ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2)
B69533-02
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

41 アイデンティティ・コンテキストの使用方法

アイデンティティ・コンテキストにより、組織は、Oracle Access Managementプラットフォームに組み込まれているコンテキストを意識したポリシー管理および認可機能を活用することで、増大するセキュリティの脅威に対応できます。アイデンティティ・コンテキストでは、従来のセキュリティ制御(ロールやグループなど)とともに、認証および認可中に確立される動的データ(認証強度、リスク・レベル、デバイス・トラストなど)を使用することで、リソースへのアクセスのセキュリティが確保されます。次の項では、アイデンティティ・コンテキストの詳細とその使用方法について説明します。

41.1 アイデンティティ・コンテキストの概要

エンタープライズ・アプリケーション・インフラストラクチャがサポートするビジネス・アプリケーションをWeb対応にするために、それらのインフラストラクチャには過去10年間にわたって変更が行われてきました。これらの変更によって、様々なタイプのデバイスを使用した、より多くのユーザーによるアクセスが可能になっています。ユーザー数の増加に伴う追加のリスクに対応するために、アクセス管理に使用される基盤となるセキュリティ・モデルは、サイロベースの実装から、より動的なものへと進化し、アイデンティティおよびリスク・データがアプリケーション配信プロセス全体のコンポーネントにわたって共有されるようになりました。この動的な実装は、Webシングル・サインオン(SSO)、きめ細かな認可、Web Services Security、Identity Federationなどを提供することでセキュリティ制御を特定のランタイム・デプロイメント環境(Webサーバーまたはアプリケーション・サーバー・コンテナ)内に集約し、ポリシーベースのセキュリティ制御を提供することでアプリケーション・リソースへのアクセスを管理するシステムに依存します。さらに、アイデンティティおよびリスク・データによって、アクセスを要求しているユーザーのコンテキストが提供されます。

アプリケーション・セキュリティ制御は、最初は、特定のエンタープライズ・アプリケーション・デプロイメント・パラダイム(たとえば、すべてのWebサーバー・アプリケーション、すべてのWebサービス・アプリケーション、またはすべてのアプリケーション・サーバー・アプリケーション)内のサイロの統合に焦点が当てられていましたが、今日では内外のセキュリティの脅威のプレゼンスの増加により、増大するリスクを適切に管理するために異なるセキュリティ・モデルの統合が必要とされています。

この要件は、クラウドおよびモバイル・コンピューティング・パラダイムの出現によりさらに拡大されました。そこでは、アプリケーションは、もはやセキュアなエンタープライズの保護された範囲内で整然と実行されるコンポーネントで構成されているものではなくなりました。

アプリケーションがクラウド・サービスを活用するには、独自の方法でサイロ化されているそれらのサービスから生じるリスクの増大を解決する必要がありました。クラウド・デプロイメントおよびモバイル配信チャネルに対する脅威の数は着実に増加しており、エンドツーエンド・アプリケーション配信プロセスに、広範な脅威への対処に不可欠なポリシー制御を実装することが必要となっています。これらのポリシー制御では、どのセキュリティの決定を行う必要があるのかを踏まえて、要求側のユーザーに関する情報にアクセスすることが必要です。したがって、セキュリティ・ポリシー管理インフラストラクチャはコンテキストを意識したものにして、管理者が、保護されているアプリケーション環境へのアクセスを要求するユーザーに対して適用するセキュリティのレベルを制御するポリシーを作成できるようにする必要があります。

以前は、アイデンティティ・コンテキストは、1つ以上のアイデンティティ・ストア(LDAPディレクトリやSQLデータベースなど)のアイデンティティ・レコードのプレゼンスによって定義されていました。アイデンティティ・レコードには、プロファイル属性、そのユーザーがメンバーになっているグループ、およびエンタープライズ・ロールが含まれます。しかし、Web、クラウド、およびモバイル・アプリケーションの配信チャネルの範囲は絶え間なく拡大しているため、アイデンティティに関してさらに動的な情報を意識した認可ポリシー制御が必要です。この情報は、保護されているリソースへのアクセスを試みるアイデンティティと関連付けられており、次の一部またはすべてを含む場合があります。

次の例は、アイデンティティ・コンテキスト・データがアプリケーションによってどのように使用される可能性があるのかを示しています。アプリケーションは、次のように動作する場合があります。

アイデンティティ・コンテキストの概念をアクセス管理に組み込むことで、制御は、アイデンティティ・プロファイルに含まれているとは限らない動的データ(アイデンティティ・コンテキスト属性と呼ばれる)を使用して決定できるようになりました。つまり、アイデンティティ・コンテキストは、特定の保護されているリソースにアクセスするユーザーの要求を取り巻く環境および状況と考えられます。それは、アクティビティの範囲、地理的な領域、通信プラットフォーム、アプリケーション、あるいは論理または物理ドメインである場合があります。

41.2 アイデンティティ・コンテキストの理解

このリリースでは、Access Managerは、Oracle Access Managementプラットフォームの組込みサービスとしてアイデンティティ・コンテキストを組み込むことで、コンテキストを意識したアクセス管理を可能にします。図41-1は、複数のシステム・コンポーネントによって実装されているアイデンティティ・コンテキスト・プロセスのフローを示しています。各アプリケーション配信コンポーネントには、アプリケーションのその個別のスライスの保護を担うそれ自体のセキュリティ・ポリシー・インフラストラクチャがあります。この特定のユース・ケースには、エンド・ユーザー・デバイス、静的GUIページを実行するWebサーバー、動的コンテンツをレンダリングするポータル・サーバーを実行するアプリケーション・サーバー、Webサービス・エンドポイントを公開するサービス・バス・サーバー、トランザクション・データを格納するデータベース・サーバー、およびアイデンティティ・プロファイル・データを格納するLDAPサーバーが含まれています。

図41-1 エンドツーエンド・アイデンティティ・コンテキスト・プロセス

図41-1の説明が続きます
「図41-1 エンドツーエンド・アイデンティティ・コンテキスト・プロセス」の説明

