1. Oracle Access Management管理者ガイド
  2. Oracle Access Management OAuthサービスおよびOpenIDConnectの管理
  3. OpenIDConnectの理解
  4. Oracle Access ManagerのOpenIDConnect認証フロー

36.3 Oracle Access ManagerのOpenIDConnect認証フロー

OpenIDConnectサーバーは、ユーザーとしてのログイン、またはユーザーのログイン・ステータスの検証のために認証を実行し、結果を安全にクライアントに送信します。

認証フローは、IDトークンとアクセス・トークンをクライアントに返す方法を決定します。リクエストを処理するには、OAuthおよびOpenIDConnectサーバーにクライアント・アプリケーションがすでに登録されている必要があります。「クライアント」および「クライアントの作成」を参照してください。

Oracle Access Managerは、次の3-legged認証フローでOpenIDConnectをサポートします。

  • 認可コード付与フロー

  • 暗黙的付与フロー

OpenIDConnect認証フローのために、curlコマンドで使用される重要なパラメータは次のとおりです。

表36-3 OpenIDConnect認証フローのためにcurlコマンドで使用されるパラメータ

フィールド 説明 タイプ 必須/オプション

client_id

リクエストを出したクライアントのID。

string

必須

scope

OpenIDConnectリクエストには、必ず"openid"スコープ値が含まれる必要があります。これが含まれないが、他のスコープが存在する場合は、スコープ・パラメータが必須ではない通常のOAuthリクエスト・フローとして扱われます。

string

必須

redirect_uri

クライアントに登録されたレスポンス送信先のリダイレクトURI。

string

必須

response_type

リクエストのタイプを示します(有効値 - code、token、id_token、token id_token)

string

必須

state

必須ではありませんが、リクエストとコールバックの間の状態を保持するために推奨します。

string

推奨値

nonce

クライアント・セッションとIDトークンの関連付け、およびリプレイ攻撃の軽減のための値です。

文字列

暗黙的なフローの場合は必須

OpenIDConnect Core 1.0に関する項を参照してください。

この節では、以下のトピックについて説明します。

36.3.1 認可コード付与の認証フローの理解

認可コード付与フローを使用する場合は、response_typeパラメータがcodeに設定され、トークン・エンドポイントからすべてのトークンが返されます。この認証フローでは、authZcodeがクライアントに返されます。authZcodeを使用して、クライアントはトークン・エンドポイントにリクエストを送信し、アクセス・トークンとIDトークンを受け取ります。

次に、認可コード付与の認証フローの概要を説明します。

  1. クライアントは、必要なリクエスト・パラメータ(scopeおよびresponse_typeなど)を含む認証リクエストを準備し、OAM認可サーバーに送信します。

  2. OAM認可サーバーはユーザーを認証し、保護されたリソースにアクセスするためのユーザーの承諾を取得します。

  3. OAMサーバーは認可コード(authZcode)をクライアントに送信します。

  4. クライアントはauthZcodeをトークン・エンドポイントに送信し、IDトークンおよびアクセス・トークンと直接交換します。レスポンス本文に両方のトークンが含まれます。

    ノート:

    ノート: 非OpenIDConnectフローの場合はアクセス・トークンのみが返されます。

  5. クライアントはIDトークンを検証し、ユーザーのサブジェクト識別子を取得します。

ノート:

IDトークンが返されるのは、OpenIDConnectフローの場合(つまり、リクエストのscopeパラメータに"openid"キーワードが含まれる場合)のみです。scopeにキーワードがない場合は、アクセス・トークンのみが返される通常のOAuth認可コード・フローだとみなされます。

リクエストの必須パラメータには次のものがあります。

  • client_id: リクエストを出したクライアントのID

  • scope: OpenIDConnectリクエストの場合、scopeパラメータにキーワードopenidが含まれる必要があります。scopeにopenidが含まれず、他のscopeが定義されている場合、認証フローは純粋なOAuthリクエスト・フローとして扱われます。

    • リクエストされたスコープがクライアントに登録されていない場合のシナリオを考えてみましょう。3-leggedフローでは、クライアントに登録されていなかった有効なスコープをクライアントがリクエストすると、ユーザーが承諾した場合にはauthZcodeが作成されます。たとえば、リソース・サーバーにscopeA、scopeBおよびscopeCの3つのスコープがあるが、scopeAのみがクライアントに登録されているとします。認可コード付与または暗黙的付与の認証フロー中に、クライアントがscopeBおよびscopeCをリクエストします。リクエストされたスコープは有効だが、クライアントに登録されていないため、ユーザーに対して承諾ページが表示されます。ユーザーの承諾を取得すると、コードが作成されるか、暗黙的フローではトークンが生成されます。

    • リクエストでスコープが渡されない場合のシナリオを考えてみましょう。リクエストでスコープが渡されない場合、クライアントに登録されたデフォルト・スコープを使用してAuthZcodeが生成され、最終的にはアクセス・トークンが生成されます。これは純粋なOAuthフローであるため、scopeパラメータは必須ではありません。

  • redirect_uri: クライアントに登録されたレスポンス送信先のリダイレクトURI。

  • response_type: リクエストのタイプを示します。有効値はcode、token、id_tokenおよびtoken id_token)

  • state: 必須ではありませんが、リクエストとコールバックの間の状態を保持するために推奨します。

