1. Oracle Access Management管理者ガイド
  2. アイデンティティ・コンテキストの使用
  3. アイデンティティ・コンテキストの使用

42 アイデンティティ・コンテキストの使用

アイデンティティ・コンテキストにより、組織は、Oracle Access Managementプラットフォームに組み込まれているコンテキストを意識したポリシー管理および認可機能を活用することで、増大するセキュリティの脅威に対応できます。

アイデンティティ・コンテキストでは、従来のセキュリティ制御(ロールやグループなど)とともに、認証および認可中に確立される動的データ(認証強度、リスク・レベル、デバイス・トラストなど)を使用することで、リソースへのアクセスのセキュリティが確保されます。

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

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

アイデンティティ・コンテキストは、特定の保護されているリソースにアクセスするユーザーの要求を取り巻く環境および状況と考えられます。それは、アクティビティの範囲、地理的な領域、通信プラットフォーム、アプリケーション、あるいは論理または物理ドメインである場合があります。

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

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

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

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

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

  • プレゼンス(場所、履歴パターン)

  • 認証強度(弱、強)

  • アシュアランスのレベル(NISTレベル、X509証明書)

  • リスク・アセスメント(パターン分析)

  • フェデレーション(パターン属性)

  • デバイス特性(フィンガープリント、デバイスのヘルス、デバイスの保護、トラステッド・データ)

  • トラステッド・パートナからのアサーション(SAMLトークンなど)

  • シングル・サインオン・セッション(セッション・タイムアウト)

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

  • ユーザーがスマート・カードなど強力な資格証明を使用して認証されていない場合、特定のビジネス機能を無効化します。

  • 組織が(Identity Federationを介して)取引しているビジネス・パートナによって提供されたアイデンティティ・データに基づいてトランザクションへのアクセスのセキュリティを確保します。

  • 不正行為で知られる場所からアクセスされていることが検出された場合、追加の認証資格証明を要求します。

  • 管理者の(サードパーティで管理されている)業界認定証が有効期限切れになっている場合、管理権限の範囲を制限します。

  • 不明なデバイスからアクセスされていることが検出された場合、特定のビジネス機能を無効化します。

アイデンティティ・コンテキストの概念をアクセス管理に組み込むことで、制御は、アイデンティティ・プロファイルに含まれているとは限らない動的データ(アイデンティティ・コンテキスト属性と呼ばれる)を使用して決定できるようになりました。

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

Access Managerは、Oracle Access Managementプラットフォームの組込みサービスとしてアイデンティティ・コンテキストを組み込むことで、コンテキストを意識したアクセス管理を可能にします。

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

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

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

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

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

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

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

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

Oracle Access Managementプラットフォームにより、アイデンティティ・コンテキスト・データを収集し、関与するコンポーネントに伝播し、保護されているリソースへのアクセスを許可または拒否するために使用可能にできます。

詳細は、図42-2を参照してください。アイデンティティ・コンテキスト・サービスにより、アイデンティティ・コンテキストAPIを介したアイデンティティ・コンテキスト・ランタイムへのアクセスが可能になります。アイデンティティ・コンテキスト・ディクショナリ・スキーマによって、アイデンティティ・コンテキスト属性が指定されます。

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

42.3.1 アイデンティティ・コンテキスト・ディクショナリ

アイデンティティ・コンテキスト・アーキテクチャの中心となるのは、アイデンティティ・コンテキスト・ディクショナリです。このディクショナリは、Oracle Access Managementプラットフォームで定義されているアイデンティティ・コンテキスト属性を指定することでアイデンティティ・コンテキスト・スキーマを定義します。

そのスキーマでは、namespace : attributeと等しい一意の名前で各属性が記述されます。表42-1は、それらのスキーマ属性を示しています。

ノート:

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

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

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

oracle:idm:claims:nameid

value

string

いいえ

OAM

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

oracle:idm:claims:nameid

format

string

いいえ

OAM

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

oracle:idm:claims:nameid

qualifier

string

いいえ

OAM

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

oracle:idm:claims:nameid

spprovidedid

string

いいえ

OAM

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

oracle:idm:claims:client

firewallenabled

boolean

いいえ

OESSO

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

oracle:idm:claims:client

antivirusenabled

boolean

いいえ

OESSO

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

oracle:idm:claims:client

fingerprint

string

いいえ

OESSO、Oracle Access Management Mobile and Social (OMS)

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

oracle:idm:claims:client

ostype

string

いいえ

OMS

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

oracle:idm:claims:client

osversion

string

いいえ

OMS

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

oracle:idm:claims:client

jailbroken

boolean

いいえ

OMS

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

oracle:idm:claims:client

macaddress

string

いいえ

OMS

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

oracle:idm:claims:client

ipaddress

string

いいえ

OMS

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

oracle:idm:claims:client