プロセスの各コンポーネントには、保護されているリソースへのアクセスを制御する認可ポリシーが管理者によって定義され、実行時に適用されるそれ自体のセキュリティ・インフラストラクチャがあります。さらに、それらのコンポーネントのいくつかまたはすべてで、ポリシー管理をOracle Entitlements Serverなどの外部認可サーバーに外在させる場合もあります。アプリケーションがOracle Platform Security Servicesを活用して構築されている場合がこれに該当します。図41-2は、構成しているOracleアプリケーションに基づいたアイデンティティ・コンテキストの機能アーキテクチャを示しています。

図41-2 エンドツーエンド・アイデンティティ・コンテキスト・プロセスのコンポーネント

図41-2の説明が続きます
「図41-2 エンドツーエンド・アイデンティティ・コンテキスト・プロセスのコンポーネント」の説明

図から明らかなように、コンテキストを意識したセキュリティ・ポリシー管理は、Oracle Access Managementプラットフォームを活用することで実現されます。このプラットフォームには、エンドユーザーのアプリケーションを変更することなくアイデンティティ・コンテキスト属性(リスク・スコア、トラステッド・デバイス・データ、認証データなど)を操作および適用するためのネイティブ・サポートが含まれています。

41.3 アイデンティティ・コンテキスト・サービスの操作

Oracle Access Managementプラットフォームにより、アイデンティティ・コンテキスト・データを収集し、関与するコンポーネントに伝播し(図41-2に定義)、保護されているリソースへのアクセス権限を付与または拒否するために使用可能にできます。アイデンティティ・コンテキスト・サービスにより、アイデンティティ・コンテキストAPIを介したアイデンティティ・コンテキスト・ランタイムへのアクセスが可能になります。アイデンティティ・コンテキスト・ディクショナリ・スキーマによって、アイデンティティ・コンテキスト属性が指定されます。次の項では、これらのコンポーネントについて詳しく説明します。

41.3.1 アイデンティティ・コンテキスト・ディクショナリの使用方法

アイデンティティ・コンテキスト・アーキテクチャの中心となるのは、アイデンティティ・コンテキスト・ディクショナリです。このディクショナリは、Oracle Access Managementプラットフォームで定義されているアイデンティティ・コンテキスト属性を指定することでアイデンティティ・コンテキスト・スキーマを定義します。そのスキーマでは、namespace : attributeと等しい一意の名前で各属性が記述されます。表41-1は、それらのスキーマ属性を示しています。


注意:

仮想属性(表41-1に記載)は、特定の属性の作成元となるアイデンティティ情報の抽象クラスを表します。仮想属性を公開する場合、アイデンティティ・コンテキストAPIは、属性値にattr-name=attr-valueが含まれていることを想定します。実際の属性は、名前namespace : attribute : attr-nameとattr-valueの値を使用して作成されます。この方法により、Oracle Access Managementコンポーネントによって直接管理されていないソースからの値を持つ属性の公開が可能になります。

表41-1 アイデンティティ・コンテキスト・スキーマ属性

ネームスペース 属性 タイプ 仮想 プライマリ・パブリッシャ 説明

oracle:idm:claims:nameid

value

文字列

不可

OAM

一意のユーザー識別子を示します。Access Managerは現在ユーザーDNを公開しています

oracle:idm:claims:nameid

format

文字列

不可

OAM

ユーザー識別子のタイプを示します。Access Managerは現在urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectNameを公開しています

oracle:idm:claims:nameid

qualifier

文字列

不可

OAM

ユーザーが属する論理アイデンティティ・ドメインを示します。Access Managerは、現在、UserIdentityStore1などのアイデンティティ・ストアの論理名を公開しています。

oracle:idm:claims:nameid

spprovidedid

文字列

不可

OAM

SP自体のアイデンティティ・ストアでユーザーを見つけるためにすべてのSPで使用できる一意の識別子を示します。Access Managerは、現在、登録済アイデンティティ・ストアで構成されている一意のID属性の値を公開しています。

oracle:idm:claims:client

firewallenabled

ブール

不可

OESSO

クライアント・デバイスでファイアウォールが有効化されていることを示します。

oracle:idm:claims:client

antivirusenabled

ブール

不可

OESSO

クライアント・デバイスでウイルス対策が有効化されていることを示します。

oracle:idm:claims:client

fingerprint

文字列

不可

OESSO、Oracle Access Management Mobile and Social (OMS)

クライアント・デバイスのフィンガープリントを示します。

oracle:idm:claims:client

ostype

文字列

不可

OMS

クライアント・デバイスのオペレーティング・システム・システム・タイプを示します。

oracle:idm:claims:client

osversion

文字列

不可

OMS

クライアント・デバイスのオペレーティング・システム・バージョンを示します。

oracle:idm:claims:client

jailbroken

ブール

不可

OMS

クライアント・デバイスがジェイルブレーク(iOS)またはルート化(Android)されているかどうかを示します。

oracle:idm:claims:client

macaddress

文字列

不可

OMS

クライアント・デバイスのイーサネット(MAC)アドレスを示します。

oracle:idm:claims:client

ipaddress

文字列

不可

OMS

クライアント・デバイスのクライアントIPアドレスを示します。

oracle:idm:claims:client

vpnenabled

ブール

不可

OMS

クライアントのデバイスでVPNが有効化されているかどうかを示します。

oracle:idm:claims:client

geolocation

文字列

不可

OMS

クライアント・デバイスの場所の地理的座標を緯度,経度の形式で示します。

oracle:idm:claims:risk

newdevice

ブール

不可

OAAM

クライアント・デバイスが既知であるかどうかを示します。既知でないデバイスからログインされている場合はtrue、それ以外の場合はfalseです。

oracle:idm:claims:risk

level

整数

不可

OAAM

リスク・レベルを示します。レベルはログインの失敗後に増加します。

oracle:idm:claims:risk

safeforuser

ブール

不可

OAAM

ユーザーが2番目のチャレンジ質問に回答したかどうかを示します。ユーザーがそれに適切に回答した後はtrue、それ以外の場合はfalseです。

oracle:idm:claims:risk

fingerprint

文字列

不可

