JSON Webトークン・サービスの使用

22.1 JWTサービス

JSON Webトークン(JWT)サービスによって、様々なデプロイメント・シナリオでOracle Identity GovernanceのSCIMおよびRESTサービスの使用が簡略化されます。

Oracle Identity Governanceトークン・サービスによって作成されたJWTには、Oracle Identity Governanceサーバーによって署名されたOIMユーザーのサブジェクト要求が含まれています。この要求を、SCIMおよびREST APIを保護するOWSMエージェントに対する認証に提示できます。

Oracle Identity GovernanceのSCIMおよびRESTサービスを保護するデフォルトのマルチトークンOWSMポリシーは、様々な標準認証メカニズムを受け入れます。このOIMアイデンティティ・プロバイダは、認証ドメインにまだ統合されていないOIGエンタープライズ・デプロイメント、またはRESTスタイルAPIをネイティブにサポートしないWebSSOなどの拡張済認証メカニズムを対象としています。このドキュメントでは、SCIMおよびRESTサービスにアクセスするためにOracle Identity Governanceのデプロイメントでサポートされる様々な認証シナリオについて説明します。

Oracle Identity Governance UIの拡張としてアプリケーションがデプロイされる場合もあれば、Oracle Identity Governance UIに依存しないアプリケーションで、アイデンティティ要件を満たすためにSCIMおよびRESTサービスが使用される場合もあります。SCIMおよびRESTコンシューマは、Oracle Identity Governanceがデプロイされブラウザで実行されているものとは異なるWeb層からロードされたHTML5/JSアプリケーションである場合もあれば、JSPまたは.Netアプリケーションのバックエンドである場合もあります。モバイル・アプリケーションでSCIMおよびRESTサービスが使用されることもあります。

22.2 認証シナリオ

アプリケーションは、スタンドアロン・デプロイメントやモバイル・アプリケーションなど、様々な認証シナリオでJWTを取得し、SCIMおよびRESTサービスにアクセスできます。

次のユースケースでは、JWTを取得し、SCIMおよびRESTサービスにアクセスするための前提となる様々な認証シナリオについて説明します。

スタンドアロンのOracle Identity Manager UI認証(WLSおよびOIMアイデンティティ・ストアを使用、WAMなし):

Oracle Identity Manager UIのログイン・ページですでに認証されているユーザーは、再度認証を行わなくても(別のHTML5/JSアプリケーションを通じて) RESTおよびSCIM APIにアクセスできます。
スタンドアロン(WAMなし):

認証は、OIGポータルを介して行われます。Oracle Identity Manager UI認証は行われません。認証は、次のいずれかを使用して行われます。
- Oracle Identity Managerをアイデンティティ・ストアとして使用する、OIG REST APIに対する直接認証
- サブジェクトがOracle Identity Managerユーザー名に対応する別のメカニズム(OAuth2など)を使用した認証。
WAM対応のOIMドメイン(OAM、SMおよびTAM)

ユーザーは、Oracle Identity Managerを保護するWAMドメインに対して認証されています。サブジェクトがOracle Identity Managerユーザー名と一致するSSOトークンをアプリケーションが所持しているか、ユーザー名をアサートする特殊なリクエスト・ヘッダーをSSOエージェントが設定しています。
モバイル・アプリケーション

アプリケーションは、サブジェクトがOracle Identity Managerユーザー名と一致するセキュリティ・トークン(OAuth2など)を所持しています。すべてのシナリオにおいて、OWSMがOracle Identity ManagerのSCIMおよびRESTサービスを保護します。OWSMエージェントは、http_jwt_token_ service_policyを使用して構成されています。

22.3 JWTの取得と適用

Oracle Identity ManagerのSCIMおよびRESTサービスは、/iam/governance/token/api/v1/tokensのエンドポイントを提供するJWTアイデンティティ・プロバイダによって拡張されます。