vpnenabled

boolean

いいえ

OMS

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

oracle:idm:claims:client

geolocation

string

いいえ

OMS

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

           
           
           
           

oracle:idm:claims:session

authnlevel

integer

いいえ

OAM

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

oracle:idm:claims:session

usercount

integer

いいえ

OAM

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

oracle:idm:claims:session

appdomain

string

いいえ

OAM

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

oracle:idm:claims:session

apppolicy

string

いいえ

OAM

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

oracle:idm:claims:session

appagent

string

いいえ

OAM

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

oracle:idm:claims:session

appclientip

string

いいえ

OAM

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

oracle:idm:claims:session

sessionid

string

いいえ

OAM

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

oracle:idm:claims:session

attributes

string

はい

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

string

いいえ

OAMまたはIF

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

oracle:idm:claims:fed

nameidvalue

string

いいえ

OAMまたはIF

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

oracle:idm:claims:fed

nameidformat

string

いいえ

OAMまたはIF

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

oracle:idm:claims:fed

attributes

string

はい

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

string

はい

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

string

いいえ

OAM

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

oracle:idm:claims:tenant

attributes

string

はい

OAM

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

42.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アサーションを活用することで構成されます。表42-1では、これらのデフォルト属性について説明しています。次のリストは、アイデンティティ・コンテキスト・ランタイムのエンドツーエンドのフローの詳細を示しています。そのリストの下の図42-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に自動的に伝播され、そこでアイデンティティ・コンテキスト属性に基づいた条件が、組込みのアイデンティティ・コンテキスト関数またはカスタム関数を使用して評価されます。

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

図42-3の説明が続きます
「図42-3 アイデンティティ・コンテキストのプロセス・フロー」の説明

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

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

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

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

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

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

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

  • OESSO – デバイス属性

  • OMS Mobile SDK - デバイス属性

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

トラステッド・セキュリティ・フレームワークによってアイデンティティ・コンテキスト属性が伝播され、別のアプリケーション・セキュリティ・フレームワークによって使用されるかアプリケーションによって直接使用されます。たとえば、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の間にあります

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

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

  • OAM – Web境界ポリシー

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

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

42.4 アイデンティティ・コンテキストAPI

アイデンティティ・コンテキストAPIは、アイデンティティ・コンテキスト・ディクショナリおよびアイデンティティ・コンテキスト・ランタイムと連動するように設計されたJavaクラスのセットです。

このAPIは、Oracle Java Required Files (JRF)の一部であるIdentityContext.jarとして配布されます。次の例では、アイデンティティ・コンテキスト・ディクショナリと連動するアプリケーションを示します。

例55-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属性サービスに要求することでアイデンティティ・コンテキスト・ランタイムにアクセスできます。次の例では、WLSTを使用してOPSS属性サービスにアプリケーション(この場合はssofilter.jar)へのアクセス権を付与する方法を示します。

属性サービスにアプリケーションへのアクセス権を付与するための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()

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

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

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
}

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

各アイデンティティ・コンテキスト・サービス・コンポーネントは、ビジネス要件に対応できるように構成する必要があります。アイデンティティ・コンテキストのサポートは、各関係Oracle Access Managementコンポーネントに事前に統合されています。ここでは、必要なアイデンティティ・コンテキスト構成の概要について説明します。ただし、詳細は、それぞれの製品に付属のドキュメントを参照してください。

表42-2を参照してください

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

42.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属性サービスと連動するためのソース・コード権限を付与されている必要があります。

関連項目:

Access Manager Identity Asserterの構成およびソース・コード権限の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

42.5.2 Access Managerの構成

OAMは、アイデンティティ・コンテキストの主なパブリッシャおよびプロパゲータとして、関係コンポーネントからアイデンティティ・コンテキスト・データを収集するための中心的な構成ポイントとして機能します。

次の項では、アイデンティティ・コンテキスト管理の背後にあるアーキテクチャの主要な要素について説明します。

42.5.2.1 IDアサーション

Web層とアプリケーション層の間にエンドツーエンド・セキュリティを適切に施行するために、Access Manager認可ポリシーにアサートされた属性を定義することをお薦めします。IDアサーション(SAMLセッション・トークン)は、Webリソースを保護するWebゲートとアプリケーション・サーバー・コンテナとの間の信頼の確保に加えて、SAML属性としてアイデンティティ・コンテキスト・データを公開するためにも使用されます。

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

関連項目:

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

42.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が含まれていると想定します)。

42.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が作成されます。

42.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が作成されます。

42.5.3 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/ディレクトリにコピーします。

42.5.4 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を使用してアイデンティティ・コンテキスト・ランタイムに変換できます。次の例は、受け取ったパラメータからコンテキストを作成するカスタムOES関数を示しています。

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

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
…
}