認可コード付与の認証フローの場合、サーバーはアクセス・トークンを返します。次の表に示すように、この場合のresponse_typeパラメータ値はcodeです。

表36-4 認可コード付与の認証フロー: パラメータおよびアクセス・トークン

パラメータ値 返されるトークン サンプル・リクエスト(openid scopeの場合) サンプル・レスポンス

response_type=code

アクセス・トークン

アイデンティティ・トークン

http://host2:2222/oauth2/rest/authorize?response_type=code&domain= JANEDOEIDDOMAIN1&client_id=JANEDOEOAUTHIDCLIENT1&scope=RServer0.searchsong openid profile&state=code1234&redirect_uri=http://host2:19528/app1/pages/Sample.jsp

http://host2:19528/app1/pages/Sample.jsp?code=NHN3WEtWazhjdGI0ZXhRcVh5bWttdz09fnYwcitKZ3ZDdFc3aXJoUVJISVR0S3lWRlVrbjFKM0JFSzZLOGlCZW13RkNBRzVUbzN1L3NOZUJLTVVFc3E1KzJnZlhVZGFXRXNJcEhtSkJNTi9BWWJhZ2VWUjZDZFB5SmtIM254VnRKcUdadVlGSjdzUzN4VktGTmFLVFhZYWQxR0NvYzVIa2M4ajJaN1haWUFzZHBKekpzL0pEa3ljcXZkdzEybnlVZlBrRkhSZy8vTE14VXpMQUoxcThhaXRROU5VMURhNHkrRW9WeFE2bFhLWmR0NmFyTUVTLzlsTkZtQ1B6YTNoeGtFWHJNR2FUV05BaWZJZXFkSk9nNzdTeFZpME9zVi92dWFRalRhbHNRWWkwQnBZbFBHRmppNjJhU1R0S1NBaCtZaDBENzRXMFJuQ0R4dW1SQTlKbTVWZjhZRzQ0WGVnSE0yemc2U0JxbzIzQWwxd3lNNnFFS2FpLzZvaXJjSUdwZFl3anhXSDl2b09lZkJaamNHY1ZCTlYxOUcwY3JKUWE5RFVidDF0VG1PRDBWNDdOcEFxZWFMbkFvRFc2QjZGUFFpd0drenEvSERjUVBpYWhoSUxHM1BOTW5CRFIyT2hzY3FJbzRvbWUxN0pONEVTR2ZiZC9sNFlYVUd2QXBPNFpWNVMxdGYrUEQ2cFJFLzZrRmVhYWk0cTV4T09jQnF1VytES2U4N0d2OXNpdlJPV3hUOFREajNSekFqeU5nWWNLc2VkTm51elBOeHlsYjAwQ3pTeWFNVVQ5R0toNWJCR2NYNGwzZkZUNlFJTUlHYVJDd3lKT1dITFhYRElqS3pTK29uZUxsSUdGZDByUUtHSmFrZGVNbGhmQktNT0hrcW8yY0xhNFQveTk4TW0zeXZOemNyc20zWnlIbWZOUHFuTFU4K2ZjPQ==&state=code1234

authzCode (参照用サンプル・スニペット)

該当なし

該当なし