このエンドポイントを通じて、アプリケーションは、図22-1に示すように、それ以降にSCIMおよびRESTサービスで使用するJWTを取得できます。

図22-1 トークン・エンドポイント・サービス

「図22-1 トークン・エンドポイント・サービス」の説明

一部のシナリオでは、アプリケーションは/tokensエンドポイントと直接やり取りします。その他のシナリオでは、アプリケーションは外部認証メカニズムによって保護され、ユーザーの資格証明をアプリケーションで使用することはできません。たとえば、ユーザーが、Oracle Identity Manager UIを拡張するSCIMまたはRESTベースのアプリケーションを開いてOracle Identity Manager UIに対して認証を行い、再度認証を行わなくても処理が続行されるものと想定しているとします。このような構成に対応するには、アプリケーションの認証ドメイン内にデプロイされたファサード・トークン・サービスを使用すると、ユーザーに対応するJWTを容易に取得できます。トークン・ファサードには、OWSM SAMLクライアント・ポリシーが適用されています。これにより、ユーザー・アカウントがセッションから抽出され、トークン・エンドポイントで認証に使用されるSAMLトークンが作成されます。その後、トークン・サービスにより、ログイン・ユーザーのJWTトークンが生成されます。JWTがアプリケーションに返されます。ユーザーのかわりに認証されたアプリケーションがファサードWebアプリケーション(/iam/governance/token/api/v1/tokens)を呼び出すと、図22-2に示すように、WebアプリケーションはサービスからJWTを取得し、それをアプリケーションにリレーできます。

図22-2 トークン・ファサードWebアプリケーション

「図22-2 トークン・ファサードWebアプリケーション」の説明

/tokensエンドポイントで、OWSMはユーザーを認証し、IDを/tokensエンドポイント実装にアサートします。認証されたユーザーに十分な権限がある場合、エンドポイントで自分のトークンを発行できます。実装によって、ターゲット・ユーザー名が検証され、OIMユーザーと照合されて、ユーザー名を要求するJWTがHTTPレスポンスで発行されます。このJWTは、アプリケーションがこれ以降にOracle Identity ManagerのSCIMおよびREST APIにアクセスする際に常に使用されます。

デフォルトで、ファサードWebアプリケーションはOracle Identity Managerとともにデプロイされます。

22.4 SCIM-REST認証用のJWTベースのOIMアイデンティティ・プロバイダ

SCIMおよびREST認証用のJWTベースのOIMアイデンティティ・プロバイダによってJWTが発行されます。これには、SCIMおよびRESTのセキュリティ、アイデンティティ・プロバイダのエンドポイント、セッション・タイムアウトおよびリフレッシュも含まれます。

この項では、SCIMおよびREST認証用のJWTベースのOIMアイデンティティ・プロバイダについて説明します。次の項目が含まれます。

22.4.1 SCIMおよびRESTのセキュリティの概要

SCIMおよびRESTサービスは、RESTサービスに固有のOWSM認証専用ポリシーによって保護されます。また、サービスからのOIMエンティティへのアクセスに共通するOPSS認可ポリシーでも保護されます。

SCIMおよびRESTサービスについて構成されているデフォルトのOWSM認証専用ポリシーは、認証メカニズムの中でも特に、トークン・サービスによって作成されたJWTを受け入れます。OWSMのポリシー・アタッチメントとデフォルトのOracle Identity Managerポリシーの詳細は、グローバル・ポリシー・アタッチメントの理解を参照してください。

22.4.2 JSON Webトークン(JWT)

JSON Web トークン(JWT)は、RFC 7519で定義されています。

OIMアイデンティティ・プロバイダによって発行されたJWTには、サブジェクト(OIMユーザー)、発行者、有効期限およびその他のデータの要求セグメントが含まれます。

{"exp":1448420525,"sub":"xelsysadm","iss":"www.oracle.com","prn":"xelsysadm","iat":1448418725}