OAAM

OAAMによって測定されるデバイス・フィンガープリントを示します。デバイスごとに、残されるフィンガープリントが異なります。デバイス(Flashを介して取得)のフィンガープリントとブラウザ(httpのみ)のフィンガープリントの間で切り替えることができます。

oracle:idm:claims:session

authnlevel

整数

不可

OAM

Access Managerの認証レベルを示します

oracle:idm:claims:session

usercount

整数

不可

OAM

ユーザーによって保持されるセッション数を示します

oracle:idm:claims:session

appdomain

文字列

不可

OAM

ポリシーが含まれているAccess Managerアプリケーション・ドメインの名前を示します。

oracle:idm:claims:session

apppolicy

文字列

不可

OAM

アクセスを許可したAccess Managerポリシーの名前を示します

oracle:idm:claims:session

appagent

文字列

不可

OAM

Access Managerにリクエストを送信したエージェントの名前を示します

oracle:idm:claims:session

appclientip

文字列

不可

OAM

Access Managerにリクエストを送信したクライアントのIPアドレスを示します

oracle:idm:claims:session

sessionid

文字列

不可

OAM

Access ManagerセッションIDを示します

oracle:idm:claims:session

attributes

文字列

可

OAM

セッション・ストアから取得されるセッション属性を示します。たとえば、Access Managerで、要求名としてoracle:idm:claims:session:attributesを選択し、attr-name=$session.attr.nameという表記法を使用してセッション属性を指定します(nameは、そのセッションに格納される属性の名前)。要求は、oracle:idm:claims:session:attributes:attr-nameの名前と、セッションのname属性に等しい値で作成されます。

oracle:idm:claims:fed

partner

文字列

不可

OAMまたはIF

Identity Federationによって判別されるパートナIDを示します

oracle:idm:claims:fed

nameidvalue

文字列

不可

OAMまたはIF

Identity Federationによって判別されるフェデレーション・パートナのユーザーIDを示します

oracle:idm:claims:fed

nameidformat

文字列

不可

OAMまたはIF

Identity Federationによって判別されるフェデレーション・パートナのユーザーIDの形式を示します

oracle:idm:claims:fed

attributes

文字列

可

OAM

パートナによって提供され、Identity Federationによって判別されるフェデレーション属性を示します。たとえば、Access Managerで、要求名としてoracle:idm:claims:fed:attributesを選択し、attr-name=$session.attr.fed.attr.nameという表記法を使用してフェデレーション属性を指定します(nameは、パートナのSAMLアサーションでのSAML属性の名前)。要求は、oracle:idm:claims:fed:attributes:attr-nameの名前と、SAMLのname属性で提供されるパートナのアサーションに等しい値で作成されます。

oracle:idm:claims:ids

attributes

文字列

可

OAM

たとえば、Access Managerで、要求名としてoracle:idm:claims:ids:attributesを選択し、attr-name=$user.attr.nameという表記法を使用してIDストア属性を指定します(nameは、ユーザー・プロファイル上のその属性の名前)。要求は、oracle:idm:claims:ids:attributes:attr-nameの名前と、ユーザー・プロファイルのname属性に等しい値で作成されます。

oracle:idm:claims:tenant

tenantid

文字列

不可

OAM

現在、今後の使用のために予約済です。(テナントIDを示します。)

oracle:idm:claims:tenant

attributes

文字列

可

OAM

現在、今後の使用のために予約済です。(パブリッシャによって提供されるテナント属性を示します。この要求値は、attr-name=attr-valueを含むことになります。要求は、oracle.idm:claims:tenant:attr-nameの名前と、attr-valueの値で作成されます。)

41.3.2 アイデンティティ・コンテキスト・ランタイムの理解

アイデンティティ・コンテキスト・ランタイムは、アイデンティティ・コンテキスト属性(アイデンティティ・コンテキスト・ディクショナリで定義される)のコレクションを参照します。それは、その属性に対して権限を持つと認識されている様々なトラステッド・アプリケーション・コンポーネントまたはセキュリティ・フレームワーク、あるいその両方によってアサートされます。これが、Oracle Access Managementプラットフォームです。ランタイム・コンテキストは、現在の状況、環境、背景、または設定を表し、それらによってランタイム・アプリケーション環境でのアイデンティティに対するイベントの意味が判別、指定、または明確化されます。

Oracle Access Managementプラットフォームでは、Context Management Engine (CME)と呼ばれる共通インフラストラクチャ・コンポーネントが活用されます。CMEにより、Oracle Access Managementプラットフォームを介して処理されるすべてのトランザクションに対してアイデンティティ・コンテキストが生成されることが保証されます。CMEによって収集されるコンテキスト・データは、WebチャネルまたはWebサービス・チャネルおよびOracle Access Managementプラットフォームで使用可能なソフトウェア製品の多くを使用してユーザーが実行するトランザクションに適用されます。バックエンドで開始されるいくつかのトランザクションにも、アイデンティティ・コンテキストへのアクセスが必要な場合があり、アイデンティティ・コンテキストがある程度の期間、永続化されることが必要な場合があります。

一般的なOracleミドルウェア・デプロイメントでは、アイデンティティ・コンテキスト・ランタイムは主にOracle Access Managementプラットフォームによって、保護されているアプリケーションのかわりにポリシーベースの決定を実行するために利用されます。ただし、コンテナ内で実行されているどのアプリケーションも、アイデンティティ・コンテキストAPIを活用することでアイデンティティ・コンテキスト・ランタイムを直接統合および使用することが可能です。使用可能なアイデンティティ・コンテキスト・データの量は、デプロイされている製品に応じて異なります。そのままで使用できるデフォルトのセットのアイデンティティ属性が用意されます。これらは主にAccess ManagerでIDアサーションを活用することで構成されます。表41-1「アイデンティティ・コンテキスト・スキーマ属性」は、これらのデフォルト属性を示しています。次のリストは、アイデンティティ・コンテキスト・ランタイムのエンドツーエンドのフローの詳細を示しています。そのリストの下の図41-3は、フローを示しています。