http://localhost:8080/Sample.jsp?code=NDNlVnBOQ2MxWlZ4MHRmTWdHSm85QT09fnJBakNGU3FOOC9MZHFyK0N3dDNDZG1uVWY4Sm05WXNEdDRRbEI1cEEwQU0rb2IvVEpqS3ZjWDBnZSs0V1hka0NnYnhIRjlnKzNtekJINysvMmlPekRpS09nOUFqbEVsUEFiRmY1VG4rbmFPbDg5OGtXc2hTdHlTRUV5azM4U1k0NExHbWNKd0Fwa3YxZkw0VVZFdXBWS1dFWEtLWUR2T2FrTyt5VzNzdHhDaFp1b0NCOHBBWDFFNXZBZ1B4dEpEN2xmbm9vRzdIR0JpZEpid1ZvamR5NzFUVytKVzZuaEE3WFlPb3NlUS9BK2pqVHo2OUNuWGdxajRMMWFwU1V6M256NG1RS3JoK3E5RGVDRDd6THJ5NWl5U3RlWE14eDh1YU9oUHJwSGpkVzJnPQ==&state=code1234

access_token (参照用サンプル・スニペット)

   

"eyJraWQiOiJPSURDRG9tYWluIiwieDV0IjoibndBTXM0cXVVZDV3emdkUTZSOTZaekRrRTYwIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwOi8vZGVuMDF0cHMudXMub3JhY2xlLmNvbToxNzc4Mi9vYXV0aDIiLCJhdWQiOiJPSURDU2VydmVyIiwiZXhwIjoxNTA5NjQwMjcwLCJqdGkiOiIxUEFrcFlabVVtSjVuMlAyV0JfRDZBIiwiaWF0IjoxNTA5NjM2NjcwLCJzdWIiOiJhYXJhdGhpIiwiY2xpZW50IjoiT0lEQ0NsaWVudDIiLCJzY29wZSI6WyJPSURDU2VydmVyLnNjb3BlMSIsIk9JRENTZXJ2ZXIub3BlbmlkIiwiT0lEQ1NlcnZlci5waG9uZSIsIk9JRENTZXJ2ZXIuYWRkcmVzcyJdLCJkb21haW4iOiJPSURDRG9tYWluIn0.ulizk3lEk2aWIc89zD7uf-rIQRz89RNfDGpdy_mrl8dMhSZme69BI-DOS1-Yj7Pj6aTSXzCUUVkDTKdVzJb8e8BcjF9FYiea8mE7zw9ulHtMO-gceSiVHQ4tc3sOYJ7_vek2gUfGj7urS_h3oHQqGazWqQlQOHRxbnYr7xbprj58pFqiJdmVAp1eReYVNlmM7RpXKFRVyUZ43JBGEHONr94tuRC8H-Ss7Y9K_ND59Q0xmOmgoznXjrNz7KN2yWC3rlRuJySmPrzqG0bA0Pp30TAvXGqUpllFn5H9DN0PnZKLeUWZZRB5GaXL-xWRmbzCS6eW1l0sMEqEdABVfdooLA",

"token_type": "Bearer",

"expires_in": 3600,

     

RDRG9tYWluIn0.ulizk3lEk2aWIc89zD7uf-rIQRz89RNfDGpdy_mrl8dMhSZme69BI-DOS1-Yj7Pj6aTSXzCUUVkDTKdVzJb8e8BcjF9FYiea8mE7zw9ulHtMO-gceSiVHQ4tc3sOYJ7_vek2gUfGj7urS_h3oHQqGazWqQlQOHRxbnYr7xbprj58pFqiJdmVAp1eReYVNlmM7RpXKFRVyUZ43JBGEHONr94tuRC8H-Ss7Y9K_ND59Q0xmOmgoznXjrNz7KN2yWC3rlRuJySmPrzqG0bA0Pp30TAvXGqUpllFn5H9DN0PnZKLeUWZZRB5GaXL-xWRmbzCS6eW1l0sMEqEdABVfdooLA",

"token_type": "Bearer",

"expires_in": 3600,

refresh_token (参照用サンプル・スニペット)

   

"LGHeL2ToSLNRsYN5rmvlQg==~2G6JvVBnwuNrTN/69fDPvzX2RZSVRptEbUF4mGVkf/bjCeeZFfaPEnyoqVu9hB5Gt4BZPMDeEjYQZx1imRdGNh/NOx/MoRt8oXkyMljf1g4Qo67n5RThoyNVNczkevmNUeBznSTjdW2HNOSzHBnv0WY8IeimNkN3C77K2wAbSJtGWio8uX388jlrvXEa/5XdNe2LszA4c5nW5UgZzcjAi/69y9azViyEdtKP4ndo8CNS8O4cVAym2pryEr2zKPr+NfW7mwJ7gVeyjCaxcKmQ2zHKGpblaPHxak/iCyN0jew31XursBIRCP9PCKRwBc26qGX2Sf7W8Q3bxsUvImhvYw==",

id_token (参照用サンプル・スニペット)

   