また、JWTには、JWSの計算に使用されるアルゴリズムおよび証明書キーを示す認証ヘッダー(JOSE)も含まれます。

{"alg":"RS256","typ":"JWT","x5t":"8KTfKAncWGbLsNOlLZRQ77qSE74","kid":"xell"}

ヘッダーおよびペイロードはbase64urlでエンコードされ、連結されて、ピリオド文字(.)で区切られます。RSA署名はその入力を通して計算され、base64urlでエンコードされて、ピリオド文字の後に追加されます。OIMアイデンティティ・プロバイダによって、次のような別のJSON構造に結果がカプセル化されます。

{
    "tokenType": "Bearer",
    "accessToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1dCI6IjhLVGZLQW5jV0diTHNOT2xMWlJRNzdxU0U3NCIsImtpZCI6InhlbGwifQ.eyJleHAiOjE0NDg0MjA1MjUsInN1YiI6InhlbHN5c2FkbSIsImlzcyI6Ind3dy5vcmFjbGUuY29tIiwicHJuIjoieGVsc3lzYWRtIiwiaWF0IjoxNDQ4NDE4NzI1fQ.s6OLNLmYdJXF2Zj6SaTM5vPHOcKuBIcJlBvVmSATCBKnS-_qmvUYn9-8bcXDbEBo9qum2O3kF0SmbtH0u6-rx-QtNXWupf9-vbtAUVoOpm8f6X3tHVbhzBVixKYnwAZC8tN3LJ6UNOhYzxe7iOZfclmhEQILgA7I3J152gToKmU",
    "expiresIn": "1799"
    }

SCIM-RESTサービスに対する後続のコールで、oracle.security.jps.service.trust.TrustServiceおよびoracle.security.restsec.jwt.JwtTokenによって作成されたaccessTokenの値が、JWTなどの認証ヘッダーで発行されます。

22.4.3 OIMアイデンティティ・プロバイダのエンドポイント

OIMアイデンティティ・プロバイダのエンドポイントは、OIMサーバー・コンテキスト(JVM)の/iam/governance/token/api/v1/tokensにデプロイされるRESTサービスです。

エンドポイントが呼び出されると、OIMユーザー名のサブジェクト要求を含むJWTが返されます。

token-for-selfモードでは、認証されたユーザーについてリクエストが処理されます。有効なユーザーは自分のトークンをリクエストできます。

22.4.4 セッション・タイムアウトおよびリフレッシュ

JWTには、サーバー構成値から設定された有効期限が含まれている必要があります。HTTP PUTメソッドを使用して、有効期限が切れていないJWTを指定することにより、/iam/governance/token/api/v1/tokensサービスでJWTをリフレッシュできます。そのため、/iam/governance/token/api/v1/tokensエンドポイントに対してHTTP Basic認証とJWTの両方を受け入れるようにOWSMを構成する必要があります。

HTML5/JS (Webブラウザ)アプリケーションでは、アプリケーションがアイドルになっているときにリフレッシュ・サイクルを停止するなど、トークンのリフレッシュを管理する必要があります。最後のトークンの有効期限が切れると、アプリケーションは、以前に使用されたメカニズムによって再認証を行います。

モバイル・アプリケーションでは、JWTの取得に必要な資格証明を安全に保存できます。そのため、ユーザー名/パスワード認証の場合でも、再認証にユーザーの操作が必要でないことがあります。

22.4.5 JWTのタイムアウト期間の構成

JWTのタイムアウト期間は、jps-config.xmlファイルで指定します。

JWTのタイムアウト期間を構成するには:

テキスト・エディタで、$DOMAIN/config/fmwconfig/jps-config.xmlファイルを開きます。

2.trust.provider.embeddedプロパティ・セットで、trust.token.validityPeriodの値を次の例のような秒単位の値に変更します。