プロセスの概要: アイデンティティ・コンテキスト・ランタイムのエンドツーエンドのフロー

  1. ユーザーが、保護されているアプリケーションにデバイスからアクセスします。

  2. Access Managerによって、アイデンティティがアサートされ、コンポーネントを公開する関連Access Managementからアイデンティティ属性が収集され、アイデンティティ・コンテキストが作成されます。

  3. Access Managerによって、IDアサーション(SAMLセッション・トークン)が生成され、アイデンティティ・コンテキスト属性が組み込まれます。Access Manager Identity Asserterによって、IDアサーションが処理され、OPSS属性サービスを使用してWebLogic Serverコンテナにアイデンティティ・コンテキストが公開されます。

  4. 保護されているアプリケーションによってOES PEP APIが呼び出され、認可の決定が行われます。OESによってアイデンティティ・コンテキストがローカルOES PDPに自動的に伝播されます。

  5. OESによって、適切な認可ポリシーが検索され、その条件が(アイデンティティ・コンテキスト属性に基づいて)評価されます。評価は、組込みのアイデンティティ・コンテキスト関数またはカスタム関数を使用して実行できます。

  6. 保護されているアプリケーションによって、JRF Webサービス呼出しが行われ、その中でOracle Web Service Manager (OWSM)クライアントによってSAMLトークンが使用され、アイデンティティ・コンテキストがWebサービス・アプリケーション環境に伝播されます。

  7. OWSM (Webサービス側)によってそのアイデンティティ・コンテキストでSAMLアサーションが処理され、OPSS属性サービスを使用することによってそのアイデンティティ・コンテキストがWebLogic Serverコンテナに公開されます。

  8. Webサービス・アプリケーションによってOES PEP APIが呼び出され、認可の決定が行われます。

  9. OESによってアイデンティティ・コンテキストがリモートOES PDPに自動的に伝播され、そこでアイデンティティ・コンテキスト属性に基づいた条件が、組込みのアイデンティティ・コンテキスト関数またはカスタム関数を使用して評価されます。

図41-3 アイデンティティ・コンテキストのプロセス・フロー

図41-3については周囲のテキストで説明しています。

CMEによって、アイデンティティ・コンテキストがアプリケーション層および基盤となるアプリケーション・サーバー・コンテナに伝播されると、そのアイデンティティ・コンテキストはコンテナおよびその中で実行されているアプリケーションから使用できるようになります。表41-2は、アイデンティティ・コンテキストを使用して動作する場合に、どのアクセス管理プラットフォーム製品によって何が実行されるのかを示しています。

表41-2 アイデンティティ・コンテキスト操作のマッピング

ロールおよびコンテキスト操作 説明 コンポーネント

パブリッシャ - アイデンティティ・コンテキストの公開

アプリケーション・コンポーネントを保護するトラステッド・セキュリティ・フレームワークは、アイデンティティまたはアイデンティティのアクセス要求、あるいはその両方に関する適切なファクトを、別のトラステッド・セキュリティ・フレームワークから取得するか、それが使用できる情報から導出します。

権限を持つコンポーネントによって収集される情報は、コンポーネントのランタイム・フレームワークで使用できる環境コンテキストに基づいています。たとえば、Access Managerによって、ユーザーの認証強度のレベルが判別され、OAAMによって特定のオンライン・セッションに関連付けられているリスク・スコアが計算され、OESSOによってクライアント・デバイスでファイアウォールが有効化されているかどうかが判別されます。

  • OAM – セッション、フェデレーション、およびアイデンティティ・スコア属性

  • OAAM – リスク属性

  • OESSO – デバイス属性

  • OMS Mobile SDK - デバイス属性

プロパゲータ - アイデンティティ・コンテキストを伝播する

トラステッド・セキュリティ・フレームワークによってアイデンティティ・コンテキスト属性が伝播され、別のアプリケーション・セキュリティ・フレームワークによって使用されるかアプリケーションによって直接使用されます。たとえば、OAAMによって、ユーザーのリスク・スコアがそのユーザーのAccess Managerセッションに伝播され、Access Managerによって、認証済ユーザーの一意のIDおよび認証レベルとともにIDアサーション(SAMLトークン)が伝播され、OWSMクライアントによって現在のアイデンティティ・コンテキストが、Webサービスに伝播され、そこで、OWSMエージェントによってWebサービス・アプリケーションでアイデンティティ・コンテキストが再構築されます。

  • OAMはWeb層とコンテナ層の間にあります

  • OWSMはWebサービス・クライアント層とWebサービス層の間にあります

  • OPSSはAccess Manager Identity AsserterまたはOWSMエージェントとWebLogic Serverコンテナの間にあります

  • OMSはOMS Mobile SDKとAccess Managerの間にあります

評価者 - アイデンティティ・コンテキストを評価する

アイデンティティ・コンテキスト属性を使用するトラステッド・セキュリティ・フレームワークまたはエンドユーザー・アプリケーションです。ポリシー決定を実行するか、アプリケーションのビジネス・ロジックをパーソナライズします。たとえば、OAAMが存在し、リスク・スコアを計算するように構成されている場合、OES内のアプリケーションの認可ポリシーによって、そのリスク・スコアが特定のしきい値未満のときにのみアクセスが許可されます。また、Access ManagerでIdentity Federationが構成されている場合、そのアプリケーションによって、パートナが提供するアサーション(アイデンティティ・コンテキストで入手可能)が使用され、OESを使用してトランザクションへのアクセスが認可されます。

  • OAM – Web境界ポリシー

  • OWSM – Webサービス・ポリシー

  • OES – アイデンティティ・コンテキストが存在するコンテナから行われたすべてのPEP API呼び出しに対するアプリケーション固有またはWLS固有ポリシーこれには、すべてのADFアプリケーション、IAMアプリケーション、カスタム・アプリケーションなどが含まれます。

41.4 アイデンティティ・コンテキストAPIの使用方法

アイデンティティ・コンテキストAPIは、アイデンティティ・コンテキスト・ディクショナリおよびアイデンティティ・コンテキスト・ランタイムと連動するように設計されたJavaクラスのセットです。このAPIは、Oracle Java Required Files (JRF)の一部であるIdentityContext.jarとして配布されます。例41-1は、アイデンティティ・コンテキスト・ディクショナリと連動するアプリケーションを示しています。