"eyJraWQiOiJPSURDRG9tYWluIiwieDV0IjoibndBTXM0cXVVZDV3emdkUTZSOTZaekRrRTYwIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwOi8vZGVuMDF0cHMudXMub3JhY2xlLmNvbToxNzc4Mi9vYXV0aDIiLCJzdWIiOiJhYXJhdGhpIiwiYXVkIjoiT0lEQ1NlcnZlciIsImV4cCI6MTUwOTY0MDI3MCwiaWF0IjoxNTA5NjM2NjcwLCJhdXRoX3RpbWUiOjAsImp0aSI6IkJKYTRlU3NhemhLa01Wd0pOT1F1NncifQ.NmUWTa0brKTV54ZIYUq8mxamATPO3xVHILALO22CAgdAYZs0ixKDSxMH-z-7-giNyAu8MXUwXmBnfnwpd0ZuphlPVMVtr0YAEh_pzraR_bKSkgIqtHOIpswFVaz69YXyFtvmlOU77m-zEndsUbsxuJ0oZ9BErtIqcnkiaQn5os_RKr4uz3ltZtSxzH-vF1nzbmOpHZYETNrEji8kqg36gZHWxhFtbAE8hh_8UoNYpDCfxnpt1Du9kbFp2jXdeM9HVwQW_KH7Vv6rW8mChPefw9lAv3nfHxuiwcZ2GLC9NOwSJBVDMA94V1u9KfsXvR_bAIyaVE5zC-rpFEyXEG5ckA"

36.3.2 暗黙的付与の認証フローの理解

暗黙的付与の認証フローの場合、次のように、response_typeパラメータに応じてサーバーはすべてのトークンを同時に返します。

表36-5 暗黙的付与の認証フロー: パラメータおよびアクセス・トークン

パラメータ値 返されるトークン サンプル・リクエスト サンプル・レスポンス

response_type=token id_token

アクセス・トークン

アイデンティティ・トークン

http://host3:2222/oauth2/rest/authorize?response_type=token id_token&domain=OIDCDomain&client_id=OIDCClient2&scope=OIDCServer.scope2+OIDCServer.openid+OIDCServer.email&redirect_uri=http://localhost:8080/Sample.jsp&nonce=abcde

http://localhost:8080/Sample.jsp#access_token=eyJraWQiOiJPSURDRG9tYWluIiwieDV0IjoibndBTXM0cXVVZDV3emdkUTZSOTZaekRrRTYwIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwOi8vZGVuMDF0cHMudXMub3JhY2xlLmNvbToxNzc4Mi9vYXV0aDIiLCJhdWQiOiJPSURDU2VydmVyIiwiZXhwIjoxNTA5NzE2MjY2LCJqdGkiOiJnTVllVGFrZVB6T3lZdGlHS0N5TTdnIiwiaWF0IjoxNTA5NzEyNjY2LCJzdWIiOiJhYXJhdGhpIiwiY2xpZW50IjoiT0lEQ0NsaWVudDIiLCJzY29wZSI6WyJPSURDU2VydmVyLnNjb3BlMiIsIk9JRENTZXJ2ZXIub3BlbmlkIiwiT0lEQ1NlcnZlci5lbWFpbCJdLCJkb21haW4iOiJPSURDRG9tYWluIn0.TDoX8y9Eg__DxrxWFrg0-sBxMiJaiPeo7jMdIDsKIXfkN60WGRuSI9atFHgcU5cnK_8R1jtZtlyp7kdUqmy-89prnzylWgUdUHXGspQVbsRf08Sgbhmrtz_RczKUygK78SSRTJXlKigRF_T3Wy6B9cmlcR-H1iVctR4eD8xcUCfGm5_bcnewTTOFbSsXDghwT_NIn1Dg-Jn6MgpWEMZMz7O_RFFrWeosztwvYqwatT7PDZZqszJ-qN9_muW4lUH-k4AnMIWS1jYUpjPMIa98gALyOP8WP6dtyB_q4FLZnx_ECmobXLvGo4GnMNLEL7sYj3jgYNySBB2d06jZcQocBQ&token_type=Bearer&id_token=eyJraWQiOiJPSURDRG9tYWluIiwieDV0IjoibndBTXM0cXVVZDV3emdkUTZSOTZaekRrRTYwIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwOi8vZGVuMDF0cHMudXMub3JhY2xlLmNvbToxNzc4Mi9vYXV0aDIiLCJzdWIiOiJhYXJhdGhpIiwiYXVkIjoiT0lEQ1NlcnZlciIsImV4cCI6MTUwOTcxNjI2NiwiaWF0IjoxNTA5NzEyNjY2LCJhdXRoX3RpbWUiOjAsIm5vbmNlIjoiYXZ5dWt0aCIsImp0aSI6IlFWdkFzU2xla3RTVWgtVHFNRXd5Q1EifQ.BMpBwtSbsffW2vz2YDh594UFOWcN52jtt2mVX3hD6OK3y-_qra71g676Igbk9PKSNcDp15yrFkIvuz39wbvVW_DC5DfOjRpWnWd-4KX8RoPpwSJDNFwZVudvgWoJ7bafGaaVO7Y-pnK-dkvb8lOX2ohBt3byaAu3rjykswR_wSw00r3ElExHqi4KSUeXW5LKDUOEf3E9pAC8tEcpQq6oh-QuzVfNxHJmB2zjSpFnzmUtuH74otVxUck38s5qqu5OiiHjw1DYgyatk-QxoJXuBPlEP0RBZ9Fspg1eJCQbhXDJoaA_n4yGsxpfM00Gok-PSTJbc0K29pwN6CdJbqCJGg&state=

