Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
アイデンティティ・コンテキストにより、組織は、Oracle Access Managementプラットフォームに組み込まれているコンテキストを意識したポリシー管理および認可機能を活用することで、増大するセキュリティの脅威に対応できます。アイデンティティ・コンテキストでは、従来のセキュリティ制御(ロールやグループなど)とともに、認証および認可中に確立される動的データ(認証強度、リスク・レベル、デバイス・トラストなど)を使用することで、リソースへのアクセスのセキュリティが確保されます。次の項では、アイデンティティ・コンテキストの詳細とその使用方法について説明します。
エンタープライズ・アプリケーション・インフラストラクチャがサポートするビジネス・アプリケーションをWeb対応にするために、それらのインフラストラクチャには過去10年間にわたって変更が行われてきました。これらの変更によって、様々なタイプのデバイスを使用した、より多くのユーザーによるアクセスが可能になっています。ユーザー数の増加に伴う追加のリスクに対応するために、アクセス管理に使用される基盤となるセキュリティ・モデルは、サイロベースの実装から、より動的なものへと進化し、アイデンティティおよびリスク・データがアプリケーション配信プロセス全体のコンポーネントにわたって共有されるようになりました。この動的な実装は、Webシングル・サインオン(SSO)、きめ細かな認可、Web Services Security、Identity Federationなどを提供することでセキュリティ制御を特定のランタイム・デプロイメント環境(Webサーバーまたはアプリケーション・サーバー・コンテナ)内に集約し、ポリシーベースのセキュリティ制御を提供することでアプリケーション・リソースへのアクセスを管理するシステムに依存します。さらに、アイデンティティおよびリスク・データによって、アクセスを要求しているユーザーのコンテキストが提供されます。
アプリケーション・セキュリティ制御は、最初は、特定のエンタープライズ・アプリケーション・デプロイメント・パラダイム(たとえば、すべてのWebサーバー・アプリケーション、すべてのWebサービス・アプリケーション、またはすべてのアプリケーション・サーバー・アプリケーション)内のサイロの統合に焦点が当てられていましたが、今日では内外のセキュリティの脅威のプレゼンスの増加により、増大するリスクを適切に管理するために異なるセキュリティ・モデルの統合が必要とされています。
この要件は、クラウドおよびモバイル・コンピューティング・パラダイムの出現によりさらに拡大されました。そこでは、アプリケーションは、もはやセキュアなエンタープライズの保護された範囲内で整然と実行されるコンポーネントで構成されているものではなくなりました。
アプリケーションがクラウド・サービスを活用するには、独自の方法でサイロ化されているそれらのサービスから生じるリスクの増大を解決する必要がありました。クラウド・デプロイメントおよびモバイル配信チャネルに対する脅威の数は着実に増加しており、エンドツーエンド・アプリケーション配信プロセスに、広範な脅威への対処に不可欠なポリシー制御を実装することが必要となっています。これらのポリシー制御では、どのセキュリティの決定を行う必要があるのかを踏まえて、要求側のユーザーに関する情報にアクセスすることが必要です。したがって、セキュリティ・ポリシー管理インフラストラクチャはコンテキストを意識したものにして、管理者が、保護されているアプリケーション環境へのアクセスを要求するユーザーに対して適用するセキュリティのレベルを制御するポリシーを作成できるようにする必要があります。
以前は、アイデンティティ・コンテキストは、1つ以上のアイデンティティ・ストア(LDAPディレクトリやSQLデータベースなど)のアイデンティティ・レコードのプレゼンスによって定義されていました。アイデンティティ・レコードには、プロファイル属性、そのユーザーがメンバーになっているグループ、およびエンタープライズ・ロールが含まれます。しかし、Web、クラウド、およびモバイル・アプリケーションの配信チャネルの範囲は絶え間なく拡大しているため、アイデンティティに関してさらに動的な情報を意識した認可ポリシー制御が必要です。この情報は、保護されているリソースへのアクセスを試みるアイデンティティと関連付けられており、次の一部またはすべてを含む場合があります。
プレゼンス(場所、履歴パターン)
認証強度(弱、強)
アシュアランスのレベル(NISTレベル、X509証明書)
リスク評価(パターン分析)
フェデレーション(パターン属性)
デバイス特性(フィンガープリント、デバイスのヘルス、デバイスの保護、トラステッド・データ)
トラステッド・パートナからのアサーション(SAMLトークンなど)
シングル・サインオン・セッション(セッション・タイムアウト)
次の例は、アイデンティティ・コンテキスト・データがアプリケーションによってどのように使用される可能性があるのかを示しています。アプリケーションは、次のように動作する場合があります。
ユーザーがスマート・カードなど強力な資格証明を使用して認証されていない場合、特定のビジネス機能を無効化します。
組織が(Identity Federationを介して)取引しているビジネス・パートナによって提供されたアイデンティティ・データに基づいてトランザクションへのアクセスのセキュリティを確保します。
不正行為で知られる場所からアクセスされていることが検出された場合、追加の認証資格証明を要求します。
管理者の(サードパーティで管理されている)業界認定証が有効期限切れになっている場合、管理権限の範囲を制限します。
不明なデバイスからアクセスされていることが検出された場合、特定のビジネス機能を無効化します。
アイデンティティ・コンテキストの概念をアクセス管理に組み込むことで、制御は、アイデンティティ・プロファイルに含まれているとは限らない動的データ(アイデンティティ・コンテキスト属性と呼ばれる)を使用して決定できるようになりました。つまり、アイデンティティ・コンテキストは、特定の保護されているリソースにアクセスするユーザーの要求を取り巻く環境および状況と考えられます。それは、アクティビティの範囲、地理的な領域、通信プラットフォーム、アプリケーション、あるいは論理または物理ドメインである場合があります。
このリリースでは、Access Managerは、Oracle Access Managementプラットフォームの組込みサービスとしてアイデンティティ・コンテキストを組み込むことで、コンテキストを意識したアクセス管理を可能にします。図48-1は、複数のシステム・コンポーネントによって実装されているアイデンティティ・コンテキスト・プロセスのフローを示しています。各アプリケーション配信コンポーネントには、アプリケーションのその個別のスライスの保護を担うそれ自体のセキュリティ・ポリシー・インフラストラクチャがあります。この特定のユース・ケースには、エンド・ユーザー・デバイス、静的GUIページを実行するWebサーバー、動的コンテンツをレンダリングするポータル・サーバーを実行するアプリケーション・サーバー、Webサービス・エンドポイントを公開するサービス・バス・サーバー、トランザクション・データを格納するデータベース・サーバー、およびアイデンティティ・プロファイル・データを格納するLDAPサーバーが含まれています。
プロセスの各コンポーネントには、保護されているリソースへのアクセスを制御する認可ポリシーが管理者によって定義され、実行時に適用されるそれ自体のセキュリティ・インフラストラクチャがあります。さらに、それらのコンポーネントのいくつかまたはすべてで、ポリシー管理をOracle Entitlements Serverなどの外部認可サーバーに外在させる場合もあります。アプリケーションがOracle Platform Security Servicesを活用して構築されている場合がこれに該当します。図48-2は、構成しているOracleアプリケーションに基づいたアイデンティティ・コンテキストの機能アーキテクチャを示しています。
図から明らかなように、コンテキストを意識したセキュリティ・ポリシー管理は、Oracle Access Managementプラットフォームを活用することで実現されます。このプラットフォームには、エンドユーザーのアプリケーションを変更することなくアイデンティティ・コンテキスト属性(リスク・スコア、トラステッド・デバイス・データ、認証データなど)を操作および適用するためのネイティブ・サポートが含まれています。
Oracle Access Managementプラットフォームにより、アイデンティティ・コンテキスト・データを収集し、関与するコンポーネントに伝播し(図48-2に定義)、保護されているリソースへのアクセス権限を付与または拒否するために使用可能にできます。アイデンティティ・コンテキスト・サービスにより、アイデンティティ・コンテキストAPIを介したアイデンティティ・コンテキスト・ランタイムへのアクセスが可能になります。アイデンティティ・コンテキスト・ディクショナリ・スキーマによって、アイデンティティ・コンテキスト属性が指定されます。次の項では、これらのコンポーネントについて詳しく説明します。
アイデンティティ・コンテキスト・アーキテクチャの中心となるのは、アイデンティティ・コンテキスト・ディクショナリです。このディクショナリは、Oracle Access Managementプラットフォームで定義されているアイデンティティ・コンテキスト属性を指定することでアイデンティティ・コンテキスト・スキーマを定義します。そのスキーマでは、namespace : attributeと等しい一意の名前で各属性が記述されます。表48-1は、それらのスキーマ属性を示しています。
注意: 仮想属性(表48-1に記載)は、特定の属性の作成元となるアイデンティティ情報の抽象クラスを表します。仮想属性を公開する場合、アイデンティティ・コンテキストAPIは、属性値にattr-name=attr-valueが含まれていることを想定します。実際の属性は、名前namespace : attribute : attr-nameとattr-valueの値を使用して作成されます。この方法により、Oracle Access Managementコンポーネントによって直接管理されていないソースからの値を持つ属性の公開が可能になります。 |
表48-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の値で作成されます。) |
アイデンティティ・コンテキスト・ランタイムは、アイデンティティ・コンテキスト属性(アイデンティティ・コンテキスト・ディクショナリで定義される)のコレクションを参照します。それは、その属性に対して権限を持つと認識されている様々なトラステッド・アプリケーション・コンポーネントまたはセキュリティ・フレームワーク、あるいその両方によってアサートされます。これが、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アサーションを活用することで構成されます。表48-1「アイデンティティ・コンテキスト・スキーマ属性」は、これらのデフォルト属性を示しています。次のリストは、アイデンティティ・コンテキスト・ランタイムのエンドツーエンドのフローの詳細を示しています。そのリストの下の図48-3は、フローを示しています。
プロセスの概要: アイデンティティ・コンテキスト・ランタイムのエンドツーエンドのフロー
ユーザーが、保護されているアプリケーションにデバイスからアクセスします。
Access Managerによって、アイデンティティがアサートされ、コンポーネントを公開する関連Access Managementからアイデンティティ属性が収集され、アイデンティティ・コンテキストが作成されます。
Access Managerによって、IDアサーション(SAMLセッション・トークン)が生成され、アイデンティティ・コンテキスト属性が組み込まれます。Access Manager Identity Asserterによって、IDアサーションが処理され、OPSS属性サービスを使用してWebLogic Serverコンテナにアイデンティティ・コンテキストが公開されます。
保護されているアプリケーションによってOES PEP APIが呼び出され、認可の決定が行われます。OESによってアイデンティティ・コンテキストがローカルOES PDPに自動的に伝播されます。
OESによって、適切な認可ポリシーが検索され、その条件が(アイデンティティ・コンテキスト属性に基づいて)評価されます。評価は、組込みのアイデンティティ・コンテキスト関数またはカスタム関数を使用して実行できます。
保護されているアプリケーションによって、JRF Webサービス呼出しが行われ、その中でOracle Web Service Manager (OWSM)クライアントによってSAMLトークンが使用され、アイデンティティ・コンテキストがWebサービス・アプリケーション環境に伝播されます。
OWSM (Webサービス側)によってそのアイデンティティ・コンテキストでSAMLアサーションが処理され、OPSS属性サービスを使用することによってそのアイデンティティ・コンテキストがWebLogic Serverコンテナに公開されます。
Webサービス・アプリケーションによってOES PEP APIが呼び出され、認可の決定が行われます。
OESによってアイデンティティ・コンテキストがリモートOES PDPに自動的に伝播され、そこでアイデンティティ・コンテキスト属性に基づいた条件が、組込みのアイデンティティ・コンテキスト関数またはカスタム関数を使用して評価されます。
CMEによって、アイデンティティ・コンテキストがアプリケーション層および基盤となるアプリケーション・サーバー・コンテナに伝播されると、そのアイデンティティ・コンテキストはコンテナおよびその中で実行されているアプリケーションから使用できるようになります。表48-2は、アイデンティティ・コンテキストを使用して動作する場合に、どのアクセス管理プラットフォーム製品によって何が実行されるのかを示しています。
表48-2 アイデンティティ・コンテキスト操作のマッピング
ロールおよびコンテキスト操作 | 説明 | コンポーネント |
---|---|---|
パブリッシャ - アイデンティティ・コンテキストの公開 |
アプリケーション・コンポーネントを保護するトラステッド・セキュリティ・フレームワークは、アイデンティティまたはアイデンティティのアクセス要求、あるいはその両方に関する適切なファクトを、別のトラステッド・セキュリティ・フレームワークから取得するか、それが使用できる情報から導出します。 権限を持つコンポーネントによって収集される情報は、コンポーネントのランタイム・フレームワークで使用できる環境コンテキストに基づいています。たとえば、Access Managerによって、ユーザーの認証強度のレベルが判別され、OAAMによって特定のオンライン・セッションに関連付けられているリスク・スコアが計算され、OESSOによってクライアント・デバイスでファイアウォールが有効化されているかどうかが判別されます。 |
|
プロパゲータ - アイデンティティ・コンテキストを伝播する |
トラステッド・セキュリティ・フレームワークによってアイデンティティ・コンテキスト属性が伝播され、別のアプリケーション・セキュリティ・フレームワークによって使用されるかアプリケーションによって直接使用されます。たとえば、OAAMによって、ユーザーのリスク・スコアがそのユーザーのAccess Managerセッションに伝播され、Access Managerによって、認証済ユーザーの一意のIDおよび認証レベルとともにIDアサーション(SAMLトークン)が伝播され、OWSMクライアントによって現在のアイデンティティ・コンテキストが、Webサービスに伝播され、そこで、OWSMエージェントによってWebサービス・アプリケーションでアイデンティティ・コンテキストが再構築されます。 |
|
評価者 - アイデンティティ・コンテキストを評価する |
アイデンティティ・コンテキスト属性を使用するトラステッド・セキュリティ・フレームワークまたはエンドユーザー・アプリケーションです。ポリシー決定を実行するか、アプリケーションのビジネス・ロジックをパーソナライズします。たとえば、OAAMが存在し、リスク・スコアを計算するように構成されている場合、OES内のアプリケーションの認可ポリシーによって、そのリスク・スコアが特定のしきい値未満のときにのみアクセスが許可されます。また、Access ManagerでIdentity Federationが構成されている場合、そのアプリケーションによって、パートナが提供するアサーション(アイデンティティ・コンテキストで入手可能)が使用され、OESを使用してトランザクションへのアクセスが認可されます。 |
|
アイデンティティ・コンテキストAPIは、アイデンティティ・コンテキスト・ディクショナリおよびアイデンティティ・コンテキスト・ランタイムと連動するように設計されたJavaクラスのセットです。このAPIは、Oracle Java Required Files (JRF)の一部であるIdentityContext.jar
として配布されます。例48-1は、アイデンティティ・コンテキスト・ディクショナリと連動するアプリケーションを示しています。
例48-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属性サービスに要求することでアイデンティティ・コンテキスト・ランタイムにアクセスできます。例48-2は、WLSTを使用してOPSS属性サービスにアプリケーション(この場合はssofilter.jar
)へのアクセス権を付与する方法を示しています。
例48-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()
例48-3は、アイデンティティ・コンテキスト・ランタイムと連動するアプリケーションを示しています。
例48-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リファレンスに記載されています。
アイデンティティ・コンテキストのサポートは、表48-2「アイデンティティ・コンテキスト操作のマッピング」にリストされている各関係Oracle Access Managementコンポーネントに事前に統合されています。このため、ビジネス要件に対応するように各コンポーネントを構成する必要があります。
次の項では、必要なアイデンティティ・コンテキスト構成の高度な概要を示します。ただし、詳細は、それぞれの製品に付属のドキュメントを参照してください。
保護対象にするアプリケーションは、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属性サービスと連動するためのソース・コード・グラントを(例48-2のように)付与されている必要があります。
関連項目: Access Manager Identity Asserterおよびソース・コード・グラントの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。 |
OAMは、アイデンティティ・コンテキストの主なパブリッシャおよびプロパゲータとして、関係コンポーネントからアイデンティティ・コンテキスト・データを収集するための中心的な構成ポイントとして機能します。次の項では、アイデンティティ・コンテキスト管理の背後にあるアーキテクチャの主要な要素について説明します。
Web層とアプリケーション層の間にエンドツーエンド・セキュリティを適切に施行するために、Access Manager認可ポリシーにアサートされた属性を定義することをお薦めします。
IDアサーション(SAMLセッション・トークン)は、Webリソースを保護するWebゲートとアプリケーション・サーバー・コンテナとの間の信頼の確保に加えて、SAML属性としてアイデンティティ・コンテキスト・データを公開するためにも使用されます。
IDアサーションは、有効化されている必要があり、アイデンティティ・コンテキスト内に特定の属性を想定しているビジネス・ロジックの必要に応じてアサートされた属性が移入されている必要があります。それは、OAMポリシー・レスポンス・タブ内で構成され、認証と認可の両方のポリシーに対して定義できます。
リソースを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が含まれていると想定します)。
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
が作成されます。
アイデンティティ・ストア属性は、アサートされた属性として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
が作成されます。
Oracle Access ManagerとOracle Adaptive Access Manager (OAAM)との間の統合の一部として、OAAMはリスクベースのアイデンティティ・コンテキスト属性を公開および伝播します。この場合、OAAM属性は、ユーザー認証フロー(OAAM側)の終わりにDAPトークンでOAMに渡されます。DAPトークンは、表48-1「アイデンティティ・コンテキスト・スキーマ属性」のoracle:idm:claims:riskネームスペースによって定義される属性を運搬します。その後、OAMによってこれらの属性が$session.risk.attrネームスペースにプッシュされます。次の項では、OAAMとOAMの構成について説明します。
この項では、OAAMのインストールおよびセットアップについて説明します。
Oracle Adaptive Access Managerをセットアップするには
スナップショットをインポートすることで、OAAMをセットアップします。
詳細は、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドを参照してください。
『Oracle Fusion Middleware Oracle Access Manager統合ガイド』に記載されているようにOAAMとAccess Managerを統合します。
TAPトークンのバージョンは、v2.0ではなくv2.1であることが必要です。
次のプロパティがtrueに設定されていることを確認します。
oracle.oaam.idcontext.enabled
は、デフォルトでtrueになっています。この値を変更するには、OAAM管理コンソールを使用します。
bharosa.uio.default.registerdevice.enabled
は、safeforuser要求が適切に処理されるためにはtrueであることが必要です。
OAAM管理コンソールから、「プロパティ」、「新規プロパティの作成」に移動します。
v2.1
に等しい値を持つプロパティ名oaam.uio.oam.dap_token.version
を入力します。
oaam_server_server1を再起動します。
次の手順を実行します。TAPSchemeを使用すると、強制的に、ユーザーがOAAM認証スキームを使用して認証されるようになります。
注意: OAAM AdvancedまたはOAAM Basicを使用しないでください。 |
OAAMと統合するようにAccess Managerを構成するには
認証にTAPSchemeを使用して(表19-21)、リソースを保護します(「特定のリソースに対する認証ポリシーの定義」)。
次のチャレンジ・パラメータをTAPSchemeに追加します(表19-22)。
TAPOverrideResource=http://IAMSuiteAgent:80/oamTAPAuthenticate
次の情報は、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から構築されたフィンガープリント・データが使用されます。様々なフィンガープリントについてテストするには、様々なデバイスを試してみます。
次のように実行して、Oracle Web Service Security Manager (OWSSM)がアイデンティティ・コンテキストを伝播できるようにします。
アイデンティティ・コンテキストに対応するようにWeb Service Security Managerを構成するには
アイデンティティ・コンテキストをサポートしているOWSSMセキュリティ・ポリシーを変更してtrueの値を持つpropagate.identity.context
要素を含めることで、セキュリティ・ポリシーを構成します。
注意: propagate.identity.context(デフォルトではfalse)は、SAML関連ポリシーの構成オーバーライド・プロパティです。それをグローバルに有効化するには、そのプロパティをtrueに設定してグローバル・ポリシーを構成します。 |
SAMLアサーションとメッセージに署名するように、キーストアと証明書ストアを構成します。更新したキーストアと証明書ストアを、$DOMAIN_HOME
/config/fmwconfig/
ディレクトリにコピーします。
Oracle Entitlements Server (OES)とのランタイムの統合は完全に自動化されています。アプリケーションによってPEP APIが起動され、認可コールが行われると、PEP APIによってアイデンティティ・コンテキスト・ランタイム全体が、条件(アイデンティティ・コンテキストを定義するポリシー・オブジェクト)が評価されるOES PDPに自動的に伝播されます。
注意: 認可コールを行うときは、newPepRequest() メソッドに渡される最後の引数が、nullではなく、少なくともこの例で示すように空のhashmapであることを確認します。
PepRequestFactory requestFactory =
PepRequestFactoryImpl.getPepRequestFactory();
PepRequest request = requestFactory.newPepRequest (subject,
action, resource, |
条件は、セキュリティ管理者がOES管理コンソールを使用して、アイデンティティ・コンテキスト・スキーマに基づいて作成します。次の組込み関数を使用して、アイデンティティ・コンテキスト属性を使用する条件を指定します。
ASSERT_IDENTITY_CONTEXT
GET_STRING_IDENTITY_CONTEXT
GET_INTEGER_IDENTITY_CONTEXT
GET_BOOLEAN_IDENTITY_CONTEXT
カスタムOES関数は、既知のリクエスト属性として完全なアイデンティティ・コンテキスト・ランタイム情報を受け取ります。このデータ構造は、アイデンティティ・コンテキストAPIを使用してアイデンティティ・コンテキスト・ランタイムに変換できます。例48-4は、受け取ったパラメータからコンテキストを作成するカスタムOES関数を示しています。
例48-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 … }
アイデンティティ・コンテキスト・サービスの一部として、Oracle Enterprise Single Sign-on (OESSO)は、クライアントベースのアイデンティティ・コンテキスト属性を公開および伝播できます。完全な統合が構成されると、クライアント固有のアイデンティティ・コンテキスト属性(第48.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資格証明とともに、ペイロード内のクライアント・コンテキスト情報が提供されます。
注意: このペイロードは次のものによって保護されます。
|
アイデンティティ・コンテキストの属性を取得するようにOESSOを構成するには
OAMとOESSOの統合の詳細は、Oracle Enterprise Single Sign-On Suite Plusインストレーション・ガイドのログオン・マネージャ・クライアントサイド・ソフトウェアのインストールに関する項を参照してください。
補足的な詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドのログオン・マネージャでのOracle Access Managementのサポートに関する項を参照してください。
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サーバーを構成する必要があります(図48-4を参照)。
アイデンティティ・コンテキストの属性を取得するようにMobile and Socialを構成するには
Mobile and Socialサービスが有効化されていることを確認します(「使用可能なサービスの有効化および無効化」を参照)。
MobileOAMAuthentication
の「サービス・プロバイダ」ページで、IDContextEnabled
属性を追加して、その値にtrue
を設定します。
関連項目:
|
Access Managerを使用してアイデンティティ・コンテキストの適切な操作を確保する手順は、次のとおりです。
アイデンティティ・コンテキストの操作を検証するには
次のように実行して、Access Managerによって構築されるIDアサーション・レスポンスを検証します。
/testidc
リソースをWebゲート・エージェントで保護し、認可レスポンスの一部として目的のアサートされた属性を持つIDアサーションを返すようにAccess Managerを構成します。
OAMテスターを使用して、/testidcに対する認可リクエストへのレスポンスでOAM_IDENTITY_ASSERTION属性としてIDアサーションが返されていることを検証します。
次のように実行して、WebゲートによってIDアサーションを含むHTTPヘッダーが作成されていることを検証します。
/cgi-bin/printenv.pl
スクリプトが、/testidcリソースを保護しているものと同じポリシーによって保護されていることを確認します。
注意: printenv.pl は、OHSの一部として出荷されており、実行する権限を持っている必要があります。かわりに、ヘッダー情報を表示する任意のスクリプトを使用できます。 |
printenv.pl
にアクセスし、ログインを起動し、HTTPヘッダーを表示します。
HTTP_OAM_IDENTITY_ASSERTIONヘッダーに、アサートされた属性を持つSAMLトークンが含まれていることを確認します。