例41-1 アイデンティティ・コンテキスト・ディクショナリとの連動

// Display Identity Context Dictionary
try {
  ClaimDictionary idCtxDict = new ClaimDictionary();
  System.out.println
    ("IDC Dictionary :" + idCtxDict.getClaimCount() + "attributes");
  Iterator<String> iterNamespace = idCtxDict.getAllNamespaces();
  while (iterNamespace != null && iterNamespace.hasNext()) {
    String namespace = iterNamespace.next();
    System.out.println("Namespace : " + namespace);
    Iterator<ClaimSchema> 
iterClaimSchema=idCtxDict.getClaimsForNamespace(namespace);
    while (iterClaimSchema != null && iterClaimSchema.hasNext()) {
      out.println(iterClaimSchema.next().getUniqueName());
    }
  }
} catch (Exception e) {
  System.out.println("Unable to acquire IDC Dictionary. " + toString());
}

アプリケーションは、アイデンティティ・コンテキスト・ランタイムと連動し、アプリケーション・インフラストラクチャに現在存在しているアイデンティティ・コンテキストのランタイム状態を取得します。保護されたアプリケーションがアイデンティティ・コンテキスト・ランタイムと連動するには、Oracle Fusion Middleware PS5(PS5用のOPSS Opatchを適用)またはOracle Fusion Middleware PS6以降で作成されたWebLogic Serverドメインに、そのアプリケーションをデプロイする必要があります。

さらに、アイデンティティ・コンテキスト・ランタイムとの連動は権限付き操作であり、WebLogic Server(必要なアイデンティティ・コンテキスト・サポートがある)で実行されているアプリケーションに適切なソース・コード・グラントがあることを必要とします。WebLogic Serverコンテナ内で実行されている、権限のあるアプリケーションは、OPSS属性サービスに要求することでアイデンティティ・コンテキスト・ランタイムにアクセスできます。例41-2は、WLSTを使用してOPSS属性サービスにアプリケーション(この場合はssofilter.jar)へのアクセス権を付与する方法を示しています。

例41-2 属性サービスにアプリケーションへのアクセス権を付与するためのWLSTの使用方法

# sh ../oracle_common/common/bin/wlst.sh
connect ('<username>', '<password>','t3://localhost:7001')
grantPermission(codeBaseURL="file:${common.components.home}/
   modules/oracle.ssofilter_11.1.1/ssofilter.jar", permClass="oracle.security.jps.service.attribute.AttributeAccessPermission",
   permTarget="*", permActions="get, set, remove") 
exit()

例41-3は、アイデンティティ・コンテキスト・ランタイムと連動するアプリケーションを示しています。

例41-3 アイデンティティ・コンテキスト・ランタイムとの連動

import java.security.AccessController;
import java.security.PrivilegedAction;
import oracle.security.jps.internal.api.runtime.AppSecurityContext;
import oracle.security.idm.IdentityContext;
 
…
 
// get runtime ID Context from OPSS
private static Object getIDContext() {
  Object idc = AccessController.doPrivileged(new PrivilegedAction<Object>() {
                    public Object run() {return AppSecurityContext.getSecurityContext().getAttribute
  (oracle.security.idm.IdentityContext.Constants.IDC_API_ID); }});
  return idc;
}
 
…
 
// Display runtime ID Context
try {
  Context idCtx = (Context)getIDContext();
  if (idCtx != null) {
    System.out.println("IDC Runtime :" + idCtx.getSize() + "attributes");
    Iterator<Claim> i = idCtx.getClaims();
    while (i != null && i.hasNext()) {
      Claim c = i.next();
      System.out.println(c.getName() + " : " + c.getValue());
    }
  } else {
    System.out.println("Identity Context Runtime is not available");
  }
} catch (Exception e) {
  System.out.println("Unable to acquire Identity Context Runtime. " + e.toString());
}
 
…
 
// Obtain few attributes from Identity Context Runtime
Attr authnLevel = ctx.getAttr (Constants.ATTR_SESSION_AUTHN_LEVEL);
Attr isFirewallEnabled = ctx.getAttr(Constants.ATTR_CLIENT_FIREWALL_ENABLED);
Attr isTrustedDevice = ctx.getAttr(Constants.ATTR_RISK_TRUSTED_DEVICE);
 
// Use user's authentication strength established at login by OAM
int authLevel = new Integer(authnLevel.getValue()).intValue();
if (authLevel < 20) {
    // do something
}

詳細は、Oracle Fusion Middleware Oracle Platform Security Services Java APIリファレンスに記載されています。

41.5 アイデンティティ・コンテキスト・サービス・コンポーネントの構成

アイデンティティ・コンテキストのサポートは、表41-2「アイデンティティ・コンテキスト操作のマッピング」にリストされている各関係Oracle Access Managementコンポーネントに事前に統合されています。このため、ビジネス要件に対応するように各コンポーネントを構成する必要があります。

次の項では、必要なアイデンティティ・コンテキスト構成の高度な概要を示します。ただし、詳細は、それぞれの製品に付属のドキュメントを参照してください。

41.5.1 Oracle Fusion Middlewareの構成

保護対象にするアプリケーションは、WebLogic Serverドメインにデプロイする必要があります。このドメインは、Oracle Platform Security Services(OPSS)のPS5用Opatchを適用したOracle Fusion Middleware 11.1.1パッチ・セット(PS5)またはOracle Fusion Middleware PS6以降で作成する必要があります。アプリケーションが実行されているWebLogic Serverドメインは、Access Manager Identity Asserterコンポーネントによって保護されている必要があり、そのコンポーネントによって、Access Managerから受け取ったIDアサーションが検証され、アイデンティティ・コンテキスト・ランタイムの作成プロセスが開始されます。Access Manager Identity Asserterは、トークン・タイプOAM_IDENTITY_ASSERTIONを検出するように構成する必要があります。また、アイデンティティ・コンテキスト・ランタイムと直接連動する保護されているアプリケーションは、OPSS属性サービスと連動するためのソース・コード・グラントを(例41-2のように)付与されている必要があります。


