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

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

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

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

55.5.1 Oracle Fusion Middlewareの構成

保護対象にするアプリケーションは、Oracle Platform Security Services (OPSS)のPS5用Opatchを適用したOracle Fusion Middleware 11.1.1パッチ・セット5 (PS5)またはOracle Fusion Middleware PS6以降で作成したWebLogic Serverドメインにデプロイする必要があります。

アプリケーションが実行されているWebLogic Serverドメインは、Access Manager Identity Asserterコンポーネントによって保護されている必要があり、そのコンポーネントによって、Access Managerから受け取ったIDアサーションが検証され、アイデンティティ・コンテキスト・ランタイムの作成プロセスが開始されます。Access Manager Identity Asserterは、トークン・タイプOAM_IDENTITY_ASSERTIONを検出するように構成する必要があります。また、アイデンティティ・コンテキスト・ランタイムと直接連動する保護されているアプリケーションは、OPSS属性サービスと連動するためのソース・コード権限を付与されている必要があります。

55.5.2 Access Managerの構成

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

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

55.5.2.1 IDアサーション

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

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

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

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

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

55.5.3 Oracle Adaptive Access Managerの構成

Oracle Access ManagerとOracle Adaptive Access Manager (OAAM)との間の統合の一部として、OAAMはリスクベースのアイデンティティ・コンテキスト属性を公開および伝播します。

この場合、OAAM属性は、ユーザー認証フロー(OAAM側)の終わりにDAPトークンでOAMに渡されます。DAPトークンは、表55-1のoracle:idm:claims:riskネームスペースによって定義される属性を搬送します。その後、OAMによってこれらの属性が$session.risk.attrネームスペースにプッシュされます。次の項では、OAAMとOAMの構成について説明します。

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

Oracle Adaptive Access Managerをインストールおよび設定できます。

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

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

スナップショットをインポートすることで、OAAMをセットアップします。
詳細は、を参照してください。
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を再起動します。

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

OAAMとの統合のためにAccess Managerを構成できます。

OAAM認証スキームを使用したユーザーの認証を強制するTAPSchemeを使用して、次のステップを実行します。

ノート:

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

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

認証にTAPSchemeを使用して(表22-21)、リソースを保護します(「特定のリソースに対する認証ポリシーの定義」)。
次のチャレンジ・パラメータをTAPSchemeに追加します(表22-22)。
```
TAPOverrideResource=http://IAMSuiteAgent:80/oamTAPAuthenticate
```

55.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から構築されたフィンガープリント・データが使用されます。様々なフィンガープリントについてテストするには、様々なデバイスを試してみます。

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

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

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

55.5.6 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を構成するには

OAMとOESSOの統合の詳細は、Logon Managerクライアント側ソフトウェアのインストールに関する項を参照してください。
補足的な詳細は、Logon ManagerでのOracle Access Managementのサポートに関する項を参照してください。

55.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サーバーを構成する必要があります(図55-4を参照)。

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

「図55-4 OAM認証プロバイダの構成」の説明

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

Mobile and Socialサービスが有効になっていることを確認します(「「共通構成」セクションの使用可能なサービス」を参照)。
MobileOAMAuthenticationの「サービス・プロバイダ」ページで、IDContextEnabled属性を追加して、その値にtrueを設定します。