Product-apim: 가입자에 대한 기본 인증 지원

새로 출시된 APIM 3.0.0은 기본 인증을 지원합니다. 현재 우리 환경에서 사용하고 있습니다.

백엔드 엔드포인트의 경우 예. API의 경우 옵션을 찾을 수 없습니다.

API 게시자 -> 런타임 구성 -> 애플리케이션 수준 보안

@Tomas-Mrazek 맞습니다. 이제 API 클라이언트에 대한 기본 인증도 지원합니다. 위와 같이 애플리케이션 수준 보안에서 Basic 옵션을 활성화할 수 있습니다. 이렇게 하면 API 소비자가 사용자 이름 암호 조합을 사용하여 이 API를 호출할 수 있습니다.

알겠습니다. 같은 곳을 보고 있는 것 같습니다. 방금 테스트했고 작동합니다.

이것은 더 많은 질문을 가져옵니다.

구독은 기본 인증으로 어떻게 작동합니까? 모든 사용자가 구독과 관계없이 모든 API를 호출할 수 있는 것처럼 보입니까? 특정 응용 프로그램에 사용자를 "할당"하여 응용 프로그램이 등록된 API만 호출할 수 있도록 하는 방법이 있습니까?

Prod와 Sandbox가 동일한 게이트웨이를 공유하는 경우 기본 인증을 수행할 때 어떤 게이트웨이가 호출되는지 어떻게 결정합니까?

기본 인증에서 사용자 이름과 암호 대신 응용 프로그램 키와 응용 프로그램 암호를 사용하는 경우 이 두 질문에 대한 답변이 필요하지 않습니다.

어쩌면 내가 뭔가를 놓치고있을 수도 있으므로 문서를 지적 할 수 있다면 좋을 것입니다.

구독은 기본 인증으로 어떻게 작동합니까? 모든 사용자가 구독과 관계없이 모든 API를 호출할 수 있는 것처럼 보입니까? 특정 응용 프로그램에 사용자를 "할당"하여 응용 프로그램이 등록된 API만 호출할 수 있도록 하는 방법이 있습니까?

아니요, oauth2 토큰과 동일하게 작동해야 합니다. 구독한 사용자만 API를 호출할 수 있으며 토큰 또는 기본 인증을 통해 여부는 중요하지 않습니다.

반대 방식으로 작동하기 때문에 응용 프로그램에 사용자를 할당할 수 없습니다. 응용 프로그램은 사용자에게 속합니다. 보다 세분화된 제어를 원하면 /carbon 콘솔에서 역할을 생성하고 사용자에게 할당하십시오. API 게시자에서 API 설정으로 이동하여 devportal에 대한 가시성을 특정 역할로 변경합니다. 그런 다음 각 리소스에 대한 특정 역할이 있는 범위를 만들고 이 범위를 리소스에 할당하고 보안을 활성화합니다. 구독한 사용자는 API를 호출할 수 있지만 사용자에게 역할을 할당하지 않으면 보호된 리소스를 호출할 수 없습니다.

Prod와 Sandbox가 동일한 게이트웨이를 공유하는 경우 기본 인증을 수행할 때 어떤 게이트웨이가 호출되는지 어떻게 결정합니까?

좋은 질문. 나는 답을 모른다.

그건 그렇고, 이것은 소비자 키와 비밀로 작동하지 않습니다. 끝점은 /token 생성 AFAIK 중에 지정됩니다.

안녕하세요 @Tomas-Mrazek 및 @tmkasun , 이것은 이제 기본 인증에 대한 저의 문제입니다. 인증에 대한 제 생각을 요약해 보겠습니다.

OAuth2 - 앱을 API로 구독합니다. 키와 비밀을 기반으로 앱과 환경을 알고 있습니다. 따라서 앱이 Api를 사용하도록 허용하려면 구독하기만 하면 됩니다. 그런 다음 모든 사용자는 키와 비밀을 알고 있으면 해당 API를 호출할 수 있습니다.

정적 API 키 - 여기서 우리는 키를 알고 있으며 이는 어떤 애플리케이션이 API를 호출하고 어떤 환경을 사용하는지 알 수 있는 충분한 정보를 제공합니다. 앱을 사용하기 위해 API를 구독한다는 개념은 여전히 ​​적용됩니다. App을 Api에 구독하기만 하면 됩니다.

현재 와 같은 기본 인증 - "사용자 기반 기본 인증"이라고 부를 것입니다. 앱 및 구독의 개념을 완전히 버리고 게시자 또는 Store/DevPortal 대신 Carbon admin을 사용하는 것과 같은 다른 개념(사용자 기반 권한)과 다른 도구를 사용해야 합니다. 그리고 하나의 게이트웨이를 사용하는 경우 프로덕션 환경과 샌드박스 환경을 구분하지 못합니다. 또한 설정 및 관리가 더욱 복잡해집니다. 이제 구독한 앱 목록을 보는 것만으로는 충분하지 않습니다. 또한 carbon admin으로 이동하여 사용자 및 권한을 확인해야 합니다. 그리고 Api에 대해 하나의 특정 앱을 평가하거나 구독 수준이 다른 경우 사용자에 대해 그렇게 할 수 없습니다.

기본 인증을 지원하는 "올바른" 방법은 다음과 같습니다.