関連項目:

Access Manager Identity Asserterおよびソース・コード・グラントの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

41.5.2 Access Managerの構成

OAMは、アイデンティティ・コンテキストの主なパブリッシャおよびプロパゲータとして、関係コンポーネントからアイデンティティ・コンテキスト・データを収集するための中心的な構成ポイントとして機能します。次の項では、アイデンティティ・コンテキスト管理の背後にあるアーキテクチャの主要な要素について説明します。

41.5.2.1 IDアサーションの構成

Web層とアプリケーション層の間にエンドツーエンド・セキュリティを適切に施行するために、Access Manager認可ポリシーにアサートされた属性を定義することをお薦めします。

IDアサーション(SAMLセッション・トークン)は、Webリソースを保護するWebゲートとアプリケーション・サーバー・コンテナとの間の信頼の確保に加えて、SAML属性としてアイデンティティ・コンテキスト・データを公開するためにも使用されます。

IDアサーションは、有効化されている必要があり、アイデンティティ・コンテキスト内に特定の属性を想定しているビジネス・ロジックの必要に応じてアサートされた属性が移入されている必要があります。それは、OAMポリシー・レスポンスタブ内で構成され、認証と認可の両方のポリシーに対して定義できます。


関連項目:

Access Manager IDアサーションおよびアサートされた属性(表17-11)。

41.5.2.2 フェデレーション属性の構成

リソースをAccess Manager認証スキームFederationSchemeで保護すると、Access Managerはサービス・プロバイダのように動作し、フェデレーション・パートナによって提供されるSAMLアサーションを受け取るようになります。フェデレーション・シングル・サインオン(SSO)操作の後、次の属性が、認証済アイデンティティのAccess Managerセッションに存在するようになります。

  • $session.attr.fed.partner (パートナ名を含む)

  • $session.attr.fed.nameidvalue (SAML名前ID値を含む)

  • $session.attr.fed.nameidformat (SAML名前IDフォーマットを含む)

  • SAML属性ごとに1つの$session.attr.fed.attr.nameエントリ(パートナから受け取るSAMLアサーションに含まれる)

    これらのフェデレーション属性は、アサートされた属性としてoracle:idm:claims:fed:attributesを選択し、その値をattr-name=$session.attr.fed.attr.nameに設定することでIDアサーションの構成に使用できます。attr-nameは、アイデンティティ・コンテキスト属性に指定されている名前、nameは、パートナのSAMLアサーション内のSAML属性の名前です。

    たとえば、partner-role=$session.attr.fed.attr.roleの値でoracle:idm:claims:fed:attributesを定義すると、managerという値を持つアイデンティティ・コンテキスト属性oracle:idm:claims:fed:attributes:partner-roleが作成されます($session.attr.fed.attr.roleに、SAML属性roleに対してパートナのSAMLアサーションで指定されているmanagerが含まれていると想定します)。

41.5.2.3 セッション属性の構成

Access Managerセッション属性は、アサートされた属性としてoracle:idm:claims:session:attributesを選択し、その値をattr-name=$session.attr.nameに設定することでIDアサーションの構成に使用できます。attr-nameは、アイデンティティ・コンテキスト属性に指定されている名前、nameは、Access Managerセッション属性の名前です。

たとえば、authn-strength=$session.attr.authnlevelの値でoracle:idm:claims:session:attributesを定義すると、ログイン・プロセス中に使用される認証スキームによって定義されている値を持つアイデンティティ・コンテキスト属性oracle:idm:claims:session:attributes:authn-strengthが作成されます。

41.5.2.4 アイデンティティ・ストア属性の構成

アイデンティティ・ストア属性は、アサートされた属性としてoracle:idm:claims:ids:attributesを選択し、その値をattr-name=$user.attr.nameに設定することでAccess Manager IDアサーションの構成に使用できます。attr-nameは、アイデンティティ・コンテキスト属性に指定されている名前、nameは、アイデンティティ・ストア属性の名前です。

たとえば、first-name=$user.attr.fnameの値でoracle:idm:claims:ids:attributesを定義すると、アイデンティティ・ストアに保持されているそのユーザーのfname属性の値を持つアイデンティティ・コンテキスト属性oracle:idm:claims:ids:attributes:first-nameが作成されます。

41.5.3 Oracle Adaptive Access Managerの構成

Oracle Access ManagerとOracle Adaptive Access Manager (OAAM)との間の統合の一部として、OAAMはリスクベースのアイデンティティ・コンテキスト属性を公開および伝播します。この場合、OAAM属性は、ユーザー認証フロー(OAAM側)の終わりにDAPトークンでOAMに渡されます。DAPトークンは、表41-1「アイデンティティ・コンテキスト・スキーマ属性」のoracle:idm:claims:riskネームスペースによって定義される属性を伝送します。その後、OAMによってこれらの属性が$session.risk.attrネームスペースにプッシュされます。次の項では、OAAMとOAMの構成について説明します。

41.5.3.1 Oracle Adaptive Access Managerのセットアップ

この項では、OAAMのインストールおよびセットアップについて説明します。

Oracle Adaptive Access Managerをセットアップするには

  1. スナップショットをインポートすることで、OAAMをセットアップします。

    詳細は、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドを参照してください。

  2. 『Oracle Fusion Middleware Oracle Access Manager統合ガイド』に記載されているようにOAAMとAccess Managerを統合します。

    TAPトークンのバージョンは、v2.0ではなくv2.1であることが必要です。

  3. 次のプロパティがtrueに設定されていることを確認します。

    • oracle.oaam.idcontext.enabledは、デフォルトでtrueになっています。この値を変更するには、OAAM管理コンソールを使用します。

    • bharosa.uio.default.registerdevice.enabledは、safeforuser要求が適切に処理されるためにはtrueであることが必要です。

  4. OAAM管理コンソールから、「プロパティ」、「新規プロパティの作成」に移動します。

  5. v2.1に等しい値を持つプロパティ名oaam.uio.oam.dap_token.versionを入力します。

  6. oaam_server_server1を再起動します。