response_type=id_token

アイデンティティ・トークン

http://host3:2222/oauth2/rest/authorize?response_type=id_token&domain=OIDCDomain&client_id=OIDCClient2&scope=OIDCServer.scope2&redirect_uri=http://localhost:8080/Sample.jsp&nonce=1234&state=abcd

http://localhost:8080/Sample.jsp#id_token=eyJraWQiOiJPSURDRG9tYWluIiwieDV0IjoibndBTXM0cXVVZDV3emdkUTZSOTZaekRrRTYwIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwOi8vZGVuMDF0cHMudXMub3JhY2xlLmNvbToxNzc4Mi9vYXV0aDIiLCJzdWIiOiJhYXJhdGhpIiwiYXVkIjoiT0lEQ1NlcnZlciIsImV4cCI6MTUwOTcyNTI0MCwiaWF0IjoxNTA5NzIxNjQwLCJhdXRoX3RpbWUiOjAsIm5vbmNlIjoiMTIzNCIsImp0aSI6Ii12RThqMlpHOEhabXZTRnVXcTVPSmcifQ.2qxv4rdrv-YvWNUK31aphrWkQ0iIrxhK690X2FgWW1CSNImUWfYGsNolcHiXxyzwPT6sv6koJ4m0jOIl2HEnIuWTdbE7SbtNJQ8JSVcg2et6hQJXLUXB1ECJQGCtw8FUYsprg-dtki-gCW85eRH9_V1RJMV2XaHC7PNoHEjG4CfqKmjwubfletYRReXks_uJ9YYW8TKnk87srG2Hh-uzK3C_GFLqUWaFrXp6XyM1yS-w4N-WyQ7UszuZTv8zd8SzX1xahjIdY0nakMEA7My7O3PcpVM4RTh-6xVLR_jNqRGxwbg4jc8QfmoWzMwRrYyjxFTzBSyGgd0jB3PWp4zn5w&state=abcd

response_type=token

アクセス・トークン

http://host3:2222/oauth2/rest/authorize?response_type=token&domain=OIDCDomain&client_id=OIDCClient2&scope=OIDCServer.scope1&state=code1234&redirect_uri=http://localhost:8080/Sample.jsp

http://localhost:8080/Sample.jsp#access_token=eyJraWQiOiJPSURDRG9tYWluIiwieDV0IjoibndBTXM0cXVVZDV3emdkUTZSOTZaekRrRTYwIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwOi8vZGVuMDF0cHMudXMub3JhY2xlLmNvbToxNzc4Mi9vYXV0aDIiLCJhdWQiOiJPSURDU2VydmVyIiwiZXhwIjoxNTA5NzA5OTE0LCJqdGkiOiI5S3BfLUZhT2pBTmxOOFE5S1J2T2d3IiwiaWF0IjoxNTA5NzA2MzE0LCJzdWIiOiJhYXJhdGhpIiwiY2xpZW50IjoiT0lEQ0NsaWVudDIiLCJzY29wZSI6WyJPSURDU2VydmVyLnNjb3BlMSJdLCJkb21haW4iOiJPSURDRG9tYWluIn0.QcCrRvlBEbK6-rVooKqkSzMP0RofgjeEhr74AbdJGnNQewlTQ9zry_TY56oWrkkyNKqjRYN0qa1_kXHoe562M-02L46A2qJSEEaaejrYhuvItmKbur0XlPpx8stUGCBhiv_vzSX_E5dr2aZ7P9Xz6Eqjm-wMMzZngAKImPmrdMDR3eJLIK2AfX7DFdcS9g4FIDZC3I8eoJ6sNBjBSVY37qGoT87NUh_d3y4Ga0Ga9Y9n5tHoxrqW1kuvtAAxHbB2lQBvBabSgDlGMGS9Fp7o0pi6by176XFUg7iYb1UY5Dx1hr0mlwPOHb3ndBX8Kg6wna_NplvvHrSc7XTH3DpOYw&token_type=Bearer&state=code1234

