| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
次の各項では、アイデンティティ・ドメインの構成オプションの詳細について説明します。次の各項の情報は、Identity Federationとモバイル・セキュリティOAuthサービスの両方に適用されます(モバイル・セキュリティOAuthサービスに固有のジェイルブレーク検出ポリシーを除く)。これらのコンポーネントの構成の詳細は、「OAuthサービスの構成」を参照してください。
アイデンティティ・ドメインは、標準のOAuthサービスまたはモバイルOAuthサービスの提供に必要なすべてのアーティファクトを含むエンティティです。
各アイデンティティ・ドメインは、独立したエンティティです。アイデンティティ・ドメインの主要なユースケースの1つは、マルチ・テナントのデプロイメントです。各アイデンティティ・ドメインは、1つのテナントに対応します。独立性が必要な場合は、組織内の様々な部門に適用できます。これは、各アイデンティティ・ドメインが個別のテナントまたはエンティティに対応できるクラウド・デプロイメントにも便利です。次のアーティファクトは、OAuthサービス・アイデンティティ・ドメイン内で構成されるコンポーネントの一部にすぎません。
1つ以上のサービス・プロファイル
1つ以上のクライアント
サービス・プロバイダ
1つ以上のリソース・サーバー
プラグイン
サーバー設定
トークン・ライフ・サイクル管理(アイデンティティ・ドメイン全体でトークンを検索および取り消し)
アイデンティティ・ドメインの構成の詳細は、「アイデンティティ・ドメインの構成」を参照してください。
クライアント、カスタム・リソース・サーバー、システム・リソース・サーバー、モバイル・サービス設定などのサービス・プロファイルを構成できます。
サービス・プロファイルでは、次の設定を定義します。
OAuthサービスが対話できるクライアント
OAuthサービスが保護し、アクセスが提供されるカスタム・リソース・サーバーおよびシステム・リソース・サーバー
リフレッシュ・トークン設定、トークンの有効期限設定、およびトークン・ライフ・サイクル管理を有効にするオプション
ユーザー・プロファイル・サービスおよび承認管理サービス・プロファイル
有効化されたセキュリティ・プロファイル・プラグイン
サポートされるモバイル・プラットフォームのセキュリティ設定を含む、モバイル・サービス設定
OAuthサービス・エンドポイントのルートURL
必要に応じて、複数のサービス・プロファイルを作成できます。異なるクライアントまたはリソースをグループ化する必要がある場合、異なるトークン設定が必要な場合、または構成設定ごとに異なるサービス・エンドポイントがある場合は、異なるサービス・プロファイルが必要になることがあります。複数のサービス・プロファイルを作成できるため、ほとんど場合では必要ありませんが、柔軟な構成オプションが提供されます。サービス・プロファイルの構成の詳細は、「サービス・プロファイルの構成」を参照してください。
クライアントは、OAuthサービスを起動することで、OAuthプロトコルを開始します。
クライアント・プロファイルは、プロトコルの開始前に、「OAuthサービス」インタフェース(Oracle Access Managementコンソール内)を使用して作成する必要があります。クライアント・プロファイルには最低限、アプリケーション名、クライアントID、およびアクセスが付与または拒否された場合に、OAuthサービスがユーザー・エージェントをリダイレクトするURIが1つ以上含まれます。OAuthサービス・クライアントは、「Web」、「パブリック」または「モバイル」として定義できます。
Webクライアントには、クライアントIDおよび秘密が割り当てられます。これらのクライアントは、クライアントIDおよび秘密を認可ヘッダーの一部として送信することで、OAuthサービス・サーバーと対話できます。それらに発行される秘密をどのようにして安全に格納するかを決定するのは、各クライアントです。
パブリック・クライアントには、クライアントIDが割り当てられますが、秘密は割り当てられません。通常、これらのプロファイルは、JavaScriptなどのブラウザ・ベースのアプリケーションに関係しますが、モバイル・ベースのアプリケーションにもなります。
モバイル・クライアントには、クライアントIDが割り当てられ、OAuthサービスへのモバイル・クライアントの登録フローの一部として秘密が動的に生成されます。(登録フローは独自のものであり、OAuth仕様を拡張することで開発されています。)
クライアントIDおよび秘密は、次の箇条書きに説明されています。
クライアントIDは、登録情報を表す一意の文字列で、クライアントごとに必要です。一意のクライアントIDを作成したり、OAuthサービスで生成できます。OAuthサービスでは、定義済のクライアントIDと、認可リクエストの一部としてクライアントがHTTPSまたはHTTP経由で送信する値を比較します。値が一致しない場合、リクエストは否認されます。クライアントIDは、認可ヘッダーとして送信されるとBase64でエンコードされます。
クライアントの秘密は、クライアント・パスワードです。一意のクライアント秘密を作成したり、OAuthサービスで生成できます。Webクライアントには、クライアントIDおよびクライアント秘密を含める必要があります。これに対し、モバイル・クライアントおよびパブリック・クライアントには、クライアント秘密が含まれず、クライアントIDのみが割り当てられます。
アクセス・トークンをリクエストするために、クライアントはリソース所有者から認可を取得します。認可は、クライアントがアクセス・トークンのリクエストに使用する認可権限の形で表されます。OAuth 2.0仕様には、様々なセキュリティ・ユースケースに対応した認可権限タイプが用意されています。OAuthサービスでは、これらの権限タイプの一部を実装しています。Web,、パブリックおよびモバイル・クライアントでは、それらに適した様々なOAuthサービス権限タイプにアクセスできます。たとえば、「クライアント検証コード」権限タイプは、モバイル・クライアントのみに関係します。OAuthサービスでは、次の権限タイプがサポートされています。
ノート:
(OAuth仕様の権限タイプの概要は、http://tools.ietf.org/html/rfc6749#section-1.3を参照してください。)
認可コード - Oracle Access Management使用時のリソース所有者のログ。トークン・エンドポイントはクライアント資格証明とともに認可コードをアクセス・トークンと交換します。3-leggedフローでは、「認可コード」権限タイプが必要です。
リソース所有者の資格証明 - リソース所有者はクライアントにユーザー名とパスワードを提供します。クライアントがパスワードを乱用したり、パスワードが誤って攻撃者に開示される可能性があるため、これは信頼性の高いクライアント・アプリケーションにのみ適しています。OAuth 2.0仕様ごとに、認可サーバーおよびクライアントは、この権限タイプの使用を最小限に抑え、可能な場合は常に他の権限タイプを利用する必要があります。「リソース所有者の資格証明」権限タイプは、2-legged認可シナリオに必要です。
クライアント資格証明: クライアントはそのクライアント資格証明のみ(または他のサポートされている認証手段)を使用してアクセス・トークンをリクエストします。これは、クライアントがその制御下、または認可サーバーで前に調整されたときの別のリソース所有者の制御下にある保護されているリソースへのアクセスをリクエストしている場合に適しています。「クライアント資格証明」権限タイプは、2-legged認可シナリオに必要です。
リフレッシュ・トークン: このオプションを選択すると、トークン・レスポンスでアクセス・トークンとともにリフレッシュ・トークンを返します。詳細は、「OAuthサービス・トークンについて」を参照してください。
JWTベアラー - OAuthサービス・アクセス・トークンのリクエストにJWTアサーションを使用できます。
SAML 2ベアラー - OAuthサービス・アクセス・トークンのリクエストにSAML2アサーションを使用できます。
OAM資格証明 - マスター・トークン、アクセス・トークン、OAuthサービス・アクセス・トークンなど、OAMトークンのリクエストに使用します。
クライアント検証コード - モバイルOAuthサービス・クライアントが、後でモバイル・クライアント・フローで使用される事前検証コードをリクエストするために使用されます。
クライアントごとに「権限」および「許可されているスコープ」をクライアントに構成することもできます。OAuthサービスにより、ユーザー承認を必要とせずにスコープを構成できます。したがって、「権限」を構成して、どのクライアントがどの権限タイプを許可されているかを定義できます。該当する場合、クライアントは、OAuthサービスと交換可能なアクセス・トークンの認可権限を取得します。クライアントの構成の詳細は、「クライアントの構成」を参照してください。
サービス・プロバイダの設定を使用して、OAuthサービスと、OAuthサービスをサポートするバックエンド認可サービス・プロバイダであるAccess Manager間の接続を管理します。カスタム・サービス・プロバイダを作成できますが、OAuthサービス・プロバイダがDefaultDomainアイデンティティ・ドメインのデフォルトのサービス・プロバイダです。
このリリースでは、OAuthサービスはOAM認証(ほとんどの認証モジュールを起動できますが、通常はユーザー/資格証明ペースのプラグイン)とIDS認証の両方のサポートを提供します。OAMまたはIDS認証で提供されていない機能には、カスタム・サービス・プロバイダが必要になります。各アイデンティティ・ドメインには、サービス・プロバイダを1つのみ含めることができます。
ノート:
現時点では、OAMのマルチ・ステップ編成を含む認証モジュールを起動することはできず、これは2-legged OAuthサービス・シナリオを指します。3-leggedシナリオでは、認証はブラウザ・フロー経由で実行されるため、OAM認証モジュールの起動に制限はありません。
サービス・プロバイダの構成の詳細は、「サービス・プロバイダの構成」を参照してください。
リソース・サーバーの設定は、OAuthサービスで保護するアプリケーションまたはサービスを含むリモート・リソース・サーバーごとに、プロファイルに個別に構成されます。
リソース・サーバー・プロファイルでは、エンドポイントやセキュリティ保護などのリソース・サーバー固有の設定は定義されず、OAuthサービス関連の構成のみが定義されます。
リソース・サーバー構成の一部には、スコープの定義が含まれます。スコープでは、クライアントが保護リソースにアクセスできる範囲を決定します。Oracle Access Managementでは、スコープ設定に基づいてアクセスを制限し、発行されたアクセス・トークンのスコープをクライアントに通知します。したがって、クライアント・アプリケーションがリソース・サーバーにアクセスするには、適切なスコープのOAuthサービス・アクセス・トークンを取得する必要があります。
クライアントでは、OAuthサービスへのリクエストでスコープ文字列を提供します。スコープは、URLまたは文字列リテラルになります。認証および認可に成功すると、OAuthサービスには、アクセス・トークンのスコープが含まれます。たとえば、OAuthクライアントが特定のエンド・ユーザーのリソースへのアクセスをリクエストすると、OAuthサービスは、UserProfile.meとして定義されたスコープを持つアクセス・トークンを作成し、クライアントは、/meエンドポイントを持つユーザー・プロファイル・リソース・サーバーにアクセスできます。(表52-1を参照してください。)次に、ユーザー・プロファイル・リソース・サーバーは、取得したアクセス・トークンを持つリソースにクライアントがアクセスできるかどうかを決定します。スコープに関して、次が該当します。
リソース・サーバーには、1つ以上のスコープを関連付けることができます。
異なるトークン設定が必要な場合や、デフォルトのセキュリティ保護(承認の失効を許可しないなど)を変更する必要がある場合など、複数のリソース・サーバーを作成できます。それぞれ独自のスコープ定義のセットがあります。このシナリオは一般的ではありません。
クライアントは、認可リクエストの一環としてスコープ・パラメータを送信します。スコープ・パラメータ値の一部が無効な場合、OAuthサービスはクライアント・アプリケーションにinvalid_scopeエラー・レスポンスを送信します。スコープ・パラメータの値が有効である場合は、認可コードおよびアクセス・トークンの一部として埋め込まれます。
OAuthサービスでは、リソース・サーバーとしてモデル化され、アクセス・トークンで保護された、すぐに使用可能なサービスが2つ提供されます。ユーザー・プロファイル・サービスおよび承認管理サービスのリソース・サーバーの詳細は、次の各項を参照してください。
構成情報は、「カスタム・リソース・サーバーの構成」、「ユーザー・プロファイル・サービスの構成」および「承認管理サービスの構成」を参照してください。
デフォルトのUserProfileユーザー・プロファイル・サービス構成は、Oracle Access Management OAuthサービスのインストール中に作成されるリソース・サーバーです。
この構成により、組織でOAuth 2.0を使用してバックエンドLDAPディレクティブ・サーバーとの対話が可能になり、表52-1に説明されているREST操作を個人、グループおよびリレーションシップ・エンティテ上で実行できます。RESTを使用したユーザー・プロファイル・サービスとの相互作用の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。
表52-1 デフォルトのユーザー・プロファイル・サービスのエンドポイント操作
| リソース・エンドポイント(URI) | HTTP(S)メソッド | 使用の詳細 |
|---|---|---|
|
GETで読取りを許可 PUTで更新を許可 |
OAuthクライアントは、指定されたユーザーのプロファイルの読取りおよび更新権限をリクエストできます。 |
|
GETで読取り、検索を許可 POSTで作成を許可 PUTで更新を許可 DELETEで削除を許可 |
OAuthクライアントは、任意のユーザー・プロファイルの作成、読取り、検索、更新および削除権限をリクエストできます。 |
|
GETで読取り、検索を許可 POSTで作成を許可 PUTで更新を許可 DELETEで削除を許可 |
OAuthクライアントは、任意のグループ・プロファイルの作成、読取り、検索、更新および削除権限をリクエストできます。 |
|
GETで読取りを許可 POSTで作成を許可 DELETEで削除を許可 |
Oracle Mobile Authenticatorによって使用され、指定されたユーザーの秘密キーを読み取り、作成または削除します。この秘密キーは、OMAによってワンタイムPINの生成に使用されます。 |
ユーザー・プロファイル・サービスは、個人、グループおよびリレーションシップ・エンティティのサービス固有のエンドポイントを使用して、HTTPSリクエストを受信し、応答します。各サービス・エンドポイントは、必要でない場合は個別に無効にできます。ユーザーが複数のユーザー・リポジトリにわたる場合は、ユーザー・プロファイル・サービスの複数のユーザー・インスタンスを作成できます(たとえば、社内の部門ごとに異なるリポジトリを使用している場合に便利です)。ただし、複数のユーザー・プロファイル・サービスを作成するのは一般的ではありません。詳細は、「ユーザー・プロファイル・サービスの概要」を参照してください。ユーザー・プロファイル・サービスの構成の詳細は、「ユーザー・プロファイル・サービスの構成」を参照してください。次の各項では、特定のユーザー・プロファイル・サービス構成の詳細について説明します。
プロキシ認証を使用すると、すべての層を通じてクライアントの識別情報と権限が保持され、クライアントのかわりに実行されるアクションが監査されるため、中間層アプリケーションのセキュリティを制御できます。
たとえば、この機能によって、Webアプリケーション("プロキシ"とも呼ばれる)を使用するユーザーの識別情報を、アプリケーションを介してデータベース・サーバーに渡すことができます。Oracle Unified Directory (OUD)およびActive Directory (AD)は、プロキシ認証をサポートする数少ないディレクトリ・サーバーです。プロキシ認証には、次のようなセキュリティ上の利点があります。
中間層が代理として接続可能なユーザーや、中間層がユーザーから引き受けるロールの制御による、制限付きの信頼モデル
データベースを介した実際のユーザーのアイデンティティの保持や、実際のユーザーのかわりに実行されるアクションの監査の有効化による、アカウンタビリティ
ユーザーがデータベースに把握される環境や、ユーザーがデータベースに認識されない単なるアプリケーション・ユーザーにすぎない環境のサポートによる、柔軟性
Oracle Access Managementでは、プロキシ認証機能をサポートしていないディレクトリ・サーバーの上部にプロキシ認証機能を追加できます。「アクセス制御」オプションは、プロキシ認証のサポートが組み込まれていないディレクトリ・サーバーにプロキシ認証のサポートを提供するだけです。
プロキシ認証およびアクセス制御は、以前はモバイル・サービスで使用できましたが、このサポートは現在はOAuthサービスで使用できます。プロキシ認証またはアクセス制御が有効でない場合、ディレクトリ・サーバーとの通信は管理者ユーザー・アカウントを使用して実行され、この場合、管理者は任意のユーザーですべての操作を実行できます。この機能を有効にすると、ログインしているユーザーは、権限を付与されている操作のみを実行できます。
ユーザー・プロファイル・サービスを実装する場合は、セキュリティに関する考慮事項が非常に重要になります。
たとえば、UserProfile.meへの書込みアクセス権を持つユーザーは自身のUIDまたまメール・アドレスを変更できますが、セキュリティ違反になります。このため、すべてのURIのスコープを読取り専用に制限できますが、スコープへの書込みアクセス権を付与する場合は、注意が必要です。属性ごとに、読取りおよび書込みアクセスを個別に構成することもできます。
セキュリティ保護は、構成済のユーザー・プロファイル・サービスの「スコープ」表内で定義されます。URIを追加すると、サービス・エンドポイントが有効かどうか、読取りまたは書込みアクセスが許可されているかどうか、URIがアクセス・トークンによって保護されているかどうか、およびユーザー承認が必要かどうかを選択できます。
Oracle Access Managementコンソールでは、変更可能な属性のきめ細かい構成も可能です。カスタム属性を作成したり、デフォルトの属性を削除することもできます。表52-2に、スコープ設定ごとにすぐに使用できる構成可能な属性を示します。
表52-2 ユーザー・プロファイル・リソース・サーバー: スコープ設定
| スコープ | HTTP(S)メソッド | リソースURI | 属性 |
|---|---|---|---|
|
GET PUT |
|
|
|
GET POST PUT DELETE |
|
|
|
GET POST PUT DELETE |
|
|
|
GET POST DELETE |
|
属性は不要です。 |
エンティティとは、ユーザーとグループなど、2つのエンティティ間の関連付けです。
エンティティ・タイプは同じ場合や異なる場合があります。たとえば、memberOfエンティティは、ユーザーとグループ間の関係ですが、managerエンティティは2人のユーザー間の関係です。クライアント・アプリケーションでは、ユーザー・プロファイル・サービス関係エンドポイントを使用して、関係を作成、読取りまたは削除できます。次のREST操作は、memberOf関係の作成方法を示しています。これらの例では、関係エンドポイントはmemberOf、ソース・エンティティURIはuser-uri、宛先エンティティURIはgroup-uriです。
Create User "John"
curl -H "Content-Type: application/json" --request POST http://localhost:port/ms_oauth/resources/userprofile/users -d '{"uid":"John"Anderson","commonname":"John Anderson","firstname":"John"}'
Create Group "Group1"
curl -H "Content-Type: application/json" --request POST http://localhost:port/ms_oauth/resources/userprofile/groups -d '{"description":"group1 testing","commonname":"group1"}'
Create memberOf relationship
curl -H "Content-Type: application/json" --request POST http://localhost:port/ms_oauth/resources/userprofile/users/memberOf -d '{"group-uri":"\/idaas_rest\/rest\/userprofile\/group\/group1", "user-uri":"\/idaas_rest\/rest\/userprofile\/people\/John"}'
デフォルトの承認管理サービス構成にはConsentManagementのラベルが付いており、承認の格納、取得、失効および承認検証操作を処理します。「ユーザー承認が必要」オプションを選択すると、Oracle Access Managementにユーザー承認フォームが表示され、リクエストされたリソースへのアクセスをユーザーが承認または拒否できます。「ユーザー承認が必要」オプションは、スコープごとに有効にできます。たとえば、"書込み"アクセスは許可するが、"読取り"アクセスは許可しないスコープ・リクエストに対してユーザー承認を要求できます。承認データはOracle Access Managementデータベースに格納されます。承認管理サービスの構成の詳細は、「承認管理サービスの構成」を参照してください。
ノート:
「クライアント」構成ページには、「ユーザー承認をバイパス」オプションがあります。このオプションが選択されると、クライアント設定はリソース・サーバー設定をオーバーライドします。クライアントの構成の詳細は、「クライアントの構成」を参照してください。
承認操作には、「クライアント資格証明」権限タイプのアクセス・トークン(「クライアント - Identity FederationおよびOAuthサービス」を参照)および該当する承認管理スコープが必要です。ユーザー(クライアント経由)は、OAuthサービスで保護されたリソースへのアクセスをリクエストします。リクエストには、アクセス・トークン、クライアント識別子およびユーザー識別子が含まれます。OAuthサービスは、構成済のスコープを取得し、許可されている場合は、スコープをアクセス・トークンに追加して承認を付与します。アクセス・トークンは、承認管理サービスによって提供されるエンドポイントを使用して、承認を取得、付与または失効するのに使用される、HTTPリクエストの認可ヘッダーに追加されます。RESTインタフェースを使用した承認管理サービスとの相互作用の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。
ノート:
複数の承認管理サービスは不要です。
OAuthサービスおよびモバイルOAuthサービスで使用する場合、次のプラグイン・タイプが使用可能です。
「カスタム・トークン属性プラグイン」は、トークン・サービス・プロバイダ周囲のセキュリティ・ポリシーを定義します。
「認可および承認サービス・プラグイン」は、認可およびユーザー承認が付与される相互作用周囲のセキュリティ・ポリシーを定義します。このプラグイン・タイプは、生成されたトークンの要求にも影響を及ぼす可能性があります。
「クライアント・プラグイン」は、アイデンティティ・ドメイン内のクライアントのセキュリティ・ポリシーを定義します。
「リソース・サーバー・プロファイル・プラグイン」は、アイデンティティ・ドメイン内のリソース・サーバーのセキュリティ・ポリシーを定義します。
モバイルOAuthサービスのみで使用する場合、次のプラグイン・タイプが使用可能です。
「モバイル・セキュリティ・マネージャ・プラグイン」は、Oracle Mobile Security Suite (OMSS)で使用するためのプラグインです。モバイル・セキュリティ・マネージャ(MSM)コンポーネント(OMSSの一部)は、モバイル・デバイス・データの豊富なセットを収集します。このプラグインは、その情報を収集し、さらにデバイスのコンプライアンス・ステータスをチェックするMSMコンプライアンス・ポリシーを呼び出します。最後に、このプラグインはデバイス情報およびコンプライアンス・ステータスをアダプティブ・アクセス・プラグインに送信します。モバイル・セキュリティ・マネージャ・プラグインの構成の詳細は、「プラグイン構成ページ」を参照してください。
「アダプティブ・アクセス・プラグイン」は、Oracle Adaptive Access Manager (OAAM)で使用するためのプラグインです。これは不正検出を実行し、さらにユーザー接続の認証を行って信頼できるかどうかを確認するリスク分析ポリシー・チェックを実行します。アダプティブ・アクセス・プラグインでは、モバイル・セキュリティ・マネージャ・プラグインによって収集されたモバイル・デバイス属性値を使用できますが、Oracle Mobile Security Suiteが使用できない場合、モバイルOAuthサービスがモバイル・アプリケーション・リクエスト中に取得したモバイル・デバイス属性値を使用できます。モバイル・セキュリティ・マネージャ・プラグインがアクティブになっている場合は最初に実行され、デバイス・データを(2番目に実行される)アダプティブ・アクセス・プラグインに渡します。
詳細は、「OAuthサービス・プラグイン」を参照してください。
各プラグイン・タイプにつき、サービス・プロファイル・レベルで一度にアクティブにできるインスタンスは1つのみです。たとえば、アイデンティティ・ドメイン・レベルではクライアント・プラグインの様々なインスタンスを作成および保存できますが、サービス・プロファイル・レベルで割り当てることができるのは、一度に1つのクライアント・プラグイン・インスタンスのみです。追加のセキュリティを提供するために、オプションのプラグインを構成できます。プラグインの構成の詳細は、「プラグインの構成」を参照してください。
「サーバー設定」ページでは、アクセス対象のアイデンティティ・ドメインの一般的なサーバー設定を構成します。
サーバー設定の構成の詳細は、「サーバー設定」を参照してください。
iOSデバイス用の事前構成済ジェイルブレーク検出ポリシーでは、デバイスがジェイルブレークされていることを示すファイルを検索し、そのファイルが見つかった場合はOAuthサービスへのデバイス・アクセスを拒否できます。
この設定タブは、モバイルOAuthサービス専用として表示されます。ジェイルブレーク検出ポリシーの構成の詳細は、「ジェイルブレーク検出ポリシー」を参照してください。
ユーザーID、クライアントID/名前、クライアントIPアドレス、サービス・プロファイル、アサーション・トークン・カテゴリおよびトークン作成/有効期限などの基準を使用して、トークンを検索できます。「トークン・ライフサイクル管理」ページを使用して、発行されたトークンを取り消すことができます。
トークン・ライフ・サイクル管理の構成の詳細は、「トークン・ライフサイクル管理」を参照してください。