41.5.3.2 OAAM統合のためのAccess Managerの構成

次の手順を実行します。TAPSchemeを使用すると、強制的に、ユーザーがOAAM認証スキームを使用して認証されるようになります。


注意:

OAAM AdvancedまたはOAAM Basicを使用しないでください。

OAAMと統合するようにAccess Managerを構成するには

  1. 認証にTAPSchemeを使用して(表16-20)、リソースを保護します(「特定のリソースに対する認証ポリシーの定義」)。

  2. 次のチャレンジ・パラメータをTAPSchemeに追加します(表16-21)。

    TAPOverrideResource=http://IAMSuiteAgent:80/oamTAPAuthenticate

41.5.3.3 OAAMによって公開されるアイデンティティ・コンテキスト・データの検証

次の情報は、OAAMによって公開されるアイデンティティ・コンテキスト・データの検証方法を示しています。

  • oracle:idm:claims:risk:newdeviceは、新しいデバイスからのログイン後はtrueになり、それ以外の場合はfalseになります。

  • oracle:idm:claims:risk:levelは、いくつかの失敗したログインに続く成功したログインの後に高い値になります。これについてテストするには、いくつかの失敗するログインの後に、成功するログインを実行してみます。

  • oracle:idm:claims:risk:safeforuserは、チャレンジ質問にユーザーが適切に回答した後、trueになります。

  • oracle:idm:claims:risk:fingerprintには、ユーザーのデバイスのフィンガープリントが含まれます。デフォルトでは、HTTPヘッダー・データから構築されたフィンガープリントが使用されますが、それが使用できない場合は、Flashから構築されたフィンガープリント・データが使用されます。様々なフィンガープリントについてテストするには、様々なデバイスを試してみます。

41.5.4 Webサービス・セキュリティ・マネージャの構成

次のように実行して、Oracle Web Service Security Manager (OWSSM)がアイデンティティ・コンテキストを伝播できるようにします。

アイデンティティ・コンテキストに対応するようにWeb Service Security Managerを構成するには

  1. アイデンティティ・コンテキストをサポートしているOWSSMセキュリティ・ポリシーを変更してtrueの値を持つpropagate.identity.context要素を含めることで、セキュリティ・ポリシーを構成します。


    注意:

    propagate.identity.context(デフォルトではfalse)は、SAML関連ポリシーの構成オーバーライド・プロパティです。それをグローバルに有効化するには、そのプロパティをtrueに設定してグローバル・ポリシーを構成します。

  2. SAMLアサーションとメッセージに署名するように、キーストアと証明書ストアを構成します。更新したキーストアと証明書ストアを、domain_home/config/fmwconfig/ディレクトリにコピーします。

41.5.5 Oracle Entitlements Serverの構成

Oracle Entitlements Server (OES)とのランタイムの統合は完全に自動化されています。アプリケーションによってPEP APIが起動され、認可コールが行われると、PEP APIによってアイデンティティ・コンテキスト・ランタイム全体が、条件(アイデンティティ・コンテキストを定義するポリシー・オブジェクト)が評価されるOES PDPに自動的に伝播されます。


注意:

認可コールを行うときは、newPepRequest()メソッドに渡される最後の引数が、nullではなく、少なくともこの例で示すように空のhashmapであることを確認します。

PepRequestFactory requestFactory =  
   PepRequestFactoryImpl.getPepRequestFactory();
PepRequest request = requestFactory.newPepRequest (subject, 
   action, resource, new HashMap<String, Object>());
PepResponse response = request.decide();
boolean isAuthorized = response.allowed();

条件は、セキュリティ管理者がOES管理コンソールを使用して、アイデンティティ・コンテキスト・スキーマに基づいて作成します。次の組込み関数を使用して、アイデンティティ・コンテキスト属性を使用する条件を指定します。

  • ASSERT_IDENTITY_CONTEXT

  • GET_STRING_IDENTITY_CONTEXT

  • GET_INTEGER_IDENTITY_CONTEXT

  • GET_BOOLEAN_IDENTITY_CONTEXT

カスタムOES関数は、既知のリクエスト属性として完全なアイデンティティ・コンテキスト・ランタイム情報を受け取ります。このデータ構造は、アイデンティティ・コンテキストAPIを使用してアイデンティティ・コンテキスト・ランタイムに変換できます。例41-4は、受け取ったパラメータからコンテキストを作成するカスタムOES関数を示しています。

例41-4 アイデンティティ・コンテキストを作成するカスタム関数

public OpssString GET_STRING_IDENTITY_CONTEXT_V2 (
 RequestHandle requestHandle,
 Object[] args,
 Subject subject,
 Map roles,
 Resource resource,
 ContextHandler contextHandler) throws RuntimeException {
 
// Obtain string representation of the runtime ID Context from the request handle.
Context runtimeCtx = null; 
 try {
 AttributeElement ctxAttr = requestHandle.getAttribute
  (Constants.IDM_IDC_API_ID, false);
    if (ctxAttr != null) {  
      String ctxStr = (String) ctxAttr.getValue(); 
      runtimeCtx = new Context(ctxStr);
    } else {
      throw new RuntimeException ("Unable to acquire ID Context from request handle");
    }
  } catch (Exception e) {
    throw new RuntimeException (e.toString());
  }
 
…
 
// start using Context which now contains the same exact Identity Context Runtime as was present in the application that made the PEP API call
…
}

41.5.6 Oracle Enterprise Single Sign Onの構成

アイデンティティ・コンテキスト・サービスの一部として、Oracle Enterprise Single Sign-on(OESSO)は、クライアントベースのアイデンティティ・コンテキスト属性を公開および伝播できます。完全な統合が構成されると、クライアント固有のアイデンティティ・コンテキスト属性(第41.3.1項「アイデンティティ・コンテキスト・ディクショナリの使用方法」に記載)が、アクセス・リクエストで送信されたユーザー資格証明とともにセッション開始リクエストでOESSOによってOAMに送信されます。