ノート:

認可コード付与または暗黙的付与タイプで認可リクエストが作成されたときに、openid scopeが含まれない場合、リクエストは通常のOAuth認可リクエストとして処理されます。レスポンスを介してid_tokenは発行されません。access_tokenおよびrefresh_tokenのみが発行されます(認可コード付与フローの場合)

36.3.3 OpenIDConnectユーザー情報エンドポイントの理解

ユーザー情報エンドポイントはOAuth2.0リソースで、認証されるユーザーに関するクレームまたは情報を返します。

必要なすべてのスコープを含むアクセス・トークンが生成されます。クライアントはこのアクセス・トークンをサーバーのユーザー・エンドポイントに渡し、エンドユーザーに関するクレームをリクエストします。

OpenIDConnectクライアントはscope値を使用して、アクセス・トークンについてリクエストされているアクセス権限を指定します。アクセス・トークンに関連付けられているスコープは、OAuth 2.0で保護されているエンドポイントにアクセスするときに、使用可能なリソースを決定します。

OpenIDConnectでは次のscope値が定義されます。次の表のように、これらを使用してクレームをリクエストします。

表36-6 クレームをリクエストするためのscope値

スコープ 説明 必須/オプション

profile

リクエストされた場合、このスコープでアクセス・トークンが生成されます。アクセス・トークンがサーバーのユーザー情報エンドポイントに送信されると、サーバーは、認証されるユーザーのプロファイルについて特定のクレームにより応答します。

オプション。

email

ユーザーのemailおよびemail_verifiedクレームへのアクセスをリクエストします

オプション。

address

エンドユーザーのaddressクレームへのアクセスをリクエストします。

オプション。

phone

エンドユーザーのphone_numberおよびphone_number_verifiedクレームへのアクセスをリクエストします。

オプション。

関連項目:

36.3.3.1 OAMからのユーザー情報属性の取得

LDAPを使用する場合、すべてのscope属性またはクレームの値をOAMから取得する必要があります。ユーザー情報クレームを取得するためにOAMを構成します。

次のいずれかの方法で新しいIDStoreを作成します。

  • IDSProfile使用して作成

  • OAM IDStoreを直接作成

ノート:

トークンの属性またはクレームはIDStoreの物理属性にマップされます。userinfoレスポンスの一部として返される属性またはクレームは変更できません。ただし、これらの一部として返される値は、IDStoreで属性を編集して物理属性マッピングに変更できます。

関連項目:

次の表は、各スコープのクレームおよび対応するバックエンドLDAP属性を示しています。

表36-7 各スコープのクレームおよび対応するバックエンドLDAP属性。

スコープ 属性/クレーム IDStore属性 IDSProfileの物理属性 サンプル・レスポンス

Profile

名前

family_name

given_name

given_name

preferred_username

gender

locale

updated_at

name

lastname

firstname

firstname

name

これは""として返されます

preferredlanguage

現在の時刻

例: cn

sn

givenname

givenname

cn

"profile": {

"name": " jane",

"family_name": " doe",

"given_name": "jane"

"preferred_username": "j.doe",

"gender": "",

"locale":"en/US"

"updated_at": "1509709292632"

}

email

電子メール

email_verified

mail

"N"

   

address

formatted

country

region

postal_code

postaladdress

country

state

postalcode

"address": {

"formatted": "Aaccf Amar$01251 Chestnut Street$Panama City, DE 50369",

"country" :"US",

"region": "DE",

"postal_code": "50369"

}

  

phone

phone_number

phone_number_verified

telephone

"N"

"phone": {

"phone_number": "jane",

"phone_number_verified": "N"

}

  

次の図は、エンティティ属性とIDSProfileの物理属性のマッピングを示しています。

