フロントエンド・アプリの保護

ブラウザベースのアプリケーションを使用している場合、 Open ID Connect(OIDC) / 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 Bearer フローと連携して使用することで、JWT Bearer トークンを検証し、サービス API を保護することができます。 ベアラー許可フローでは、有効なアクセス・トークンとオプションの ID トークンを指定した許可ヘッダーが要求に含まれていなければなりません。 予期されるヘッダー構造は Authorization=Bearer {access_token} [{id_token}] です。 認証されていないクライアントには、HTTP 401 応答ステータスと一緒に、許可を取得するために必要な範囲のリストが返されます。 トークンが無効または期限切れの場合、API 戦略は HTTP 401 応答と一緒に Www-Authenticate=Bearer scope="{scope}" error="{error}" というオプションのエラー・コンポーネントを返します。

トークンおよびその使用方法について詳しくは、トークンについてを参照してください。

構成の定義

フロントエンド・アプリケーションとバックエンド・アプリケーションのどちらを保護するかに応じて、以下のいずれかの方法でポリシー構成を作成します。

• フロントエンド・アプリケーションの場合: ユーザー認証を必要とするブラウザー・ベースのアプリケーションは、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 Bearer トークン仕様は、 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 からポッドにアクセスできます。

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