<propertySet name="trust.provider.embedded">
    <property name="trust.aliasName" value="xell"/>
    <property name="trust.issuerName" value="www.oracle.com"/>
    <property name="trust.keyStoreName" value="kss://opss/trustservice_ks"/>
    <property name="trust.keystoreType" value="KSS"/>
    <property name="trust.trustStoreName" value="kss://opss/trustservice_ts"/>
    <property name="trust.token.validityPeriod" value="1800"/>

ノート:

trust.token.validityPeriodプロパティがtrust.provider.embeddedプロパティ・セットで2回定義されている場合は、一方の定義を削除してください。

jps-config.xmlファイルを保存します。
Oracle Identity Managerの管理対象サーバーを再起動します。

22.5 エンドポイントおよびファサード・アプリケーション

エンドポイントには、トークン・エンドポイントとリフレッシュ・トークン・エンドポイントがあります。ファサード・アプリケーションは、ログイン・ユーザーのトークンをフェッチします。

トークンおよびリフレッシュ・トークン・エンドポイントは/iam/governance/token/api/v1/tokensです。

この項では、エンドポイントとファサード・アプリケーションについて説明します。次の項目が含まれます。

22.5.1 エンドポイント

トークンおよびリフレッシュ・トークン・エンドポイントは/iam/governance/token/api/v1/tokensです。

この項では、トークン・エンドポイントとリフレッシュ・トークン・エンドポイントについて説明します。次の項目が含まれます。

22.5.1.1 トークン・エンドポイント( /iam/governance/token/api/v1/tokens)

この項では、トークン・エンドポイントについて説明します。次の項目が含まれます。

22.5.1.1.1 トークン・エンドポイントについて

このエンドポイントは、アプリケーションがユーザーのトークンを取得できるように公開されます。OWSMは/iam/governance/token/api/v1/tokensエンドポイントで、エンドポイントの実装に対するIDアサータとしてユーザーおよびサービスを認証します。認証されたユーザーに十分な権限がある場合、エンドポイントで自分のトークンを発行できます。HTTPレスポンスで、実装によってターゲット・ユーザー名がOIMユーザーと一致することが検証され、ユーザー名を要求するJWTが発行されます。このJWTは、アプリケーションがこれ以降にOracle Identity ManagerのSCIMおよびREST APIにアクセスする際に常に使用されます。

22.5.1.1.2 トークン・エンドポイントの認可

認可については、認証されたユーザーはtoken-for-selfをリクエストできます。このケースは、トークン・リクエストの空のペイロードによって識別されます。

ターゲット・ユーザーは、Basic認証ヘッダーで識別されたユーザー名です。

22.5.1.1.3 トークン・リクエスト

トークン・リクエスト(自己)

トークン・リクエスト(自己)には、次のリクエスト・メソッド、URLおよびヘッダーが含まれます。

リクエスト・メソッド: POST
URL: https://<host>:<ssl port>/iam/governance/token/api/v1/tokens
ヘッダー:
- Authorization: Basic <Base64 encoded user:password>
- Accept: application/json
- Content-Type: application/json
- X-REQUESTED-BY: <random value>

22.5.1.2 リフレッシュ・トークン・エンドポイント(/iam/governance/token/api/v1/tokens)

この項では、リフレッシュ・トークン・エンドポイントについて説明します。次の項目が含まれます。

22.5.1.2.1 リフレッシュ・トークン・エンドポイントについて

このエンド・ポイントは、有効期限切れになる前に古いトークンを提供することにより、アプリケーションが既存のトークンをリフレッシュできるように公開されます。このエンドポイントによって既存のトークンが検証され、既存のトークンがまだ有効である場合はトークンが再発行されます。このエンド・ポイントは、JWT OWSMポリシーによって保護されます。

22.5.1.2.2 リフレッシュ・トークン・エンド・ポイントの構成

表22-1は、リフレッシュ・トークン・エンドポイントの構成のリストです。

表22-1 リフレッシュ・トークン・エンドポイントの構成