claim:given_nameがIDStoreのfirstname属性にマップされると、firstnameがLDAPのgivenname物理属性にマップされます。この属性からの物理属性へのマッピングを変更して、必要な値を指定できます。givennameのかわりにmaidennameを返す必要がある場合に、物理属性の列を変更できます。

次の図に示すように、IAMSuiteの下部に、OAuth用にすぐにシードされる2つのリソースがあります。UserAttributesのリクエスト中に、リソース /OAuth/UserAssertionが使用されて新しいIDStoreに対してユーザーがアサートされます。次に、最初に作成されたIdentityDomainを変更して、identityProviderをAdmin OAuth APIまたはcurlコマンドを使用して作成した新しいIDStoreに設定します。

aiaag_oidc_iamsuite_appdom.pngの説明が続きます
図aiaag_oidc_iamsuite_appdom.pngの説明

新しく作成されたIDStoreがDefaultStoreの場合、変更は必要ありません。リソース/OAuth/UserAssertionにより、LDAPNoPasswordValidationSchemeを持つOAuthアサーション・ポリシーが使用されます。新しいIDStoreを使用するLDAPNoPasswordAuthModuleがスキームにより使用されることを確認してください。

aiaag_oidc_idsprofle.pngの説明が続きます
図aiaag_oidc_idsprofle.pngの説明aiaag_oidc_ldapnopassauth.pngの説明が続きます
図aiaag_oidc_ldapnopassauth.pngの説明

新しく作成されたIDStoreがDefaultStoreでない場合は、次を行います。

  • UserIdentificationPluginを使用して、新しい認証モジュールUserInfoAuthModuleを作成します

  • KEY_IDENTITY_STORE_REFを新しいIDStoreを指すように設定します。

  • 新しいAuthnSchemeを作成するか、LDAPNoPasswordValidationSchemeを更新してこの新しいモジュールを使用します。

  • OAuthアサーション・ポリシーを更新して、この新しい認証スキームを指すようにします。

表36-8 新しい認証モジュールのUserInfoAuthModuleを作成するためのパラメータ

エンドポイント サンプル・リクエスト サンプル・レスポンス

http://{{machine}}:{{mgdport}}//oauth2/rest/userinfo

curl -X GET http://host4:14100//oauth2/rest/userinfo -H 'authorization: Bearer <AccessToken>'

"profile": {

"name": "oamAdminUser",

"family_name": "oamAdminUser",

"preferred_username": "oamAdminUser",

"locale": "oamAdminUser",

"updated_at": "1512529444621"

},

"email": {

"email": "oamAdminUser",

"email_verified": "N"

},

"address": {

"formatted": "oamAdminUser",

"region": "oamAdminUser",

"postal_code": "oamAdminUser",

"country": "oamAdminUser"

},

"phone": {

"phone_number": "oamAdminUser",

"phone_number_verified": "N"

}

}

36.3.4 OpenIDConnectの検出エンドポイントの理解

OpenIDプロバイダ発行者の検出は、OpenIDプロバイダの場所を判別するプロセスです。

検出された発行者の場所を使用して、OpenIDプロバイダの構成情報を取得できます。レスポンスはOpenIDプロバイダの構成に関するクレームのセットで、必要なすべてのエンドポイントおよび公開キーの場所の情報が含まれます。

36.3.4.1 OpenIDConnectの検出エンドポイントの構成

OpenIDプロバイダの構成の詳細は/.well-known/openid-configurationを介して公開されます。

次の図に示すように、OAMコンソールでは、IAMSuiteドメインの配下にOpenID検出エンドポイントがリソースとしてリストされます。

aiaag_oidc_discov_endpoint.pngの説明が続きます
図aiaag_oidc_discov_endpoint.pngの説明

<ohs_domain_home>/config/fmwconfig/components/OHS/instances/<ohs_instance_name>にあるmod_wl_ohs.confファイルを見つけて、次を追加します。 

<Location /.well-known/openid-configuration> 
SetHandler weblogic-handler
PathTrim /.well-known 
PathPrepend /oauth2/rest
WebLogicHost <OAM_managed_server host>
WebLogicPort <OAM_managed_server port> 
</Location>

サンプル・リクエスト: 

GET /.well-known/openid-configuration HTTP/1.1 
Host: host4:7777

サンプル・レスポンス: 

