Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
Oracle Access Managementには、OAuthサービスを構成するためのGUIが用意されています。この章では、Oracle Access Managementコンソールを使用して、OAuthサービスを構成する方法について説明します。この章の内容は、次のとおりです。
注意: OAuthサービスは、WLSTを使用してコマンド行から構成できます。Mobile and SocialのWLSTコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。 |
標準OAuthサービスは、Oracle Access ManagementのIdentity Federationサービスが「使用可能なサービス」で有効になっている場合に有効です。Mobile OAuthも有効とするには、Identity Federationサービスに加えて、Mobile and Socialサービスも有効化します。
Identity Federationサービスの有効化については、「Oracle Access ManagementのIdentity Federationの概要」の章の「Identity Federationの有効化」を参照してください。
Mobile and Socialサービスの有効化については、「Mobile and Socialの理解」の章の「Mobile and Socialの有効化」を参照してください。
Oracle Access ManagementコンソールでOAuthサービスの構成ページを開くには、次の手順を実行します。
Oracle Access Managementコンソールにログインします。
「起動パッド」が開きます。
「Mobile and Social」ペインの「OAuthサービス」をクリックします。
独自のタブで「OAuthアイデンティティ・ドメイン」ページが開きます。
「OAuthアイデンティティ・ドメイン」ページにOAMサーバーのすべてのOAuthアイデンティティ・ドメインがリストされます。ドメインをクリックして構成します。次の各項では、OAuthサービスの構成に使用するタブについて説明します。
OAuthサービスは、DefaultDomainという名前のOAuthアイデンティティ・ドメインに同梱されています。必要に応じて、追加のドメインを作成できます。各OAuthアイデンティティ・ドメインには、インターネット上で一意に識別する汎用一意識別子(UUID)があります。OAuthアイデンティティ・ドメインを構成するには、次の構成オブジェクトを定義します。
OAuthサービス・プロバイダ
1つ以上のOAuthサービス・プロファイル
1つ以上のOAuthクライアント
1つ以上のOAuthリソース・サーバー
アイデンティティ・ドメイン・レベルで次の設定を構成することもできます。
OAuthサーバー設定
OAuthプラグイン
OAuthジェイルブレーク検出ポリシー
ユーザー・プロファイル・サービス設定(「リソース・サーバー」構成タブで使用可能)
承認管理サービス設定(「リソース・サーバー」構成タブで使用可能)
次の画面は、アイデンティティ・ドメイン内でトークンを検索し、取り消すために使用できます。
トークン・ライフ・サイクル管理
OAuthサービス・プロバイダの設定ページを使用して、OAuthサービスと、OAuthサービスをサポートするバックエンド認可サービス・プロバイダであるAccess Manager間の接続を管理します。
サービス・プロファイルは、OAuthサービスの次の構成設定カテゴリを定義します。
サービスと相互作用可能なクライアント
サービスが保護し、アクセスを提供可能なカスタム・リソース・サーバー
リフレッシュ・トークン設定、有効期限設定およびトークン・ライフサイクル管理を有効にするオプションを含む、サービスのトークン設定
サービスで有効化されるユーザー・プロファイル・サービス・プロファイルおよび承認管理サービス・プロファイル
サービスで有効化されるセキュリティ・プロファイル・プラグイン
サポートされるモバイル・プラットフォームのセキュリティ設定を含む、サービスのモバイル・サービス設定
OAuthサービス・エンドポイントのルートURL
必要に応じて、異なる構成設定を持つ異なるサービス・エンドポイントを定義する複数のサービス・プロファイルを作成できます。
各リソース・サーバーの設定を個別に定義するには、「リソース・サーバー」タブを使用します。アプリケーションまたはサービスのカスタム・リソース・サーバーを定義します。OAuthサービスには、「ユーザー・プロファイル・サービス」と「承認管理サービス」という、2つの組込みリソース・サーバーも含まれています。
スコープとユーザーの承認
リソース・サーバー構成ページは、アクセス・リクエスト・スコープを定義する場所で、リクエストされたリソースに対してクライアントが持つアクセス範囲を決定します。この設定に基づいて、認可サーバーはアクセスを制限し、発行されるアクセス・トークンのスコープをクライアントに知らせます。
アクセス・サービスにより、認可リクエストとトークン・リクエストの両方を処理する際にスコープ・チェックが実行されます。クライアントは、認可リクエストの一環としてスコープ・パラメータを送信します。スコープ・パラメータ値の一部が無効な場合、OAuthサーバーはクライアント・アプリケーションに、エラー・テキストinvalid_scope
とともに不正なリクエスト(コード400)エラー・レスポンスを送信します。
リソース・サーバー構成ページは、「ユーザー承認が必要」オプションを選択する場所でもあります。このオプションは、認可サーバーにユーザー承認フォームを表示するよう要求し、ユーザーがリクエストされたリソースへのアクセスを承認(または拒否)できるようにします。「ユーザー承認が必要」オプションは、スコープごとに有効にできます。たとえば、書込みアクセスは許可するが、読取りアクセスは許可しないスコープ・リクエストに対してユーザー承認を要求できます。
注意: 「OAuthクライアント構成」ページには、「ユーザー承認をバイパス」オプションがあります。このオプションが選択されると、クライアント設定はリソース・サーバー設定をオーバーライドします。 |
ユーザー・プロファイル・リソース・サービス
Oracle User Profile Resource Serviceは、Oracle Access Management OAuthサーバーに含まれているネイティブ・リソース・サーバーです。このサービスにより、組織はOAuth 2.0を使用してユーザー・プロファイル・サービスと相互作用できます(第41.2.5項「ユーザー・プロファイル・サービスの概要」を参照)。このサービスにより、OAuth 2.0を使用してバックエンド・ディレクトリ・サーバーと相互作用できるようになり、個人、グループおよびリレーションシップ・エンティティで次のユーザー・プロファイルREST操作を実行します。
作成
更新
Delete
読取り
検索
ユーザー・プロファイル・サービスは、個人、グループおよびリレーションシップ・エンティティのサービス固有のエンドポイントを使用して、HTTPSリクエストを受信し、応答します。各サービス・エンドポイントは、必要でない場合は個別に無効にできます。
次の表は、ユーザー・プロファイル・リソース・サーバーと相互作用するためにOAuthクライアントが使用できるHTTP(S)メソッドとユーザー・プロファイル属性をまとめたものです。
表46-1 ユーザー・プロファイル・リソース・サーバー: リソース・カテゴリ
リソース・カテゴリ | HTTP(S)メソッド | リソース・エンドポイント | 使用の詳細 |
---|---|---|---|
|
GET PUT |
|
OAuthクライアントは、指定されたユーザー・プロファイルの読取りおよび更新権限をリクエストできます。 |
|
GET POST PUT DELETE |
|
OAuthクライアントは、任意のユーザー・プロファイルの作成、読取り、検索、更新および削除権限をリクエストできます。 |
|
GET POST PUT DELETE |
|
OAuthクライアントは、任意のグループ・プロファイルの作成、読取り、検索、更新および削除権限をリクエストできます。 |
|
POST PUT DELETE |
|
表46-2 ユーザー・プロファイル・リソース・サーバー: スコープ設定
スコープ | HTTP(S)メソッド | リソース・カテゴリ | 属性 |
---|---|---|---|
|
GET PUT |
|
|
|
GET POST PUT DELETE |
|
|
|
GET POST PUT DELETE |
|
|
|
POST PUT DELETE |
|
クライアント・プロファイル・ページを使用して、OAuthサービスにクライアントを登録します。OAuthクライアントは、プロトコルを開始する前に、OAuthサーバーに登録する必要があります。アプリケーション名、クライアント・シークレット、およびアクセスが付与または拒否されたときにOAuthサーバーがユーザー・エージェントをクライアントにリダイレクトするために使用する1つ以上のリダイレクトURIを入力します。
OAuthサービスまたはシステム管理者は各クライアントにクライアント識別子を発行します。このIDは、OAuthクライアントに提供される登録情報を表す一意の文字列です。
次の2つのタイプのOAuthクライアントを定義できます。
Web: クライアントID、シークレットおよび1つ以上のHTTPリダイレクトURIが必要です。
モバイル: クライアントID、1つ以上のモバイル・リダイレクトURIおよびモバイルOAuthの実装固有の属性が必要です。
権限
許容されるスコープを構成し、クライアントごとにユーザー承認の必要性をバイパスできます。アクセス・トークンを取得する前に、クライアントはアクセス・トークンのためにOAuthサービスと交換可能な認可権限を取得する必要があります。クライアント権限により、どのクライアントがどの権限タイプを許可されるかが決定されます。OAuth 2.0仕様は、様々なセキュリティ・ユースケースにいくつかの認可権限タイプを提供します。
注意: OAuth権限タイプの詳細は、OAuth 2.0標準を定義するIETF RFC 6749 (http://tools.ietf.org/html/rfc6749#section-1.3 )を参照してください。 |
OAM OAuthサービスでは、次の権限タイプがサポートされています。
認可コード: リソース所有者は認可サーバーを使用してログインします。トークン・エンドポイントはクライアント資格証明とともに認可コードをアクセス・トークンと交換します。
リソース所有者の資格証明: リソース所有者はクライアントにユーザー名とパスワードを提供します。クライアントがパスワードを乱用したり、パスワードが誤って攻撃者に開示される可能性があるため、これは信頼性の高いクライアント・アプリケーションにのみ適しています。OAuth 2.0仕様ごとに、認可サーバーおよびクライアントは、この権限タイプの使用を最小限に抑え、可能な場合は常に他の権限タイプを利用する必要があります。
クライアント資格証明: クライアントはそのクライアント資格証明のみ(または他のサポートされている認証手段)を使用してアクセス・トークンをリクエストします。これは、クライアントがその制御下、または認可サーバーで前に調整されたときの別のリソース所有者の制御下にある保護されているリソースへのアクセスをリクエストしている場合に適しています。
OAuth 2.0標準で定義されるOAuth権限タイプに加え、次のオプションも使用可能です。
リフレッシュ・トークン: このオプションを選択すると、トークン・レスポンスでアクセス・トークンとともにリフレッシュ・トークンを返します。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
JWTベアラー: OAuthアクセス・トークンのリクエストにJWTアサーションを使用できます。
SAML 2ベアラー: OAuthアクセス・トークンのリクエストにSAML2アサーションを使用できます。
OAM資格証明: マスター・トークン、アクセス・トークン、OAuthアクセス・トークンなど、OAMトークンのリクエストに使用します。
クライアント検証コード: モバイル・クライアントがOAuthサーバーから事前検証コードをリクエストするために使用します。その後、OAuthサーバーは使用されたモバイル・クライアント・フローを取得します。
「承認管理サービス」構成ページは、「リソース・サーバー」タブから開きます。デフォルトの承認管理サービスは承認の格納、取得、失効および承認検証操作を処理します。承認データはOracle Access Managementデータベースに格納されます。
OAuth認可サーバーは、アクセス・トークンにカスタム属性を埋め込むことができます。次の2つの属性タイプ、静的属性および動的属性を定義できます。
静的属性: 属性の定義時に値が固定される属性名と値のペア。例: name1=value1
動的属性: ユーザープロファイル固有の属性。「OAuthサービス・プロファイル構成」ページの「ユーザー・ストア」設定を構成することもできます。この設定は、ユーザー・プロファイル属性のソースを定義します。ユーザー・プロファイル・サービス(および/または基礎となるIDSインタフェース)を使用して、属性の名前と値を取得できます。動的属性はユーザーに関連するため、ユーザー承認ページ(構成されている場合)には、構成された属性がクライアントおよびリソースと共有されていることが示されます。
次のOAuthサービス構成オブジェクトを使用して静的属性および動的属性を定義できます。
OAuthサービス・プロファイル
リソース・サーバー
カスタム属性の構成時には、次のガイドラインに従ってください。
静的属性および動的属性に同じ名前を使用しないでください。
サービス・プロファイル構成およびスコープ構成にカスタム属性を追加する際には同じ名前を使用しないでください。両方の場所に同じ属性名を定義する場合は、スコープベースの属性値が優先されます。
カスタム属性はアクセス・トークンの要求として表示されます。JWTベースのアクセス・トークンにはOAuthサーバー固有の要求とともに標準のJWT要求が含まれます。例:
標準
"exp":1357596398000, "iat":1357589198000, "aud":"oam_server1", "iss":"OAuthServiceProfile", "prn":null, "jti":"340c8324-e49f-43cb-ba95-837eb419e068",
OAuthサーバー固有
"oracle.oauth.user_origin_id":"john101", "oracle.oauth.user_origin_id_type":"LDAP_UID", "oracle:idm:claims:client:macaddress":"1C:AB:A7:A5:F0:DC", "oracle.oauth.scope":"brokerage", "oracle.oauth.client_origin_id":"oauthssoapp1id", "oracle.oauth.grant_type":"oracle-idm:/oauth/grant-type/resource-access-token/jwt"
これらの要求は、OAuthサーバーで生成されたアクセス・トークンの一部として使用できます。カスタム属性はJWTベースのアクセス・トークンで要求として表示されるため、次の名前付け制限が適用されます。
JWT標準要求名は使用しないでください。
Oracle接頭辞が付く名前は使用しないでください(前述のとおり)。
この項では、OAuthサービス・トランザクションの保護に役立つ機能およびオプションについて簡単に説明します。
IDとシークレット
OAuthサービスでは、クライアントの登録時にクライアント・シークレットが必要です。登録時に、クライアントごとに一意のクライアントIDを作成します。(必要な場合は、システムがかわりに作成することもできます。)OAuthサービスは、格納されている値を、HTTPSまたはHTTPを介してOAuthサービスのエンドポイントと相互作用する際にクライアントが送信する値と比較します。値が一致しない場合、リクエストは否認されます。クライアント・シークレットは、認可ヘッダーとして送信されるBase64の値です。
クライアントはOAuthサーバーに認可リクエストの一環としてクライアントIDを送信し、OAuthサーバーはトークン・エンドポイント・リクエストでクライアントIDとクライアント・シークレットを送信します。
OAuthプラグイン
追加のセキュリティを提供するために、オプションのプラグインを構成できます。
アダプティブ・アクセス・プラグイン: 不正検出とリスク分析ポリシー・チェックを実行し、確実性とユーザーの信頼度が向上します。
トークン属性プラグイン: トークン・サービス・プロバイダの周囲のセキュリティ・ポリシーを定義します。
認可および承認サービス・プラグイン: 認可およびユーザー承認が付与される相互作用周囲のセキュリティ・ポリシーを定義します。このプラグインは、生成されたトークンの要求にも影響を及ぼす可能性があります。
OAuthアイデンティティ・ドメイン内で、クライアント・プラグインは、OAuthクライアントのセキュリティ・ポリシーを定義し、リソース・サーバー・プロファイル・プラグインはリソース・サーバーのセキュリティ・ポリシーを定義します。
ジェイルブレーク検出ポリシー
iOSデバイス用事前構成済ジェイルブレーク検出ポリシーは、デバイスがジェイルブレークされていることを示すファイルを検索し、そのファイルが見つかった場合は、OAuthフローへのデバイス・アクセスを拒否できます。
モバイル・セキュリティ
モバイル・セキュリティの詳細は、第41章「Mobile and Socialの理解」のモバイルOAuth認可フローの図を参照してください。
標準OAuthセキュリティ
OAuth 2.0仕様で提供されるセキュリティ対策も適用されます。
OAuthセキュリティに関する考慮事項の詳細は、IETF RFC 6749のセクション10 (http://tools.ietf.org/html/rfc6749#section-10
)を参照してください。
この項では、ユーザー・インタフェースを使用してOAuthサービスを構成する方法について説明します。次のトピックが含まれます:
OAuthアイデンティティ・ドメインの概要は、第46.3.1項「OAuthアイデンティティ・ドメイン構成の理解」を参照してください。次の項では、ユーザー・インタフェースを使用してOAuthアイデンティティ・ドメインを構成する方法について説明します。次のトピックが含まれます:
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開きます。
次のいずれかを選択します。
基本情報のみを使用してアイデンティティ・ドメインを簡単に作成する場合は、「作成」をクリックします。
「アイデンティティ・ドメインの構成」ページが開きます。
フォームに入力して、「作成」をクリックし、変更内容を保存します。追加の構成詳細を後で指定する必要があります。
アイデンティティ・ドメインを作成し、なおかつ重要なサービス・プロファイル設定を構成する場合は、ウィザード・フロー・ボタンをクリックします。
「OAuthアイデンティティ・ドメインの作成」ウィザード・フロー・ページが開きます。
ウィザード・フローを前後に移動するには、「戻る」および「次」をクリックします。「終了」をクリックして、変更内容を保存します。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthアイデンティティ・ドメイン」ページを開きます。
アイデンティティ・ドメインを表示または編集するには、表内でその名前をクリックします。
アイデンティティ・ドメインを削除するには、ドメイン名の左側の列をクリックしてそれを選択し、コマンド・バーの削除ボタンをクリックします。
この項では、既存のアイデンティティ・ドメインを表示したり、新しいアイデンティティ・ドメインを作成するときの「アイデンティティ・ドメインの構成」の「サマリー」タブのフォーム・フィールドについて説明します。
アイデンティティ・ドメイン: アイデンティティ・ドメインの名前。アイデンティティ・ドメインを作成または編集する場合は、スペースなしに一意の名前を入力します。
説明: (オプション)自分または別の管理者が将来このアイデンティティ・ドメインを識別する際に役立つ簡単な説明。
IdentityドメインのUUID: インターネット上でこのアイデンティティ・ドメインを一意に識別する識別コード。汎用一意識別子コードをこのフィールドに移入するには、「生成」をクリックします。
複数のリソース・サーバーを許可する: アイデンティティ・ドメインが複数のリソース・サーバーをサポートする場合は、このオプションを選択します。
モバイルの有効化: アイデンティティ・ドメインがモバイル・クライアントをサポートする場合は、このオプションを選択します。このオプションの選択が解除されると、モバイル・サービス構成設定は、このアイデンティティ・ドメインのユーザー・インタフェースで使用できなくなります。
サービス構成
これらのフィールドは、「アイデンティティ・ドメインの作成」ページに表示されます。
サービス・プロファイル名: アイデンティティ・ドメインのサービス・プロファイルの名前。各アイデンティティ・ドメインには少なくとも1つのサービス・プロファイルが必要です。詳細は、第46.3.3項「OAuthサービス・プロファイル構成の理解」を参照してください。
ユーザー・プロファイル・サービス名: アイデンティティ・ドメインのユーザー・プロファイル・サービスの名前。ユーザー・プロファイル・サービスは、アイデンティティ・ドメインごとに自動的に作成されます。詳細は、第46.3.4項「OAuthリソース・サーバー構成の理解」を参照してください。
承認管理サービス名: アイデンティティ・ドメインの承認管理サービスの名前。各アイデンティティ・ドメインには承認管理サービスが必要です。このサービスは、承認レコードを格納および取得し、承認検証および承認失効操作を実行します。詳細は、第46.3.6項「OAuth承認管理サービス構成の理解」を参照してください。
サービス・プロファイル・エンドポイント: このアイデンティティ・ドメインのOAuth認可サービスが認可リクエストに応答するURL。
ユーザー・プロファイル・サービス・エンドポイント: ユーザー・プロファイル・サービスがリクエストの作成、読取り、更新および削除を行うために受信し、応答するURL。
承認管理サービス・エンドポイント: 承認管理サービスがクライアントおよびリソース所有者サービス・リクエストを受信し、応答するURL。
「OAuthアイデンティティ・ドメインの作成」ウィザード・ページのフォーム・フィールドを理解するには、次の各項を参照してください。
情報: 詳細は、第46.4.1.3項「「アイデンティティ・ドメインの構成」ページ: 「サマリー」タブの理解」を参照してください。
サービス・プロファイル: 詳細は、第46.4.2.3項「OAuthサービス・プロファイルの構成ページの理解」を参照してください。
モバイル・サービス: 詳細は、第46.4.2.3項の「モバイル・サービスの設定」を参照してください。
トークン: 詳細は、第46.4.2.3項の「トークン設定」を参照してください。
サマリー: 設定を確認し、「終了」をクリックして、アイデンティティ・ドメインを作成します。
OAuthサービス・プロファイルの概要は、第46.3.3項「OAuthサービス・プロファイル構成の理解」を参照してください。次の項では、ユーザー・インタフェースを使用してOAuthサービス・プロファイルを構成する方法について説明します。次のトピックが含まれます:
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして開きます。
「OAuthサービス・プロファイル」タブをクリックします。
「作成」ボタンをクリックして、ウィザードを完了します。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして編集用に開きます。
「OAuthサービス・プロファイル」タブをクリックします。
次を実行します。
サービス・プロファイルを編集するには、表内でその名前をクリックします。
サービス・プロファイルを削除するには、名前の左側のボックスをクリックしてそれを選択し、コマンド・バーの削除ボタンをクリックします。
アイデンティティ・ドメイン: このサービス・プロファイルが適用されるアイデンティティ・ドメインの名前。(読取り専用)
名前: このサービス・プロファイルの名前。
説明: (オプション)自分または別の管理者が将来このサービス・プロファイルを識別する際に役立つ簡単な説明。
サービス有効: 選択すると、サービス・プロファイルがアクティブになり、オプション・ボックスの選択を解除すると、非アクティブになります。
サービス・プロバイダ: このOAuthサービス・プロファイルに対応するOAuthサービス・プロバイダの名前。
サービス・エンドポイント: OAuth認可サービスが認可リクエストに応答するURL。
ユーザー・ストア
ユーザー・オーセンティケータ: ユーザー認証の場合、Oracle Access Managementのトークン・プロバイダを使用するには「OAM」を選択し、アイデンティティ・ディレクトリ・サービスのトークン・プロバイダを使用するには「IDS」を選択します。OAMトークンが使用されない場合はIDS認証のみを選択します(たとえば、JWTトークンのみが使用される場合)。OAMとJWTトークンの両方が使用される場合、IDSとOAMの両方で送信される重複認証試行を避けるために、OAM認証を選択します。
アイデンティティ・ストア名: IDSがユーザー・オーセンティケータとして構成される場合のアイデンティティ・ストアの名前。
プラグイン
次のカテゴリのメニューから使用可能なプラグインを選択します。
アダプティブ・アクセス: Oracle Adaptive Access Manager (OAAM)不正検出とリスク分析ポリシー・チェックを実行し、確実性とユーザーの信頼度が向上します。
トークン属性: トークン・サービス・プロバイダの周囲のセキュリティ・ポリシーを定義します。
クライアント: 機密クライアント認証、クライアント認可およびクライアント・プロファイルの読取りを外部セキュリティ・モジュールに委任します。
リソース・サーバー・プロファイル: 機密リソース・サーバー認証、リソース・サーバー認可およびリソース・サーバー・プロファイルの読取りを外部セキュリティ・モジュールに委任します。
承認管理サービス: 認可およびユーザー承認が付与される相互作用周囲のセキュリティ・ポリシーを定義します。このプラグインは、生成されたトークンの要求にも影響を及ぼす可能性があります。
属性
サービス・プロファイル属性とその値を追加または削除して、さらにOAuthサービス・プロファイルを構成します。
JWTトークンの生成および検証の場合、次のパラメータを構成します。
jwt.cert.alias
jwt.trusted.issuer.size
jwt.trusted.issuer.1
jwt.trusted.issuer.2
表46-3 OAuthサービス・プロファイル構成の属性
名前 | 値 | 注意 |
---|---|---|
|
キーストアの署名証明書のための秘密鍵の別名。この属性が指定されていない場合、デフォルトの別名が使用されます。 |
|
|
|
JWTトークンのコンテンツへの署名に使用する暗号アルゴリズム。デフォルト値は |
|
|
このトークンの発行者(つまり、OAuthサーバーによって生成されたJWTトークンの |
|
2 |
信頼できる発行者の数。この値は信頼できる発行者の任意の数に設定できます。たとえば、数が2の場合、次のパラメータもこれに合せて指定する必要があります。 |
|
キーストアの1つ目の信頼できる発行者の公開鍵の別名。詳細は、 |
|
|
キーストアの2つ目の信頼できる発行者の公開鍵の別名。詳細は、 |
|
|
|
trueに設定される場合、現在のOAuthサーバー・プロファイルはドメイン作成の一環として自動的に作成されます。そうでない場合は、手動で作成します。 |
|
|
trueに設定される場合、クライアントIDおよびシークレットをOAuthサーバーと相互作用するための資格証明として使用できます。 |
|
|
OAuthサーバーによって発行されたトークンのテナント要求名。デフォルトで、これはアイデンティティ・ドメイン名を使用して設定されます。 |
|
指定される値 |
デフォルトで、これは |
|
指定される値(秒単位) |
デフォルト値は |
|
|
デフォルトで |
モバイル・サービスの設定
サポートされているプラットフォーム: 「iOS」、「Android」および/または「その他」を選択します。
iOS: 選択した場合、認可サーバーは、iOSクライアントからのリクエストを受け入れます。
Android: 選択した場合、認可サーバーは、Androidクライアントからのリクエストを受け入れます。
その他: 選択した場合、認可サーバーは、iOSまたはAndroid以外のクライアントからのリクエストを受け入れます。
iOSセキュリティ・レベル: 「高」、「中」または「低」を選択します。
詳細: クライアント登録およびトークン取得はすべて、プッシュ通知とHTTP(S)の両方を使用して行われます。
混合: クライアント登録はすべて、プッシュ通知とHTTP(S)の両方を使用して行われ、アクセス・トークンの取得はHTTP(S)のみを使用して行われます。
標準: クライアント登録およびトークン取得はすべて、HTTP(S)を使用して行われます。
Androidセキュリティ・レベル: 「高」、「中」または「低」を選択します。
詳細: クライアント登録およびトークン取得はすべて、プッシュ通知とHTTP(S)の両方を使用して行われます。
混合: クライアント登録はすべて、プッシュ通知とHTTP(S)を使用して行われ、アクセス・トークンの取得はHTTP(S)のみを使用して行われます。
標準: クライアント登録およびトークン取得はすべて、HTTP(S)を使用して行われます。
Android送信者ID: Androidプッシュ通知に必要なGCM送信者IDを入力します。
Android APIキー: Androidプッシュ通知に必要なAPIキーを入力します。
承認サービス保護: 認可リクエストは承認サービスにルーティングされます。ユーザーはこの承認サービスにログインして、承認する必要があります。承認ページ保護にOracle Access Managementまたはサード・パーティ・オプションのいずれかを使用するには、OAMまたはサード・パーティ・アクセス管理を選択します。承認ページ保護にOAuthサーバー自体を使用するには、このオプションの選択を解除します。承認ページ保護にOAuthサーバーを使用する場合、認証フローは「ユーザー・ストア」設定で決定されます。
クライアント登録にはユーザー承認が必要: モバイル・デバイス上に各モバイルOAuthアプリケーション・インストール・インスタンスを登録する前にユーザーが認可する必要がある場合は、このオプションを選択します。
優先ハードウェアID: モバイル・デバイスを一意に識別するために使用する必要があるハードウェアID属性の優先させるには、このリストを使用します。リストから使用可能な最初のハードウェアIDが使用されます。
モバイル・クライアント属性: 次の表に基づいてモバイル・クライアント属性およびその値を追加または削除します。
表46-4 モバイル・クライアント属性名と値
名前 | 値 | 注意 |
---|---|---|
|
|
サポートされる値は、 |
クライアント
すべてのクライアントにアクセスを許可する: アイデンティティ・ドメインのすべてのクライアントがこのサービス・プロファイルを使用する必要がある場合に選択します。サービス・プロファイルにアクセス可能なクライアントを選択する場合は、このオプションの選択を解除します。
クライアント: サービス・プロファイルにアクセス可能なクライアントを表に追加します。「クライアントの参照」をクリックして、「クライアント」表に追加するクライアントを選択します。異なるサービス・プロファイルにクライアントを割り当てるには、クライアント名の左側にあるボックスをクリックして、「削除」をクリックします。
トークン設定
このタブを使用して、トークン設定の他、OAuthサービスがアクセス・トークンに埋め込む必要があるカスタム属性の設定を構成します。
トークン
トークン名: トークンの名前。
期限切れ: トークンの有効期限が切れるまでの時間(分単位)。
リフレッシュ・トークン有効: このオプションを選択すると、リフレッシュ・トークンが使用可能になります。リフレッシュ・トークンは、クライアント検証コードまたは認可コードでは使用できません。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
リフレッシュ・トークンの有効期限: リフレッシュ・トークンの有効期限が切れるまでの時間(分単位)。
ライフサイクル有効: OAuthサーバーがトークンをキャッシュし、それを有効期限が切れるまでデータベースに保存する必要がある場合はこのオプションを選択します。
カスタム属性
このセクションを使用して、OAuthサービスがアクセス・トークンに埋め込むカスタム属性を定義します。カスタム属性の詳細は、第46.3.7項「OAuthアクセス・トークン・カスタム属性の理解」を参照してください。
静的属性: 属性の定義時に値が固定される属性名と値のペア。例: name1=value1
動的属性: ユーザープロファイル固有の属性。
カスタム・リソース・サーバー
このタブを使用して、クライアントがアクセス権を持つ必要があるカスタム・リソース・サーバーを選択します。カスタム・リソース・サーバーは、OAuthサービスに含まれるユーザー・プロファイルおよび承認管理リソース・サーバーではない任意のリソース・サーバーです。
クライアントにすべてのリソース・サーバーへのアクセスを許可する: クライアントがアイデンティティ・ドメインで構成されているすべてのリソース・サーバーにアクセスできるようにする場合に選択します。アクセス可能なリソース・サーバー・クライアントを選択する場合は、このオプションの選択を解除します。
カスタム・リソース・サーバー: 矢印を使用して、クライアントがアクセス可能にする必要のあるリソース・サーバーを「使用可能なサーバー」ボックスから「選択されたサーバー」ボックスに移動します。(このオプションは、「クライアントにすべてのリソース・サーバーへのアクセスを許可する」オプションが選択されていない場合にのみ使用できます。)
システム・リソース・サーバー
このタブを使用して、クライアントがユーザー・プロファイル・サービスや承認管理サービスへのアクセス権を持つ必要があるかどうかを構成します。
ユーザー・プロファイル・サービス: 矢印を使用して、クライアントがアクセスできる必要があるユーザー・プロファイル・サーバーを「使用可能なサーバー」ボックスから「選択されたサーバー」ボックスに移動します。「選択されたサーバー」ボックスにリストされたサービスは、アクティブなサービスです。
承認管理サービス: 矢印を使用して、クライアントがアクセスできる必要がある承認管理サーバーを「使用可能なサーバー」ボックスから「選択されたサーバー」ボックスに移動します。「選択されたサーバー」ボックスにリストされたサービスは、アクティブなサービスです。
OAuthクライアントの概要は、第46.3.5項「OAuthクライアント・プロファイル構成の理解」を参照してください。次の項では、ユーザー・インタフェースを使用してOAuth WebクライアントおよびOAuthモバイル・クライアントを構成する方法について説明します。次のトピックが含まれます:
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして開きます。
「OAuthクライアント」タブをクリックします。
OAuth Web (非モバイル)クライアントを作成するには、「OAuth Webクライアント」見出しの真下にある「作成」ボタンをクリックして、フォームに入力します。
OAuthモバイル・クライアントを作成するには、「OAuthモバイル・クライアント」見出しの真下にある「作成」ボタンをクリックして、フォームに入力します。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして編集用に開きます。
「OAuthクライアント」タブをクリックします。
次を実行します。
クライアント構成を編集するには、そのページでその名前をクリックします。
新しいタブでクライアント構成ページが開きます。
クライアントを削除するには、名前の左側のボックスをクリックしてそれを選択し、コマンド・バーの削除ボタンをクリックします。
この項では、既存のOAuth Webクライアントを表示するか、新しいOAuth Webクライアントを作成するときの「OAuth Webクライアント構成」ページのフォーム・フィールドについて説明します。
アイデンティティ・ドメイン: このOAuth Webクライアントが登録されているアイデンティティ・ドメインの名前。(読取り専用)
名前: このOAuthクライアントの名前。
説明: (オプション)自分または別の管理者が将来このOAuth Webクライアントを識別する際に役立つ簡単な説明。
HTTPリダイレクトURI: アクセスが付与または拒否されたときにOAuthサーバーがユーザー・エージェントをリダイレクトすることを許可されるクライアントURI。
クライアントID: 認可サーバーが登録時にこのクライアントに作成した一意のID。(読取り専用)。
トークン属性の取得を許可する: カスタム属性(属性名と値の両方)がリソース・サーバーおよびリソース所有者で共有されるようにするには、このオプションを選択します。カスタム属性の詳細は、第46.3.7項「OAuthアクセス・トークン・カスタム属性の理解」を参照してください。
クライアント・シークレット: OAuth認可サービスおよびクライアントに認識されているシークレット値。認可サービスは、クライアントからトークン・エンドポイント・リクエストを受信するときに、クライアント・シークレットとクライアントIDを確認します。
権限
ユーザー承認をバイパス: 選択した場合、クライアントは、ユーザーの保護されたリソースにアクセスするために、そのユーザーの明示的な許可を求めません。このオプションを選択した場合、この設定はリソース・サーバー設定をオーバーライドします。クライアントがリソース・サーバー設定に従う場合は、このオプションの選択を解除します。
すべてのスコープにアクセスを許可する: 選択した場合、アイデンティティ・ドメインのリソース・サーバーのスコープ制限にかかわらず、クライアントはアクセス・トークンを取得できます。クライアントがスコープ制限に従う場合は、このオプションの選択を解除します。
許可されているスコープ: クライアントがリクエストされたリソースに対して所有するアクセス権の範囲をリストします。追加のアクセス権を付与するには、「追加」をクリックして、表に行を追加し、ドロップダウン・メニューから追加するスコープを選択します。アクセスを制限するには、表の行をクリックして削除するスコープを選択し、「削除」をクリックして、強調表示された行を削除します。選択したスコープを削除することを確認するプロンプトで、「OK」をクリックします。
権限タイプ: OAuth 2.0仕様は、様々なセキュリティ・ユースケースにいくつかの認可権限タイプを提供します。アクセス・トークンを取得する前に、クライアントはアクセス・トークンのためにOAuthサービスと交換可能な認可権限を取得する必要があります。クライアント権限により、どのクライアントがどの権限タイプを許可されるかが決定されます。OAM OAuthサービスでは、次の権限タイプがサポートされています。
認可コード: リソース所有者は認可サーバーを使用してログインします。トークン・エンドポイントはクライアント資格証明とともに認可コードをアクセス・トークンと交換します。
リソース所有者の資格証明: リソース所有者はクライアントにユーザー名とパスワードを提供します。クライアントがパスワードを乱用したり、パスワードが誤って攻撃者に開示される可能性があるため、これは信頼性の高いクライアント・アプリケーションにのみ適しています。OAuth 2.0仕様ごとに、認可サーバーおよびクライアントは、この権限タイプの使用を最小限に抑え、可能な場合は常に他の権限タイプを利用する必要があります。
クライアント資格証明: クライアントはそのクライアント資格証明のみ(または他のサポートされている認証手段)を使用してアクセス・トークンをリクエストします。これは、クライアントがその制御下、または認可サーバーで前に調整されたときの別のリソース所有者の制御下にある保護されているリソースへのアクセスをリクエストしている場合に適しています。
OAuth 2.0標準で定義されるOAuth権限タイプに加え、次のオプションも使用可能です。
リフレッシュ・トークン: このオプションを選択すると、トークン・レスポンスでアクセス・トークンとともにリフレッシュ・トークンを返します。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
JWTベアラー: OAuthアクセス・トークンのリクエストにJWTアサーションを使用できます。
SAML 2ベアラー: OAuthアクセス・トークンのリクエストにSAML2アサーションを使用できます。
OAM資格証明: マスター・トークン、アクセス・トークン、OAuthアクセス・トークンなど、OAMトークンのリクエストに使用します。
クライアント検証コード: モバイル・クライアントがOAuthサーバーから事前検証コードをリクエストするために使用します。その後、OAuthサーバーは使用されたモバイル・クライアント・フローを取得します。
属性
認可サーバーがスコープ設定とともにクライアントに返すカスタム属性を追加または削除します。
サービス・プロファイル構成およびスコープ構成にカスタム属性を追加する際には同じ名前を使用しないでください。両方の場所に同じ属性名を定義する場合は、スコープベースの属性値が優先されます。
この項では、既存のOAuth Webクライアントを表示するか、新しいOAuth Webクライアントを作成するときの「OAuth Webクライアント構成」ページのフォーム・フィールドについて説明します。
アイデンティティ・ドメイン: このOAuthモバイル・クライアントが登録されているアイデンティティ・ドメインの名前。(読取り専用)
名前: このOAuthクライアントの名前。
説明: (オプション)自分または別の管理者が将来このOAuthモバイル・クライアントを識別する際に役立つ簡単な説明。
クライアントID: 認可サーバーが登録時にこのクライアントに作成した一意のID。(読取り専用)。
トークン属性の取得を許可する: カスタム属性(属性名と値の両方)がリソース・サーバーおよびリソース所有者で共有されるようにするには、このオプションを選択します。カスタム属性の詳細は、第46.3.7項「OAuthアクセス・トークン・カスタム属性の理解」を参照してください。
ジェイルブレーク検出: モバイル・デバイスのジェイルブレーク検出を有効にする場合に選択します。詳細は、「ジェイルブレーク検出ポリシー」を参照してください。
モバイル・リダイレクトURI: アクセスが付与または拒否されたときにOAuthサーバーがユーザー・エージェントをリダイレクトすることを許可されるクライアントURI。
権限
ユーザー承認をバイパス: 選択した場合、クライアントは、ユーザーの保護されたリソースにアクセスするために、そのユーザーの明示的な許可を求めません。このオプションを選択した場合、この設定はリソース・サーバー設定をオーバーライドします。クライアントがリソース・サーバー設定に従う場合は、このオプションの選択を解除します。
すべてのスコープにアクセスを許可する: 選択した場合、アイデンティティ・ドメインのリソース・サーバーのスコープ制限にかかわらず、クライアントはアクセス・トークンを取得できます。クライアントがスコープ制限に従う場合は、このオプションの選択を解除します。
許可されているスコープ: クライアントがリクエストされたリソースに対して所有するアクセス権の範囲をリストします。追加のアクセス権を付与するには、「追加」をクリックして、表に行を追加し、ドロップダウン・メニューから追加するスコープを選択します。アクセスを制限するには、表の行をクリックして削除するスコープを選択し、「削除」をクリックして、強調表示された行を削除します。選択したスコープを削除することを確認するプロンプトで、「OK」をクリックします。
権限タイプ: OAuth 2.0仕様は、様々なセキュリティ・ユースケースにいくつかの認可権限タイプを提供します。アクセス・トークンを取得する前に、クライアントはアクセス・トークンのためにOAuthサービスと交換可能な認可権限を取得する必要があります。クライアント権限により、どのクライアントがどの権限タイプを許可されるかが決定されます。OAM OAuthサービスでは、次の権限タイプがサポートされています。
認可コード: リソース所有者は認可サーバーを使用してログインします。トークン・エンドポイントはクライアント資格証明とともに認可コードをアクセス・トークンと交換します。
リソース所有者の資格証明: リソース所有者はクライアントにユーザー名とパスワードを提供します。クライアントがパスワードを乱用したり、パスワードが誤って攻撃者に開示される可能性があるため、これは信頼性の高いクライアント・アプリケーションにのみ適しています。OAuth 2.0仕様ごとに、認可サーバーおよびクライアントは、この権限タイプの使用を最小限に抑え、可能な場合は常に他の権限タイプを利用する必要があります。
クライアント資格証明: クライアントはそのクライアント資格証明のみ(または他のサポートされている認証手段)を使用してアクセス・トークンをリクエストします。これは、クライアントがその制御下、または認可サーバーで前に調整されたときの別のリソース所有者の制御下にある保護されているリソースへのアクセスをリクエストしている場合に適しています。
リフレッシュ・トークン: このオプションを選択すると、トークン・レスポンスでアクセス・トークンとともにリフレッシュ・トークンを返します。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
Apple Push Notification
iOSデバイスのみに適用されます。OAuth認可サーバーは、HTTPSを介してクライアント登録ハンドルの一部を送信し、Apple Push Notification Service (APNS)を使用してプッシュ通知を介して他の部分を送信して、トークンの配信を特定のモバイル・デバイスにインストールされた特定のアプリケーションに制限できます。次のフィールドを使用して、OAuthサーバーがこの特定のクライアント・アプリケーション用のAPNSに接続する方法を構成します。
接続設定: APNSを使用して、モバイル・クライアント・アプリケーションにセキュリティ・コードとトークンの一部を送信する場合は、「有効」を選択します。(APNSを使用して送信されない部分は、HTTPSを使用して送信されます。)このモバイル・クライアント・アプリケーションにAPNSを使用しない場合は、このオプションの選択を解除します。
最小接続プール・サイズ: 接続プールの最小接続数を指定します。
最大接続プール・サイズ: 接続プールの最大接続数を指定します。
キープ・アライブ: Apple Push Notificationキープ・アライブ値(秒単位)。
通信モード: アプリケーションの初期開発とテストにApple開発環境を使用するには「開発」を選択し、Appleの本番環境を使用するには「本番」を選択します。
開発用のSSL/TLS証明書: Apple Push Notification Serviceに対してAppleによって発行された開発用のSSL/TLS証明書に移動するには、「参照」をクリックします。
開発用証明書パスワード: Apple Push Notificationの証明書の開発用パスワードを入力します。
本番用のSSL/TLS証明書: Apple Push Notification Serviceに対してAppleによって発行された本番用のSSL/TLS証明書に移動するには、「参照」をクリックします。
本番用証明書パスワード: Apple Push Notificationの証明書の本番用パスワードを入力します。
Googleアプリケーション設定
Androidデバイスのみに適用されます。OAuth認可サーバーは、HTTPSを介してクライアント登録ハンドルの一部を送信し、Google Cloud Messaging (GCM) for Androidを使用してプッシュ通知を介して他の部分を送信して、トークンの配信を特定のモバイル・デバイスにインストールされた特定のアプリケーションに制限できます。次のフィールドを使用して、OAuthサーバーがこの特定のクライアント・アプリケーション用GCMサービスに接続する方法を構成します。
リダイレクトされたパッケージ名: Googleにより制限されるパッケージ名。
構成設定
デバイス要求属性: システムがデバイスのフィンガープリント用に収集するデバイス属性を指定します。空の場合は、システムはSDKのすべての属性を収集します。
モバイル・カスタム属性: アプリケーション・プロファイルを使用してモバイル・アプリケーションに送信されるキー値ペアを指定します。(モバイル・アプリケーションは、エンドポイント、ジェイルブレーク検出ポリシー、セキュリティ・レベル詳細など、サーバー側設定を含むアプリケーション・プロファイルをリクエストします。)
属性
認可サーバーがスコープ設定とともにクライアントに返すカスタム属性を追加または削除します。
サービス・プロファイル構成およびスコープ構成にカスタム属性を追加する際には同じ名前を使用しないでください。両方の場所に同じ属性名を定義する場合は、スコープベースの属性値が優先されます。
OAuthサービス・プロバイダの概要は、第46.3.2項「OAuthサービス・プロバイダ構成の理解」を参照してください。次の項では、ユーザー・インタフェースを使用してOAuthサービス・プロバイダを構成する方法について説明します。次のトピックが含まれます:
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして編集用に開きます。
「OAuthサービス・プロバイダ」タブをクリックします。
次を実行します。
サービス・プロバイダを編集するには、表内でその名前をクリックします。
サービス・プロバイダを削除するには、名前の左側のボックスをクリックしてそれを選択し、コマンド・バーの削除ボタンをクリックします。
この項では、「OAuthサービス・プロバイダの構成」ページのフォーム・フィールドについて説明します。
アイデンティティ・ドメイン: このOAuthサービス・プロバイダが登録されているアイデンティティ・ドメインの名前。(読取り専用)
名前: このサービス・プロバイダの名前。
説明: (オプション)自分または別の管理者がこのサービス・プロバイダを識別する際に役立つ簡単な説明。
サービス・プロバイダのJavaクラス: このサービス・プロバイダを実装するJavaクラス。
属性
表46-6の属性設定を使用して、Access ManagerとのOAuthサービス・プロバイダ接続を構成します。
表46-6 Access ManagerのOAuthサービス・プロバイダ属性
名前 | 値 | 注意 |
---|---|---|
|
|
使用しているOracle Access Managerのバージョンに応じて、 |
|
|
|
|
||
|
|
|
|
|
このAccessGateとアクセス・サーバーとの間のメッセージの暗号化方式を指定します。暗号化方式は一致している必要があります。有効な値は次のとおりです。
これらの設定を更新する際は、42.9.1.1項「簡易モードおよび証明書モードのAccess Managerと連動するモバイル・サービスの構成」を参照してください。 |
|
|
プライマリOracle Access Managementサーバーのホスト名およびポート番号を指定します。 |
|
|
このMobile and SocialインスタンスがOAM_SERVER_1と確立できる接続の最大数を指定します。デフォルト値は4です。 |
|
|
セカンダリOracle Access Managementサーバーのホスト名およびポート番号を指定します。 |
|
|
このMobile and SocialインスタンスがOAM_SERVER_2と確立できる接続の最大数を指定します。デフォルト値は4です。 |
|
|
OAuthリソース・サーバーの概要は、第46.3.4項「OAuthリソース・サーバー構成の理解」を参照してください。次の項では、ユーザー・インタフェースを使用してOAuthリソース・サーバーを構成する方法について説明します。次のトピックが含まれます:
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして開きます。
「リソース・サーバー」タブをクリックします。
次のうちから選択します。
OAuthサービスで使用するために新しいリソース・サーバーを定義するには、「カスタム・リソース・サーバー」セクションの「作成」ボタンをクリックします。
「カスタム・リソース・サーバー構成」ページが開きます。
新しいユーザー・プロファイル・サービス・インスタンスを定義するには、「ユーザー・プロファイル・サービス」セクションの「作成」ボタンをクリックします。
「OAuthユーザー・プロファイル・サービス構成」ページが開きます。
新しい承認管理サービス・インスタンスを定義するには、第46.4.7項「OAuth承認管理サービスの構成」を参照してください。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして編集用に開きます。
「リソース・サーバー」タブをクリックします。
次のうちから選択します。
編集用リソース・サーバーを開くには、それをクリックします。「カスタム・リソース・サーバー構成」ページが開きます。
編集用にOAuthユーザー・プロファイル・サービス構成を開くには、「ユーザー・プロファイル・サービス」セクションでそれをクリックします。ユーザー・プロファイル・サービス構成ページが開きます。
承認管理サービスの構成については、第46.4.7項「OAuth承認管理サービスの構成」を参照してください。
アイデンティティ・ドメイン: このリソース・サーバーが適用されるアイデンティティ・ドメインの名前。(読取り専用)
名前: このリソース・サーバー(またはリソース・サービス)の名前。
説明: (オプション)自分または別の管理者が将来このリソース・サーバーを識別する際に役立つ簡単な説明。
リソース・サーバーID: 登録時にこのリソース・サーバーに対して作成された一意のID。(読取り専用)
トークン属性の取得を許可する: カスタム属性(属性名と値の両方)がクライアントおよびリソース所有者で共有されるようにするには、このオプションを選択します。カスタム属性の詳細は、第46.3.7項「OAuthアクセス・トークン・カスタム属性の理解」を参照してください。
認可および承認サービス・プラグイン: メニューから、リソース・サーバーの認可プラグインを選択します。このプラグイン・タイプは、認可およびユーザー承認が付与される相互作用周囲のセキュリティ・ポリシーを定義します。このプラグインは、生成されたトークンの要求にも影響を及ぼす可能性があります。
スコープ
スコープ表に新しい行を追加するには、「追加」をクリックします。行を削除するには、その行をクリックして選択し、「削除」をクリックします。
名前: スコープ定義を入力します。photo.read
などのドット表記法を使用します。
説明: スコープを説明する短いメモを入力します。
ユーザー承認が必要: ユーザーがアクセス・リクエストを承認(または拒否)できるように、認可サーバーにユーザー承認フォームを表示するよう要求する場合に選択します。
オフライン・スコープ: ユーザーがオフラインか、存在しない場合にも、クライアント・アプリケーションがアクセス・トークンを取得するために使用可能なリフレッシュ・トークンをリクエストできるようにします。クライアント・アプリケーションは、リフレッシュ・トークンを使用して、リソースにアクセスするための新しいアクセス・トークンを取得します。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
トークン設定
デフォルト設定をオーバーライド: リソース・サーバー構成ページで定義されているトークン設定が「OAuthサービス・プロファイル」ページで定義されているデフォルトのトークン設定をオーバーライドする場合にこのオプションを選択します。
トークン名: トークンの名前。
期限切れ: トークンの有効期限が切れるまでの時間(分単位)。
リフレッシュ・トークン有効: このオプションを選択すると、リフレッシュ・トークンが使用可能になります。リフレッシュ・トークンは、クライアント検証コードまたは認可コードでは使用できません。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
リフレッシュ・トークンの有効期限: リフレッシュ・トークンの有効期限が切れるまでの時間(分単位)。
ライフサイクル有効: OAuthサーバーがトークンをキャッシュし、それを有効期限が切れるまでデータベースに保存する場合にこのオプションを選択します。
カスタム属性
このセクションを使用して、OAuthサービスがアクセス・トークンに埋め込むカスタム属性を定義します。カスタム属性の詳細は、第46.3.7項「OAuthアクセス・トークン・カスタム属性の理解」を参照してください。
静的属性: 属性の定義時に値が固定される属性名と値のペア。例: name1=value1
動的属性: ユーザープロファイル固有の属性。
次の項では、コンソールを使用してOAuthユーザー・サービス・プロファイル・サービスを構成する方法について説明します。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして開きます。
「リソース・サーバー」タブをクリックします。
「ユーザー・プロファイル・サービス」セクションの「作成」ボタンをクリックします。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして編集用に開きます。
「リソース・サーバー」タブをクリックします。
「ユーザー・プロファイル・サービス」セクションで、サービス名をクリックしてこれを編集します。「OAuthユーザー・プロファイル・サービス構成」ページが開きます。
このページを使用して、ユーザー・プロファイル・サービスを構成します。このサービスは、OAuth 2.0認可をサポートし、クライアントがバックエンド・ディレクトリ・サーバーと相互作用して、個人、グループおよびリレーションシップ・エンティティ上でユーザー・プロファイルREST操作を実行できるようにします。
アイデンティティ・ドメイン: このサービス・プロファイルが適用されるアイデンティティ・ドメインの名前。(読取り専用)
名前: このサービス・プロファイルの名前。
説明: (オプション)自分または別の管理者が将来このサービス・プロファイルを識別する際に役立つ簡単な説明。
リソース・サーバーID: OAuthサービスがこのユーザー・プロファイル・リソース・サーバーに対して作成した一意のID。(読取り専用)
サービス・エンドポイント: サービスがユーザー・プロファイル・サービス・リクエストの作成、読取り、更新および削除を行うために受信し、応答するURI。このサービスの一意のUniform Resource Identifier (URI)アドレスを作成します。例: localhost:5575
サービス有効: サービスを有効にする場合は選択し、サービスを無効にする場合はオプション・ボックスの選択を解除します。
トークン属性の取得を許可する: カスタム属性(属性名と値の両方)がクライアント間で共有されるようにするには、このオプションを選択します。有効な場合、ユーザー承認フォームにより、ユーザー・プロファイル固有の詳細がクライアントで共有されることがユーザーに通知されます。カスタム属性の詳細は、第46.3.7項「OAuthアクセス・トークン・カスタム属性の理解」を参照してください。
認可および承認サービス・プラグイン: メニューから、サービスの認可プラグインを選択します。このプラグイン・タイプは、認可およびユーザー承認が付与される相互作用周囲のセキュリティ・ポリシーを定義します。このプラグインは、生成されたトークンの要求にも影響を及ぼす可能性があります。
アイデンティティ・ストア名: ユーザー・レコードを含むアイデンティティ・ストアの名前。
OAuthサービス・プロファイルによる保護: メニューから、ユーザー・プロファイル・サービスを保護するOAuthサービス・プロファイルを選択します。
スコープ
個人、リレーションシップおよびグループ・エンティティの個別権限設定を構成します。サービスは、次のデフォルトのエンティティ名を使用します。
/me: クライアントにログインしたユーザーに適用される操作を指定します。
/users: 他のユーザーに適用される操作を指定します。
/groups: グループに適用される操作を指定します。
URI: スコープが定義されるURIセグメント。
読取りの許可: 選択すると、このスコープの読取り操作が許可されます。
書込みの許可: 選択すると、このスコープの書込み操作が許可されます。
匿名アクセスの許可: アクセスを制限しない場合はこのオプションを選択し、スコープ別にアクセスを制限するには、このオプションの選択を解除します。
OAuthスコープ: スコープ定義を入力します。UserProfile.me.write
などのドット表記法を使用します。
説明: スコープを説明する短いメモを入力します。
ユーザー承認が必要: ユーザーがアクセス・リクエストを承認(または拒否)できるように、認可サーバーにユーザー承認フォームを表示するよう要求する場合に選択します。
オフライン・スコープ: ユーザーがオフラインか、存在しない場合にも、クライアント・アプリケーションがアクセス・トークンを取得するために使用可能なリフレッシュ・トークンをリクエストできるようにします。クライアント・アプリケーションは、リフレッシュ・トークンを使用して、リソースにアクセスするための新しいアクセス・トークンを取得します。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
トークン設定
デフォルト設定をオーバーライド: リソース・サーバー構成ページで定義されているトークン設定が「OAuthサービス・プロファイル」ページで定義されているデフォルトのトークン設定をオーバーライドする場合にこのオプションを選択します。
トークン名: トークンの名前。
期限切れ: トークンの有効期限が切れるまでの時間(分単位)。
リフレッシュ・トークン有効: このオプションを選択すると、リフレッシュ・トークンが使用可能になります。リフレッシュ・トークンは、クライアント検証コードまたは認可コードでは使用できません。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
リフレッシュ・トークンの有効期限: リフレッシュ・トークンの有効期限が切れるまでの時間(分単位)。
ライフサイクル有効: OAuthサーバーがトークンをキャッシュし、それを有効期限が切れるまでデータベースに保存する場合にこのオプションを選択します。
属性
このセクションを使用して、ユーザー・プロファイル固有の(動的)属性を定義します。
表46-7 ユーザー・プロファイル・サービス属性
名前 | 値 | 注意 |
---|---|---|
|
|
|
|
|
|
|
|
リソースURI
このセクションを使用して、/me、/usersおよび/groupsサービスを有効または無効にし、これらのサービスのサービス・エンドポイントURIおよびプロバイダ実装クラス・パスを定義します。
サービス・エンドポイント: サービスがサービス・リクエストを受信し、応答するURI。このサービスの一意のUniform Resource Identifier (URI)アドレスを作成します。例: localhost:5575
サービス有効: サービスを有効にする場合は選択し、サービスを無効にする場合はオプション・ボックスの選択を解除します。
プロバイダ実装クラス: ユーザー・プロファイル・サービス・プロバイダを実装するJavaクラスの名前。
エンティティ: このセクションのフィールドを使用して、エンティティ関係を構成します。
名前: 定義されたエンティティの名前。
アイデンティティ・ディレクトリ・サービスの関係: エンドポイント・セグメントによってアクセスされるディレクトリ・サービスの関係を選択します。
エンドポイント: アイデンティティ・ディレクトリ・サービスの対応するデータ列にアクセスするために使用するURIセグメントを入力します。たとえば、memberOf
がエンドポイントURIである場合、
http://host:port/.../idX/memberOf
が、ID idX
を持つエンティティの関連エンティティにアクセスするためのURIです。
ソース・エンティティURI: ソース・エンティティのURI(またはURL)です。
宛先エンティティURI: 宛先エンティティのURI(またはURL)です。
再帰型をリクエストするスコープ - 関係検索で、ネストされたレベルの属性を取得するには、スコープ属性値をスコープ問合せパラメータとともに使用します。再帰的に関連エンティティにアクセスするには、使用する値を入力します。デフォルト構成では、toTop
とall
の2つのスコープ属性値が使用されます。「再帰型をリクエストするスコープ」の値が属性値all
である場合、次のREST URIの例が使用されてリクエストが実行されます。
http://host:port/.../idX/reports?scope=all
この例では、URIによって、ID idX
を持つエンティティに関連するエンティティが、それに続いて関連しているエンティティすべてとともに返されます。
属性: このセクションを使用して、ユーザー・プロファイル・エンティティ固有の(動的)属性を定義します。
OAuth承認管理サービスの概要は、第46.3.6項「OAuth承認管理サービス構成の理解」を参照してください。次の項では、ユーザー・インタフェースを使用して、承認管理サービスを構成する方法について説明します。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして開きます。
「リソース・サーバー」タブをクリックします。
「承認管理サービス」セクションの「作成」ボタンをクリックします。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして編集用に開きます。
「リソース・サーバー」タブをクリックします。
「承認管理サービス」セクションで、編集するサービス名をクリックします。「OAuth承認管理サービス構成」ページが開きます。
承認管理サービスは承認の格納、取得、失効および承認検証操作を処理します。
アイデンティティ・ドメイン: この承認管理サービスが適用されるアイデンティティ・ドメインの名前。(読取り専用)
名前: この承認管理サービスの名前。
説明: (オプション)自分または別の管理者が将来このサービスを識別する際に役立つ簡単な説明。
リソース・サーバーID: 認可サーバーが登録時にこのリソース・サーバーに作成した一意のID。(読取り専用)
サービス・エンドポイント: 承認管理サービスがクライアントおよびリソース所有者サービス・リクエストを受信し、応答するURL。
サービス有効: サービスを有効にする場合は選択し、サービスを無効にする場合はオプション・ボックスの選択を解除します。
トークン属性の取得を許可する: カスタム属性(属性名と値の両方)がクライアント、リソース・サーバーおよびリソース所有者で共有されるようにするには、このオプションを選択します。
認可および承認サービス・プラグイン: メニューから、サービスの認可プラグインを選択します。このプラグイン・タイプは、認可およびユーザー承認が付与される相互作用周囲のセキュリティ・ポリシーを定義します。このプラグインは、生成されたトークンの要求にも影響を及ぼす可能性があります。
OAuthサービス・プロファイルによる保護: メニューから、承認管理サービスを保護するOAuthサービス・プロファイルを選択します。
スコープ
URI: スコープが定義されるURIセグメント。
読取りの許可: 選択すると、このスコープの読取り操作が許可されます。
書込みの許可: 選択すると、このスコープの書込み操作が許可されます。
匿名アクセスの許可: アクセスを制限しない場合はこのオプションを選択し、スコープ別にアクセスを制限するには、このオプションの選択を解除します。
OAuthスコープ: スコープ定義を入力します。UserProfile.me.write
などのドット表記法を使用します。
説明: スコープを説明する短いメモを入力します。
ユーザー承認が必要: ユーザーがアクセス・リクエストを承認(または拒否)できるように、認可サーバーにユーザー承認フォームを表示するよう要求する場合に選択します。
オフライン・スコープ: ユーザーがオフラインか、存在しない場合にも、クライアント・アプリケーションがアクセス・トークンを取得するために使用可能なリフレッシュ・トークンをリクエストできるようにします。クライアント・アプリケーションは、リフレッシュ・トークンを使用して、リソースにアクセスするための新しいアクセス・トークンを取得します。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
トークン設定
デフォルト設定をオーバーライド: リソース・サーバー構成ページで定義されているトークン設定が「OAuthサービス・プロファイル」ページで定義されているデフォルトのトークン設定をオーバーライドする場合にこのオプションを選択します。
トークン名: トークンの名前。
期限切れ: トークンの有効期限が切れるまでの時間(分単位)。
リフレッシュ・トークン有効: このオプションを選択すると、リフレッシュ・トークンが使用可能になります。リフレッシュ・トークンは、クライアント検証コードまたは認可コードでは使用できません。詳細は、第45.2.6項「リフレッシュ・トークンの理解」を参照してください。
リフレッシュ・トークンの有効期限: リフレッシュ・トークンの有効期限が切れるまでの時間(分単位)。
ライフサイクル有効: OAuthサーバーがトークンをキャッシュし、それを有効期限が切れるまでデータベースに保存する場合にこのオプションを選択します。
属性
このセクションを使用して、カスタム属性を定義します。
リソースURI
このセクションを使用して、取得、付与および失効サービスを有効または無効にします。これらのサービスのサービス・エンドポイントURIおよびプロバイダ実装クラス・パスを定義することもできます。
サービス・エンドポイント: サービスがリクエストを受信し、応答するURI。このサービスの一意のURIアドレスを作成します。
サービス有効: サービスを有効にする場合は選択し、サービスを無効にする場合はオプション・ボックスの選択を解除します。
プロバイダ実装クラス: この承認管理サービス・プロバイダを実装するJavaクラスの名前。
このページを使用して、OAuthセキュリティ・プラグインを構成します。
「アダプティブ・アクセス・プラグイン」は、不正検出とリスク分析ポリシー・チェックを実行し、確実性とユーザーの信頼度が向上します。
「カスタム・トークン属性プラグイン」は、トークン・サービス・プロバイダ周囲のセキュリティ・ポリシーを定義します。
認可および承認サービス・プラグインは、認可およびユーザー承認が付与される相互作用周囲のセキュリティ・ポリシーを定義します。このプラグインは、生成されたトークンの要求にも影響を及ぼす可能性があります。
OAuthアイデンティティ・ドメイン内で、「クライアント・プラグイン」は、OAuthクライアントのセキュリティ・ポリシーを定義し、「リソース・サーバー・プロファイル・プラグイン」はリソース・サーバーのセキュリティ・ポリシーを定義します。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして開きます。
「OAuthプラグイン」タブをクリックします。
プラグイン・カテゴリ・セクションの「作成」ボタンをクリックします。
「プラグイン構成」ページが開きます。
「OAuthサーバー設定構成」ページを使用して、指定のアイデンティティ・ドメインの一般的なサーバー設定を構成します。
アイデンティティ・ドメイン: この構成ページの設定が適用されるアイデンティティ・ドメインの名前。(読取り専用)
HTTPプロキシ設定
プロキシ・サーバーがOAuth Token Service (プッシュ・サービス)とApple Push Notification Service (APNS)またはGoogle Cloud Messaging (GCM)サービス間に存在する場合は、次の設定を構成します。
プロキシURL - プロキシ・サーバーへの接続に使用するプロトコル(HTTPまたはHTTPS)を選択し、プロキシ・サーバーのホスト名およぴポート番号を入力します。
プロキシ認証 - プロキシ・サーバーで認証を受けるために必要なユーザー名およびパスワードを入力します。
Apple Push Notification
このアイデンティティ・ドメインに使用されるデフォルト値を構成します。「OAuthモバイル・クライアント構成」ページを使用して、アプリケーションごとにこれらの設定をカスタマイズします。
最小接続プール・サイズ: 接続プールの最小接続数を指定します。
最大接続プール・サイズ: 接続プールの最大接続数を指定します。
キープ・アライブ: Apple Push Notificationキープ・アライブ値(秒単位)。
トークン・ライフサイクル管理
検索結果の最大数: 「トークン・ライフサイクル管理」ページで返されるトークン・エントリ検索結果の最大数を指定します。
属性
属性: このセクションを使用して、カスタム属性を定義します。
ジェイルブレーク検出ポリシーの概要は、第46.4.10項「OAuthサービス・ジェイルブレーク検出ポリシーの構成」を参照してください。次の項では、ユーザー・インタフェースを使用して、ポリシーを構成する方法について説明します。
ジェイルブレーク検出: 「有効」を選択してジェイルブレーク検出ポリシーをオンにするか、このオプションの選択を解除してすべてのクライアント・アプリケーション・インスタンスに対してこの機能をオフにします。ここでジェイルブレーク検出ポリシーを有効化しても、このポリシーはアプリケーションごとに無効化できます。ここでこのポリシーを無効化すると、この機能をアプリケーションごとに有効化したり無効化したりできなくなります。
ポリシー文
ポリシー文: メニューのボタンを使用して、ポリシー文の追加、削除および並替えを行います。
ポリシー文条件
有効: ポリシー文条件をアクティブ化するには、このオプションを選択します。
最小OSバージョン: ポリシーが適用されるiOSの最低バージョン。この値が1.0である場合、ポリシーは、少なくともバージョン1.0のiOSを実行しているiOSデバイスに適用されます。
最大OSバージョン: ポリシーが適用されるiOSの最高バージョン。値が空の場合、最高iOSバージョン番号が確認されず、ポリシーは、「最低OSバージョン」で指定した値よりも上位のすべてのiOSバージョンに適用されます。
最小クライアントSDKバージョン: Mobile and SocialクライアントSDKの最低バージョン番号。たとえば、11.1.2.0.0などです。
最大クライアントSDKバージョン: Mobile and SocialクライアントSDKの最高バージョン番号。11.1.2.2.0などです。
ポリシー文検出ロジック
ポリシー有効期間: モバイル・クライアント・デバイス上のSDKが、ポリシーのローカル・コピーの期限が切れて新しいバージョンを取得するまで待機する時間の長さを秒単位で入力します。
自動チェック期間: クライアント・デバイスが、ジェイルブレーク検出ポリシー文を再び実行するまで待機する時間の間隔を分単位で入力します。
検出ロケーション - iOSクライアント・デバイスが、論理OR演算子を使用してポリシー文を評価します。次のように、検出ロケーションを追加します。
ファイル・パス - 検出ポリシーによって検索されるデバイス上のファイルまたはディレクトリの絶対パスを入力します。
アクション - 「存在」を選択します。それにより、それがファイル・パスにアクセスできるかどうかを評価するように検出ポリシーに指示します。
成功 - 指定したファイルまたはディレクトリがデバイス上に見つかったときに、ポリシーによってジェイルブレーク済としてそのデバイスにフラグを設定する場合に選択します。ポリシーが、認可されていないファイルまたはディレクトリについて確認している場合は、このオプションを使用します。指定したファイルまたはディレクトリが見つからないときに、ポリシーによってジェイルブレーク済としてそのデバイスにフラグを設定する場合は、このオプションの選択を解除します。(必須のファイルまたはディレクトリについて確認している場合は、このオプションを使用します。)
この画面を使用して、発行されたトークンを検索し、取り消します。ユーザーID、クライアントID/名前、クライアントIPアドレス、サービス・プロファイル、アサーション・トークン・カテゴリおよびトークン作成/有効期限などの基準を使用して、トークンを検索できます。基準を入力し、「検索」をクリックします。返されるトークン・エントリ検索結果の最大数は、「OAuthサーバー設定」ページの「検索結果の最大数」で指定されます。
検索基準
アイデンティティ・ドメイン: トークンを検索するアイデンティティ・ドメインの名前。(読取り専用)
ユーザー: 検索するLDAP UID (john.smith
)またはLDAP完全修飾DN (cn=jane.smith,dc=example,dc=com
)を指定します。
クライアント: トークンを検索するクライアントIDを指定します。
クライアントIPアドレス: トークンを検索するクライアントIPアドレス(たとえば、192.168.100.1
)を指定します。
サービス・プロファイル: メニューからプロファイルを選択するか、この選択を空のままにします。
アサーション・トークン・カテゴリ: メニューからカテゴリを選択するか、選択を空のままにします。
発行されたトークン: 発行された日時別にトークンを検索します。
トークンの有効期限: 有効期限が切れる日時別にトークンを検索します。
モバイル・デバイス要求属性
IMEI: 検索する一意の15桁のIMEI (国際移動体装置識別番号)コードを指定します。IMEIは、*#06#をダイヤルして、ほとんどのモバイル・ハンドセットで表示できます。
MACアドレス: 検索する一意のMAC (Media Access Control)アドレスを指定します。
電話番号: 検索する電話番号を指定します。
Oracle Access Management OAuthサービスは、サードパーティ(Oracle以外)のJWTアサーションを受け入れます。ただし、サードパーティの証明書をOAuthサービス・プロファイル・キーストアに追加することによって、信頼関係を構成する必要があります。サービスは、キーストアを使用してJWTアサーションのデジタル署名を検証します。専用の署名証明書を必要とするOAuthサービス・プロファイルに対して、それぞれ別々のキーストアを作成します。この項の内容は次のとおりです。
OAuthサービス・プロファイルの役割は、第46.3.3節「OAuthサービス・プロファイル構成の理解」に記載されています。DefaultDomainに含まれるデフォルトのOAuthサービス・プロファイル(OAuthServiceProfile)は、Oracle Access Managementに含まれているJavaキーストア(JKS)を使用します。デフォルトのサービスは、次のファイルから構成されています。
表46-9 デフォルトOAuth JKSキーストア・ファイルおよび設定ファイル
ファイル | パス |
---|---|
JKSキーストア・ファイル |
|
キーストア設定ファイル |
|
注意: Oracle Web Services Managerは、default-keystore.jks サービスも使用します。詳細は、第37.2.2項「Oracle Web Services Manager キーストア (default-keystore.jks)について」を参照してください。 |
次のJava keytool
コマンドを使用して、デフォルト・キーストア(default-keystore.jks
)内のすべての秘密鍵と証明書の情報を一覧にすることができます。
keytool -list -keystore default-keystore.jks
この項の手順では、次の内容を実行する方法を説明します。
サードパーティの証明書を格納する独立したキーストアを作成します。
キーストアに証明書をインポートします。
キーストアを構成します。
キーストア・サービスを適切なOAuthサービス・プロファイルに追加します。
キーストアの作成手順
Java JDKとともに配布されたkeytool
ユーティリティを使用して、新しいJavaキーストア(JKS)を作成します。
$JDK_HOME
/jdk/bin
に移動し、プロンプトを開きます。
次のようにkeytool
を使用して、キーのペアを生成します。
keytool -genkeypair -keyalg RSA -dname
dname
-alias
aliasname
-keypass
key_password
-keystore
keystore
-storepass
keystore_password
-validity
days_valid
説明:
dname
は、alias
に関連付けられるX.500識別名であり、自己署名証明書のissuerフィールドとsubjectフィールドとして使用されます。正しい書式であるかぎり、どのような文字列であっても構いません(cn=spaces,dc=example,dc=com
など)。
aliasname
は、新しいキーストアのエントリを識別する短縮名です。
key_password
は、新しい公開鍵のパスワードです。
keystore
はキーストアの名前です(oauth-xyz-keystore.jks
など)。
keystore_password
は、キーストア・パスワードです。
days_valid
は、証明書の有効日数です(1064など)。
キーストアに証明書をロードします。
keytool
ユーティリティを使用して、証明書をキーストアにインポートします。
keytool
コマンドを使用して、次のコマンドをタイプします。
keytool -importcert -alias
aliasname
-file
certfile
-keystore
keystore
-storepass
keystore_passwor
d
説明:
aliasname
は、キーストアを識別する短縮名です。
certfile
は、ロードする証明書を格納しているファイルです。
keystore
はキーストアの名前です(oauth-xyz-keystore.jks
など)。
keystore_password
は、キーストア・パスワードです。
キーストア・インスタンスをjps-config.xmlに追加します。
キーストア・サービスを構成して資格証明ストアを更新し、OAMがキーストアとキーを正しく読み取れるようにします。jps-config.xml
キーストア設定ファイルにて、<serviceInstances>
エレメントに次の新規キーストア・サービス・インスタンスを追加します。
テキスト・エディタでキーストア設定ファイルを開きます。
$DOMAIN_HOME
/config/fmwconfig/jps-config.xml
keystore.provider Provider
に対する<serviceInstances>
ノードを探して、次の内容を追加します。
<serviceInstance name="<service-instance-name>
" provider="keystore.provider" location="<keystore-location>
"> <property name="keystore.provider.type" value="db"/> <property name="keystore.sig.csf.key" value="sign-csf-key"/> <property name="keystore.enc.csf.key" value="enc-csf-key"/> <property name="keystore.csf.map" value="oracle.oauth.security"/> <property name="keystore.pass.csf.key" value="keystore-csf-key"/> <property name="keystore.type" value="JKS"/> <propertySetRef ref="props.db.1"/> </serviceInstance>
説明:
service-instance-name
= Any service-instance-name
keystore-location
= キーストア・ファイルに対するパス
例46-3 jps-config.xmlの更新
<serviceInstance name="oauth-xyz-keystore.db" provider="keystore.provider" location="./oauth-xyz-keystore.jks"> <property name="keystore.provider.type" value="db"/> <property name="keystore.sig.csf.key" value="sign-csf-key"/> <property name="keystore.enc.csf.key" value="enc-csf-key"/> <property name="keystore.csf.map" value="oracle.oauth.security"/> <property name="keystore.pass.csf.key" value="keystore-csf-key"/> <property name="keystore.type" value="JKS"/> <propertySetRef ref="props.db.1"/> </serviceInstance>
<jpsContexts>
ノードを探して、新しいサービス・インスタンスをデフォルトのコンテキスト・セクションに追加します。次の例に、oauth-xyz-keystore.db
サービス・インスタンス(前の手順で定義済)に対する<serviceInstanceRef>
エレメントのref
付きの追加を示します。
キーストア・サービス・インスタンスにCSFエントリを作成します。
次のWLSTコマンドを使用して、必要な資格証明ストア・フレームワーク(CSF)エントリを作成します。完了したらサーバーを再起動します。
createCred(map="oracle.wsm.security", key="
sign_csf_key
", user="
alias_name
", password=
keystore_password
, desc="
Description of the signing key credential
")
createCred(map="oracle.wsm.security", key="
enc_csf_key
", user="
alias_name
", password=
keystore_password
, desc="Description of the encryption key credential")
createCred(map="oracle.wsm.security", key="
keystore_csf_key
", user="
oauth
", password=
keystore_password
, desc="
Description of the keystore credential
")
説明:
sign_csf_key
= 署名するキーのパスワード
alias_name
= キーのエイリアス名
keystore_password
= キーストア・パスワード
enc_csf_key
= 暗号化キーのパスワード
keystore_csf_key
= キーストアのパスワード
例46-5 資格証明ストアのエントリの作成
createCred(map="oracle.wsm.security", key="oauth-sign-csf-key", user="ms-oauth-key", password=passwordxyz, desc="Signing key credential") createCred(map="oracle.wsm.security", key="oauth-enc-csf-key", user="ms-oauth-key", password=passwordxyz, desc="Encryption key credential") createCred(map="oracle.wsm.security", key="keystore_csf_key", user="oauth", password=passwordxyz, desc="Keystore credential")
プロバイダ・サービス名をOAuthサービス・プロファイルに追加します。
更新された構成をOAuthサービス・プロファイルに適用します。サードパーティ・サービス用のOAuthサービス・プロファイルをまだ作成していない場合には、第46.4.2.1項「OAuthサービス・プロファイルの作成」を参照してください。
第46.2項「OAuthサービスの構成ページを開く」の説明に従って「OAuthサービス」構成ページを開き、アイデンティティ・ドメインをクリックして編集用に開きます。
「OAuthサービス・プロファイル」タブをクリックします。
表内でサービス・プロファイル名をクリックします。
「属性」セクションを開きます。
keystore.service
名を使用して、「属性」表に例46-4「新規サービス・インスタンスの追加」で構成したキーストア・サービス情報を追加します。次のスクリーンショットを参照してください。
この項では、JWTべアラー・アサーションの検証をサポートするOAuthサービスを構成する方法を説明します。各トークン・プロバイダに対して、次のように構成します。
JWTべアラー・アサーション発行者の名前。これは必須属性です。
証明書別名用のキーID (KID)。これはオプションの属性です。
JWTべアラー・アサーション発行者の名前を、次のように構成します。
属性名 | 属性値 |
---|---|
jwt.trusted.issuer.1
...
|
alias-1 <キーストア内のcert-alias-name>
alias-2 <キーストア内のcert-alias-name> ... alias-n <キーストア内のcert-alias-name> |
キーIDを次のように構成します。
属性名 | 属性値 |
---|---|
jwt.trusted.issuer.size |
n
ここで、nは構成された発行者の別名の数です。 |
OAuthサーバーは、検証のためにJWTアサーションをBase64デコードする必要があります。サーバーは発行者名を検索し、次に署名メソッドとキーID値を検索します。
署名メソッドとキーID値が含まれていない場合には、システムは発行者名を使用して必要な構成情報を取得します。その後、システムはOPSS検証メソッドを呼び出します。署名メソッドとキーID値が含まれている場合には、システムは情報が構成値と一致することを検証した後に、OPSS検証メソッドを呼び出します。
この項では、OAuthサービスとともに使用するためのWebゲートの構成方法について説明します。Webゲートは、クライアント認証およびトークン・エンドポイント・リクエストがOracle Access Managementサーバーに直接アクセスするのではなく、Webゲートにアクセスするようにプロキシとしての役割を果たします。次に、WebLogic環境専用の手順を示します。
『WebGate for Oracle Access Managerのインストール』の手順を使用してOracle HTTP Server 11g WebGate for OAMをインストールします。
次のリソースを定義し、認証ポリシーおよび認可ポリシーを作成して、Webゲートを構成します。
Oracle Access Managementコンソールを開きます。
「Access Manager」で、「アプリケーション・ドメイン」をクリックして、「検索」をクリックし、「アプリケーション・ドメインの検索」ページの「アプリケーション・ドメイン」を表示します。
クリックして、「アプリケーション・ドメイン」を編集します。
「アプリケーション・ドメイン」ページで、「リソース」タブをクリックします。
次のリソースを作成します。既存のIAMSuiteAgentホスト識別子を使用する場合、リソースはすでに存在し、「リソースURL」フィールドを使用して検索できます。
/ms_oauth/oauth2/ui/**
クリックしてリソースを選択してから「編集」ボタンをクリックします。
「保護」見出しの下で、メニューから次のオプションを選択して、「適用」をクリックします。
保護レベル: 保護
認証ポリシー: 保護されるより高度なポリシー
認可ポリシー: 保護リソース・ポリシー
これらの設定によりWebゲートはユーザー認証およびユーザー認可を実行できます。
次のリソースを追加して、「保護レベル」を「除外」に設定します。
/ms_oauth/oauth2/endpoints/** /ms_oauth/oauth2/oammsui/** /ms_oauth/style/** /ms_oauth/img/** /oam/**
Webゲートは除外されたリソースを保護せず、除外されたリソースへのアクセスを許可します。
次の行をmod_wl_ohs.conf
ファイルに追加し、Webゲートを再起動します。WebLogicPort
の場合、必ずその環境の管理対象ポートの詳細を追加してください。
# the following directive proxies all the OAuth requests <IfModule weblogic_module> WebLogicHost host123.us.example.com WebLogicPort 17100 Debug ON WLLogFile /tmp/weblogic.log MatchExpression /ms_oauth/* </IfModule> # the following directive proxies all the OAM managed server requests. <IfModule weblogic_module> WebLogicHost host123.us.example.com WebLogicPort 17100 Debug ON WLLogFile /tmp/weblogic.log MatchExpression /oam/* </IfModule>
Access Managerロード・バランシング設定を次のように更新します。
Oracle Access Managementコンソールを開きます。
「構成」で、「Access Managerの設定」をクリックします。
「ロード・バランシング」セクションで、「OAMサーバー・ホスト」および「OAMサーバー・ポート」設定をWebゲートのホストおよびポート設定に変更します。
「適用」をクリックします。
次の手順を実行します。
$ORACLE_HOME
/ORACLE_IDM1/oam/server/apps/
を開き、oam-server.ear
ファイルを検索します。例:
cd /scratch/test/Oracle/Middleware/Oracle_IDM1/oam/server/apps
.ear
ファイルをバックアップします。
cp oam-server.ear oam-server.ear.original
一時ディレクトリを作成し、そのディレクトリに移動します。
mkdir tmp-ear cd tmp-ear/
oam-server.ear
ファイルをtmp-ear
ディレクトリに抽出します。
jar -xvf ../oam-server.ear
tmp-ear
内に別の一時ディレクトリを作成し、そのディレクトリに移動します。
mkdir tmp-ms-war cd tmp-ms-war
次のディレクトリに存在していることになります。
/scratch/test/Oracle/Middleware/Oracle_IDM1/oam/server/apps/tmp-ear/tmp-ms-war
ms_oauth.war
をtmp-ms-war
ディレクトリに抽出します。
jar -xvf ../ms_oauth.war
編集用にWEB-INF/web.xml
ファイルを開いて、次のようにセキュリティ制約の前後にコメント・タグを追加して更新します。
<!-- BEGIN: Comment the following security constraint if either the OAM WebGate is front-ending OAM in a WebSphere setup or if the WebLogic server Domain Agent is not used. <security-constraint> <web-resource-collection> <web-resource-name>OAuthSecuredResources</web-resource-name> <url-pattern>/oauth2/ui/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint> END of security constraint needing to be commented -->
tmp-ms-war
ディレクトリに.war
ファイルを再作成します。
jar cvf ms_oauth.war
更新された.war
ファイルを親ディレクトリにコピーし、tmp-ear/
にあるtmp-ms-war
ディレクトリを削除します。
cp /scratch/test/Oracle/Middleware/Oracle_IDM1/oam/server/apps/tmp-ear/tmp-ms-war/ms_oauth.war /scratch/test/Oracle/Middleware/Oracle_IDM1/oam/server/apps/tmp-ear rm -rf /scratch/test/Oracle/Middleware/Oracle_IDM1/oam/server/apps/tmp-ear/tmp-ms-war
tmp-ear
ディレクトリにoam-server.ear
アーカイブを作成します。
jar cvf oam-server.ear .
tmp-ear/oam_server.ear
アーカイブ・ファイルを親ディレクトリにコピーします。
cp /scratch/test/Oracle/Middleware/Oracle_IDM1/oam/server/apps/tmp-ear/oam-server.ear /scratch/test/Oracle/Middleware/Oracle_IDM1/oam/server/apps/oam-server.ear
WebSphereサーバーを再起動します。
Webゲートはこれで、リバース・プロキシOAuth URLおよびOAM管理対象サーバーURLになります。すべての認可およびトークン・エンドポイント・リクエストは、実際のOAMホストおよびポートの値ではなく、Webゲート・ホストおよびポートの値を使用してアクセスされるようになります。