42.5.5 Oracle Enterprise Single Sign Onの構成

アイデンティティ・コンテキスト・サービスの一部として、Oracle Enterprise Single Sign-on (OESSO)は、クライアントベースのアイデンティティ・コンテキスト属性を公開および伝播できます。

完全な統合が構成されると、クライアント固有のアイデンティティ・コンテキスト属性(「アイデンティティ・コンテキスト・ディクショナリ」を参照)が、アクセス・リクエストで送信されたユーザー資格証明とともにセッション開始リクエストで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のサポートに関する項を参照してください。

42.5.6 セキュアなアイデンティティ・コンテキストの伝播の構成

OAM_IDENTITY_ASSERTIONヘッダーは、エンド・ユーザーのアイデンティティをOAMで保護されたアプリケーションに安全に伝播するために使用されます。OAM_IDENTITY_ASSERTIONヘッダーの値は、アイデンティティ・コンテキストを含むBase64でエンコードされた署名付きSAMLトークンです。デフォルトでは、トークンは、サーバーの最初の起動時に、ブートストラップ中に生成された自己署名証明書を使用して署名されます。署名キーおよび証明書は、OAM Keystore at $DOMAIN_HOME/config/fmwconfig/.oamkeystoreに格納されます。

この項では、即時利用可能な署名キーおよび証明書を置換するステップを示します。エンタープライズ・セキュリティ・プラクティスに準拠して発行されたキーおよび証明書を使用することをお薦めします。

ノート:

.oamkeystoreを更新する前に、最新の.oamkeystoreを.oamkeystore_newという名前でバックアップすることをお薦めします。

たとえば、ドメイン・ホーム: <mw>/domains/oam_domainです

次のコマンドを実行して、証明書およびキーを作成します:
  1. openssl req -new -keyout aaa_key.pem -out aaa_req.pem -utf8 -sha256

    ノート:

    キーは、.oamkeystoreファイルと同じパスワードを使用して生成する必要があります。
  2. openssl genrsa -aes256 -out rootCA.key 4096
  3. openssl req -x509 -new -nodes -key rootCA.key -days 7300 -sha256 -out aaa_chain.pem
  4. openssl x509 -req -in aaa_req.pem -CA aaa_chain.pem -CAkey rootCA.key -CAcreateserial -sha256 -out aaa_cert.pem -days 500
  5. openssl x509 -in aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER
  6. openssl pkcs8 -topk8 -nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der -outform DER
次のkeytoolコマンドを実行して、.oamkeystoreを更新します:
  1. keytool -delete -alias assertion-cert -v -keystore oamkeystore_new-storepass <pswd> -storetype JCEKS
  2. keytool -delete -alias assertion-key -v -keystore oamkeystore_new-storepass <pswd> -storetype JCEKS
  3. keytool -list -v -keystore oamkeystore_new -storetype JCEKS -storepass <pswd>
  4. keytool -importcert -file aaa_chain.pem -trustcacerts -storepass <pswd> -keystore oamkeystore_new -storetype JCEKS -alias assertion-cert
  5. keytool -list -v -keystore oamkeystore_new -storetype JCEKS -storepass <pswd>
  6. <JDK>/bin/java -cp importcert.jaroracle.security.am.common.tools.import certs.CertificateImport -keystoreoamkeystore_new -privatekeyfile aaa_key.der -signedcertfile aaa_cert.der -alias assertion-key -storetype JCEKS
  7. keytool -list -v -keystore oamkeystore_new -storetype JCEKS -storepass <pswd>
  8. oamkeystore_newを次の場所にコピーします

    <DOMAIN_HOME>/config/fmwconfig/.oamkeystore cp oamkeystore_new <DOMAIN_HOME>/config/fmwconfig/.oamkeystore

  9. keytool -list -v -keystore <DOMAIN_HOME>/config/fmwconfig/.oamkeystore -storetype JCEKS -storepass <pswd>
  10. アーティファクトを保存するWLSTコマンド:
    saveAccessArtifacts(domainHome="<mw>/domains/oam_domain", propsFile="<path>/dbprop.properties")

    ノート:

    <path>/dbprop.propertiesの内容:

    oam.entityStore.schemaUser=OAM_Schema_userName

    oam.entityStore.schemaPassword=<pswd>

    oam.entityStore.ConnectString=jdbc:oracle:thin:@dbhost:dbport/ServiceID

署名証明書を更新したら、更新された証明書を使用してOAM_IDENTITY_ASSERTIONヘッダー値を検証するようにクライアントを更新する必要があります。Weblogic OAMアイデンティティ・アサータ(OAMIdentityAsserter)を使用している場合は、構成内の検証証明書を置換する必要があります。

詳細は、「Oracle ADFアプリケーションとAccess Manager SSOの統合」を参照してください。

42.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トークンが含まれていることを確認します。