{
"issuer": "http://host4:7777/oauth2", 
"authorization_endpoint": "http://host4:7777/oauth2/rest/authorize", 
"token_endpoint": "http://host4:7777/oauth2/rest/token", 
"userinfo_endpoint": "http://host4:7777/oauth2/rest/userinfo", 
"introspect_endpoint": "http://host4:7777/oauth2/rest/token/info",
"jwks_uri": "http://host4:7777/oauth2/rest/security", 
"end_session_endpoint": "http://host4:7777/oauth2/rest/userlogout", 
"scopes_supported": [ 
	"openid",
	"profile", 
	"email", 
	"address", 
	"phone" 
],
"response_types_supported": [
	"code",
	"token",
	"id_token",
	"token id_token"
],
"grant_types_supported": [
	"client_credentials",
	"password",
	"refresh_token",
	"authorization_code",
	"implicit",
	"urn:ietf:params:oauth:grant-type:jwt-bearer"
],
"subject_types_supported": [
	"public"
],
"id_token_signing_alg_values_supported": [
	"RS256"
],
"userinfo_signing_alg_values_supported": [
	"none"
],
"token_endpoint_auth_methods_supported": [
	"client_secret_basic",
	"client_secret_jwt"
],
"token_endpoint_auth_signing_alg_values_supported": [
	"RS256"
],
"claims_supported": [
	"aud",
	"exp",
	"iat",
	"iss",
	"jti",
	"sub"
],
"ui_locales_supported": [
	"en"
]
}

36.3.4.2 OIDC検出エンドポイントの構成

OpenIDプロバイダの構成の詳細に加えて、もう1つのエンドポイント/.well-known/oidc-configurationが公開されます。これは認証およびログアウト・エンドポイントなどのアクセス・サーバーに関する情報を提供します。

<ohs_domain_home>/config/fmwconfig/components/OHS/instances/<ohs_instance_name>にあるmod_wl_ohs.confファイルを見つけて、次を追加します。 

<Location /.well-known/oidc-configuration> 
SetHandler weblogic-handler
PathTrim /.well-known 
PathPrepend /oauth2/rest
WebLogicHost <OAM_managed_server host>
WebLogicPort <OAM_managed_server port> 
</Location>

サンプル・リクエスト: 

GET /.well-known/oidc-configuration HTTP/1.1 
Host: host4:7777

サンプル・レスポンス: 

{
"configuration": {
"release-version": "12.2.1.3.0"
},
"access-configuration": {
"http-direct-authentication-endpoint": "http://host4:7777/oam/server/authentication",
"http-logout-endpoint": "http://host4:7777/oam/server/logout",
"http-credential-submit-endpoint": "http://host4:7777/oam/server/auth_cred_submit"
},
"openid-configuration": {

← Same as openid discovery response value→
}
}

ノート:

現在のところ、end_session_endpointを介したバックチャネル・ログアウトは実装されていません。http-logout-endpointを介したフロントチャネル・ログアウトを使用して、ユーザーをログアウトしてセッションを終了できます。

36.3.5 アイデンティティ・ドメイン証明書のフェッチ

securityエンドポイント、http://<managed server host>:<managed server port>/oauth2/rest/securityを使用して、所定のアイデンティティ・ドメインの公開証明書をフェッチします。このエンドポイントからの出力は<identitydomain>.p7bファイルです。

表36-9 所定のアイデンティティ・ドメインの公開証明書のフェッチ: パラメータ

パラメータ・タイプ パラメータ名 説明 サンプル

ヘッダー

X-OAUTH-IDENTITY-DOMAIN-NAME

Identity Domain Name

MDCDomain19

ヘッダー

Authorization

基本<B64エンコードclientid:password>

Basic TURDQ2xpZW50MTk6d2VsY29tZTE=

問合せ

identityDomainName

Identity Domain Name

ノート: 第一に優先されるのはX-OAUTH-IDENTITY-DOMAIN-NAMEです。

次に優先されるのはidentityDomainNameです。

MDCDomain18

次に、RESTコールのサンプルを示します。ここで、X-OAUTH-IDENTITY-DOMAIN-NAMEはidentityDomainNameより優先されます。

サンプル・リクエスト:

 curl -X GET 'http://host1:14100/oauth2/rest/security?identityDomainName=MDCDomain18' -H 'authorization: Basic TURDQ2xpZW50MTk6d2VsY29tZTE=' -H 'x-oauth-identity-domain-name: MDCDomain19'

次に示すRESTコールのサンプルでは、p7b形式でMDCDomain18公開証明書チェーン(MDCDomain18.p7bファイル)が生成されます。

サンプル・リクエスト:

curl -X GET 'http://host1:14100/oauth2/rest/security?identityDomainName=MDCDomain18' -H 'authorization: Basic TURDQ2xpZW50MTk6d2VsY29tZTE='