リクエストの受信後に、OESSOによって、SSLで保護されているOAM REST API(OESSO管理者によって事前に構成され、OESSOクライアント配布の一部として含まれている)に対するコールが実行されます。このAPIによって、OAM_ID CookieがOESSOに返されます。その後、OESSOによって、有効なOAM_ID Cookieがクライアント・ブラウザ(Internet ExplorerおよびFirefox)に伝播され、それによってOESSOリソースの保護が可能になり、OAM埋込み資格証明コレクタによって保護されるリソースでシングル・サインオン(SSO)が有効になります。(これには、分散型資格証明コレクタによって保護されるリソースは含まれません。)その後、OESSOによって、OAM埋込み資格証明コレクタが受入れ可能なOAM資格証明とともに、ペイロード内のクライアント・コンテキスト情報が提供されます。


注意:

このペイロードは次のものによって保護されます。

  • 16バイト・ランダムSaltの生成

  • その16バイト・ランダムSaltを使用したSHA-256ハッシュの生成

  • OESSOによって保護されるOAMパスワードを使用した要求の暗号化

アイデンティティ・コンテキストの属性を取得するようにOESSOを構成するには

  1. OAMとOESSOの統合の詳細は、Oracle Enterprise Single Sign-On Suite Plusインストレーション・ガイドのログオン・マネージャ・クライアントサイド・ソフトウェアのインストールに関する項を参照してください。

  2. 補足的な詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドのログオン・マネージャでのOracle Access Managementのサポートに関する項を参照してください。

41.5.7 Oracle Access Management Mobile and Socialの構成

Oracle Access Management Mobile and Social (Mobile and Social)は、モバイルおよびデスクトップ・デバイス用にユーザー・プロファイル・サービスおよび認証サービスのほかにRESTベースの認証サービスを提供しています。Access Managerを使用する認証を提供するようにMobile and Socialを構成すると、モバイル・クライアントによって提供されるアイデンティティ・コンテキスト属性をAccess Managerに公開できます。このアイデンティティ・コンテキスト属性は、iOSおよびJavaのプラットフォーム用のMobile and Social SDKによって公開されます。

モバイル・アプリケーションは、Mobile and Social SDKを使用して、Mobile and Socialサーバーによって提供されるサービスにアクセスし、使用します。モバイル・アプリケーションがiOSまたはAndroid APIを使用して認証を実行する場合、それによってアイデンティティ・コンテキスト属性が取得され、そのデータがMobile and Socialサーバーに公開され、そこでその属性がAccess Managerサーバーに公開されます。管理者は、Mobile and Socialサーバーを、すべての属性を取得するように構成することも、必要な属性のみを取得するように構成することもできます。

管理者は、Access Manager管理コンソールの「システム構成」タブの下にある「Mobile and Social」アコーディオンの「アプリケーション・プロファイル構成」ページで、アプリケーションによって送信されるアイデンティティ・コンテキスト属性を構成できます。

Mobile and Socialサーバーは、Mobile and Social SDKからそのサーバーにアプリケーション・プロファイルを求めるアクセスがあったときに、必要なアイデンティティ・コンテキスト属性をMobile and Social SDKに渡します。(アプリケーション・プロファイルには、収集するアイデンティティ・コンテキストと実行する認証のタイプに関する情報が含まれています。)SDKは、属性の収集がユーザーまたはプラットフォームによって許可されている場合はそれを実行し、それらを認証リクエストの一部としてMobile and Socialサーバーに公開します。


注意:

一部のモバイル・プラットフォーム(たとえば、iOS)では、アプリケーションによる特定のデバイス属性(たとえば、UDIDまたはIMEIデバイス番号)の収集が禁止されています。また、そのユーザーは、アプリケーションがロケーションの更新を入手することを拒否できます。そのため、サーバーが属性を要求しても、SDKによってそれらがすべて収集できることは保証されません。

Mobile and Social SDKから収集した属性を、OAMサーバーで作成され維持されているユーザー・セッションに公開するようにMobile and Socialサーバーを構成する場合、管理者は、IDコンテキストを有効化するようにMobile and Socialサーバーを構成する必要があります(図41-4を参照)。

図41-4 OAM認証プロバイダの構成

図41-4については周囲のテキストで説明しています。

アイデンティティ・コンテキストの属性を取得するようにMobile and Socialを構成するには

  1. Mobile and Socialサービスが有効化されていることを確認します(「使用可能なサービスの有効化および無効化」を参照)。

  2. MobileOAMAuthenticationの「サービス・プロバイダ」ページで、IDContextEnabled属性を追加して、その値にtrueを設定します。


関連項目:

  • 構成の完全な詳細は、第38章「モバイル・サービスの構成」を参照してください。

  • iOS SDKを使用してアプリケーションを開発する方法の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

41.6 アイデンティティ・コンテキストの検証

Access Managerを使用してアイデンティティ・コンテキストの適切な操作を確保する手順は、次のとおりです。

アイデンティティ・コンテキストの操作を検証するには

  1. 次のように実行して、Access Managerによって構築されるIDアサーション・レスポンスを検証します。

    1. /testidcリソースをWebゲート・エージェントで保護し、認可レスポンスの一部として目的のアサートされた属性を持つIDアサーションを返すようにAccess Managerを構成します。

    2. OAMテスターを使用して、/testidcに対する認可リクエストへのレスポンスでOAM_IDENTITY_ASSERTION属性としてIDアサーションが返されていることを検証します。

  2. 次のように実行して、WebゲートによってIDアサーションを含むHTTPヘッダーが作成されていることを検証します。

    1. /cgi-bin/printenv.plスクリプトが、/testidcリソースを保護しているものと同じポリシーによって保護されていることを確認します。


      注意:

      printenv.plは、OHSの一部として出荷されており、実行する権限を持っている必要があります。かわりに、ヘッダー情報を表示する任意のスクリプトを使用できます。

    2. printenv.plにアクセスし、ログインを起動し、HTTPヘッダーを表示します。

    3. HTTP_OAM_IDENTITY_ASSERTIONヘッダーに、アサートされた属性を持つSAMLトークンが含まれていることを確認します。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引