ユースケース	使用の可否	説明
既存のOracle Identity Manager UIログイン・セッション(非SSO)を含むWebブラウザ	いいえ	アプリケーションは、ファサード・アプリケーションを使用してログイン・ユーザーのトークンをフェッチします。ユーザーはいつでもOracle Identity Managerからログアウトできるため、このシナリオでリフレッシュ・エンドポイントを使用することはできません。ユーザー・トークンの有効期限が切れたときにユーザーがOracle Identity Managerにまだログインしている場合、アプリケーションは、ファサード・アプリケーションを使用して新しいトークンを取得できます。
既存のOracle Identity Manager UIログイン・セッション(SSO)を含むWebブラウザ	いいえ	アプリケーションは、ファサード・アプリケーションを使用してログイン・ユーザーのトークンをフェッチします。ユーザーはいつでもSSOからログアウトできるため、このシナリオでリフレッシュ・エンドポイントを使用することはできません。ユーザー・トークンの有効期限が切れたときにユーザーがSSOにまだログインしている場合、アプリケーションは、ファサード・アプリケーションを使用して新しいトークンを取得できます。
Oracle Identity Managerをアイデンティティ・ストアとして使用するポータルを介したWebブラウザ	はい	アプリケーションは、/tokensエンドポイントにアクセスし、ユーザー名およびパスワードを指定することにより、トークンを直接フェッチします。トークンの有効期限が間もなく切れる場合、アプリケーションは、既存のトークンを指定して/tokensエンドポイントにアクセスし、新しいトークンを受け取ります。
外部認証プロバイダを使用するポータルを介したWebブラウザ	はい	アプリケーションは、外部認証プロバイダによって認証されたユーザーのトークンをフェッチします。トークンの有効期限が間もなく切れる場合、アプリケーションは、既存のトークンを指定して/tokensエンドポイントにアクセスし、新しいトークンを受け取ります。

22.5.1.2.3 リフレッシュ・トークン・リクエスト

リフレッシュ・トークン・リクエストには、次のリクエスト・メソッド、URLおよびヘッダーが含まれます。

リクエスト・メソッド: POST
URL: https://<host>:<ssl port>/iam/governance/token/api/v1/tokens
ヘッダー:
- Authorization: Bearer <token value>
- Accept: application/json
- Content-Type: application/json
- X-Requested-By: <random_value>

22.5.2 ファサード・アプリケーション

ファサード・アプリケーションは、既存のユーザー・セッションに基づいてログイン・ユーザーのトークンをフェッチします。OIM/SSOアプリケーションにログインし、HTML/JSアプリケーションに移動したユーザーは、ファサード・アプリケーションを使用して、ログイン・ユーザーのトークンを取得できます。

表22-2は、ファサード・アプリケーションの有用性を示しています。

表22-2 ファサード・アプリケーションの有用性

ユースケース	必須
既存のOracle Identity Manager UIログイン・セッション(非SSO)を含むWebブラウザ	はい
既存のOracle Identity Manager UIログイン・セッション(SSO)を含むWebブラウザ	はい
Oracle Identity Managerをアイデンティティ・ストアとして使用するポータルを介したWebブラウザ	いいえ
外部認証プロバイダを使用するポータルを介したWebブラウザ	いいえ

ユーザーは、FacadeWebApp REST APIで次のURIを使用してJWTトークンをフェッチできます:

/FacadeWebApp/GetToken GET: これにより、ユーザー用のJWTトークンが取得されます。「FacadeWebApp Token ServiceのREST API」を参照してください。

22.6 CSRFおよびCORS保護

カスタム・リクエスト・ヘッダーを使用して、クロスサイト・リクエスト・フォージェリ(CSRF)攻撃からSCIMリソースを保護できます。クロスオリジンHTTPリクエストは、Cross-Origin Resource Sharing (CORS)メカニズムを使用して制限されます。

CSRFおよびCORS保護の詳細は、SCIMリソースのセキュリティを参照してください。