앱 수준 기본 인증 - 사용자를 개념에서 제외하고(예: 정적 키 사용) 대신 응용 프로그램 인증을 사용합니다. 애플리케이션은 여전히 ​​API에 가입해야 합니다. 소비자 키와 소비자 비밀은 기본 인증 자격 증명으로 사용됩니다. 그렇게 하면 앱/Api 구독 개념을 유지하고 다른 모든 것과 동일한 도구(퍼블리셔/devPortal, Carbon Admin 필요 없음)를 계속 사용할 수 있으며 키를 기반으로 어떤 앱이 어떤 API를 사용하고 어떤 환경을 사용하는지 알 수 있습니다.

거기에 도착하는 방법?

두 가지 옵션이 있습니다. 현재 기본 구현을 위에서 제안한 것으로 변경하거나 "앱 기본 인증"이라는 새로운 구현을 구현하십시오.
기존 기본 인증에서 사용자/패스 및 키/비밀을 모두 지원하는 세 번째 옵션도 있지만 가장 더러운 옵션입니다.

기본 인증 구현으로는 충분하지 않습니다. 예를 들어 Carbon 콘솔을 통해 생성하고 사용자와 연결해야 하는 역할 ->을 기반으로 devportal에서 API 가시성을 제한할 수 있습니다.

안녕하세요 @Tomas-Mrazek 및 @markokocic
제안해 주셔서 감사합니다. 내 답변을 인라인으로 찾으십시오.

구독은 기본 인증으로 어떻게 작동합니까? 모든 사용자가 구독과 관계없이 모든 API를 호출할 수 있는 것처럼 보입니까? 특정 응용 프로그램에 사용자를 "할당"하여 응용 프로그램이 등록된 API만 호출할 수 있도록 하는 방법이 있습니까?

클라이언트 요청에 대한 기본 인증 지원에는 구독이 필요하지 않습니다. API 작성자가 특정 API에 대한 기본 인증 지원을 활성화한 경우 해당 API에 가입하지 않고도 해당 API를 호출할 수 있습니다(애플리케이션별).
@markokocic 예, 구독 작동 방식은 An Application subscribed to an API 입니다.

또한 Baisc 인증을 사용하면 다음을 수행할 수 있습니다.
당신은 여전히 ​​얻습니다 :

• 리소스 수준 또는 API 수준 조절
• 리소스 범위 유효성 검사

당신은 얻을 수 없습니다:

• 구독 수준 조절
• Production & Sandbox 환경 차별화

Prod와 Sandbox가 동일한 게이트웨이를 공유하는 경우 기본 인증을 수행할 때 어떤 게이트웨이가 호출되는지 어떻게 결정합니까?

예, 사용자 이름과 비밀번호로 환경을 구분할 수 없었습니다. 따라서 기본 인증을 사용할 때 환경을 선택할 수 있는 옵션이 없으며 프로덕션 엔드포인트가 사용됩니다.

@Tomas-Mrazek

끝점은 /token 생성 AFAIK 중에 지정됩니다.

아니요, API 생성자가 API 생성자에 의해 엔드포인트(제품 및 샌드박스)를 정의합니다. API 소비자는 리디렉션 기반 부여 유형(즉, 암시적)을 사용하려는 경우 애플리케이션에 대한 콜백 URL을 제공할 수 있습니다.

@markokocic 관련

앱 수준 기본 인증

이것은 현재 구현에서도 가능합니다. 클라이언트 자격 증명 부여 유형을 사용하여 애플리케이션 소유자를 대신하여 토큰 쌍을 얻을 수 있습니다.

앱 수준 기본 인증

이것은 현재 구현에서도 가능합니다. 클라이언트 자격 증명 부여 유형을 사용하여 애플리케이션 소유자를 대신하여 토큰 쌍을 얻을 수 있습니다.

@tmkasun
예, 기본 인증을 사용하여 클라이언트 자격 증명을 사용하여 토큰을 생성할 수 있습니다. 다음과 같이 사용합니다.

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

그러나 API를 사용하려면 소비자가 여전히 다음을 수행할 수 있어야 합니다.

• 위의 방법을 사용하여 토큰 생성
• 실제 API 요청에 대해 Bearer 및 Token을 사용하여 http "Authorization" 헤더로 설정합니다.
• 결국 토큰 만료 및 새로 고침을 처리합니다.

프로그래머가 소비자를 프로그래밍하거나 이를 수행할 수 있는 공급업체가 있으면 괜찮습니다. 설명된 대로 이 문제는 사용자 지정할 수 없는 많은 레거시 엔터프라이즈 클라이언트에서 발생합니다. 예를 들어 SAP에서 외부 서비스를 사용하려는 경우 설정할 수 있는 유일한 항목은 URL이며 기본 인증을 위한 선택적으로 사용자 이름과 비밀번호입니다. 토큰을 가져오거나 사용자 정의 헤더를 설정할 수 있는 기능이 없습니다.

위에서 앱 수준 기본 인증으로 설명한 것은 실제로 토큰 생성 단계를 건너뛰고 클라이언트 자격 증명을 기반으로 기본 인증을 직접 사용하여 API를 호출하는 기능입니다.

다음과 같은 것:

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

이렇게 하면 사용자를 생성, 설정 및 관리할 필요 없이 동일한 App to API 구독 모델을 계속 사용할 수 있습니다.

또 다른 이점으로 기본 인증 표준은 인증 헤더를 URL의 일부로 포함하는 기능을 제공하므로 다음과 같이 레거시 소비자를 지원할 수도 있습니다.

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

편집: 지금 생각해보면 더 명확한 이름은 API용 클라이언트 자격 증명 기반 기본 인증일 것입니다.