프론트 엔드 앱 보호

브라우저 기반 애플리케이션을 사용하는 경우 OIDC(Open ID Connect) / OAuth 2.0 authorization_grant 플로우를 사용하여 사용자를 인증할 수 있습니다. 인증되지 않은 사용자를 발견하면 인증 페이지로 경로가 자동으로 재지정됩니다. 인증이 완료되면 어댑터가 요청을 가로채는 내재적 /oidc/callback 엔드포인트로 브라우저의 경로가 재지정됩니다. 이 때 어댑터에서 ID 제공자로부터 토큰을 얻어 원래 요청된 URL로 사용자의 경로를 다시 재지정합니다.

세션 토큰 등의 사용자 세션 정보를 보려면 Authorization 헤더를 확인할 수 있습니다.

Authorization: Bearer <accessToken> <IDToken>

인증된 사용자를 로그아웃할 수도 있습니다. 인증된 사용자가 다음 예제에 표시된 대로 oidc/logout이 추가된 상태로 보호된 엔드포인트에 액세스하면 로그아웃됩니다.

https://myhost/path/oidc/logout

필요한 경우 새로 고치기 토큰을 사용하면 사용자가 재인증하지 않고 새로운 액세스 및 ID 토큰을 자동으로 얻을 수 있습니다. 구성된 ID 제공자가 새로 고치기 토큰을 리턴하면 세션에서 해당 토큰을 유지하며 ID 토큰이 만기될 때 새 토큰을 검색하는 데 사용합니다.

백엔드 앱 보호

어댑터는 OAuth 2.0 JWT 베어러 플로우와 함께 사용하여 JWT 베어러 토큰의 유효성을 검사하여 서비스 API를 보호할 수 있습니다. Bearer 권한 플로우에서는 올바른 액세스 토큰과 선택적 ID 토큰이 있는 Authorization 헤더가 요청에 포함될 것으로 예상합니다. 예상 헤더 구조는 Authorization=Bearer {access_token} [{id_token}]입니다. 인증되지 않은 클라이언트에 권한 부여를 얻는 데 필요한 범위 목록과 함께 HTTP 401 응답 상태가 리턴됩니다. 토큰이 올바르지 않거나 만료된 경우 API 전략에서 Www-Authenticate=Bearer scope="{scope}" error="{error}"라는 선택적 오류 컴포넌트와 HTTP 401 응답을 리턴합니다.

토큰과 토큰 사용 방법에 관한 자세한 정보는 토큰 이해를 참조하십시오.

구성 정의

보호하는 애플리케이션(프론트 엔드 또는 백엔드)에 따라 다음 옵션 중 하나를 사용하여 정책 구성을 작성하십시오.

• 프론트 엔드 애플리케이션의 경우: 사용자 인증이 필요한 브라우저 기반 애플리케이션은 OIDC / OAuth 2.0 인증 플로우를 사용하도록 구성할 수 있습니다. ID 제공자를 사용하여 인증 플로우를 용이하게 하는 데 사용하는 클라이언트를 포함하는 OidcConfig CRD를 정의하려면 다음 예를 안내서로 사용하십시오.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: OidcConfig
  metadata:
     name:      oidc-provider-config
     namespace: sample-namespace
  spec:
     discoveryUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/.well-known/openid-configuration
     clientId:     <clientID>
     clientSecret: <randomlyGeneratedClientSecret>
     clientSecretRef:
           name: <nameOfKubeSecret>
           key: <keyInKubeSecret>
  

  YAML 구성 파일 구성 요소 설명

  필드	유형	필수	설명
  discoveryUrl	문자열	예	OIDC/OAuth 2.0 구성 정보의 JSON 문서를 제공하는 잘 알려진 엔드포인트입니다.
  clientId	문자열	예	인증에 사용하는 클라이언트의 ID입니다.
  clientSecret	문자열	아니오	클라이언트를 인증하는 데 사용하는 일반 텍스트 시크릿입니다. 제공하지 않으면 clientSecretRef가 있어야 합니다.
  clientSecretRef	오브젝트	아니오	클라이언트를 인증하는 데 사용하는 참조 시크릿입니다. 참조는 clientSecret 대신 사용할 수 있습니다.
  clientSecretRef.name	문자열	예	clientSecret를 포함하는 Kubernetes 시크릿의 이름입니다.
  clientSecretRef.key	문자열	예	clientSecret를 보유하는 Kubernetes 시크릿의 필드입니다.

• 백엔드 애플리케이션용: OAuth 2.0 무기명 토큰 사양은 JSON 웹 토큰(JWT)을 사용하여 API를 보호하는 패턴을 정의합니다. 다음 구성을 예제로 사용하여 토큰 서명의 유효성을 검증하는 데 사용하는 공개 키 리소스를 포함하는 JwtConfig CRD를 정의하십시오.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: JwtConfig
  metadata:
     name:      jwt-config
     namespace: sample-app
  spec:
     jwksUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/publickeys
  

애플리케이션 엔드포인트 등록

Policy CRD에 애플리케이션 엔드포인트를 등록하여 수신 요청의 유효성을 검증하고 인증 규칙을 적용하십시오. 각 Policy는 오브젝트가 있는 Kubernetes 네임스페이스에 독점적으로 적용되며 보호할 서비스, 경로 및 메소드를 지정할 수 있습니다.

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
  name:      samplepolicy
  namespace: sample-app
spec:
  targets:
    -
      serviceName: <svcSampleApp>
      paths:
        - exact: /web/home
          method: ALL
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              rules:
                - claim: scope
                  match: ALL
                  source: access_token
                  values:
                    - appid_default
                    - openid
                - claim: amr
                  match: ANY
                  source: id_token
                  values:
                    - cloud_directory
                    - google

        - exact: /web/user
          method: GET
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              redirectUri: https://github.com/ibm-cloud-security/app-identity-and-access-Adapter
        - prefix: /
          method: ALL
          policies:
            -
              policyType: jwt
              config: <jwtConfig>

어댑터

어댑터 로그를 보려면 kubectl을 사용하거나 Kubernetes 콘솔의 appidentityandaccessAdapter 팟(Pod)에서 팟(Pod)에 액세스할 수 있습니다.

alias Adapter_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=appidentityandaccessAdapter -o jsonpath='{.items[0].metadata.name}')"
Adapter_logs | jq

Mixer

어댑터가 요청을 받지 못하는 것으로 보이면 Mixer 로그를 확인하여 어댑터에 제대로 연결되었는지 확인하십시오.

alias mixer_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=telemetry -o jsonpath='{.items[0].metadata.name}') -c mixer"
mixer_logs | jq