ここでは、Oracle Identity Federationのサーバー構成と管理に関するその他のトピックについて説明します。内容は次のとおりです。
使用中のバックエンドとフローが初期化される場所に応じて、フェデレーテッド・シングル・サインオン(SSO)処理の実行にはいくつかの方法があります。表7-1に、可能な組合せを示します。
表7-1 フェデレーテッド・シングル・サインオンの組合せ
組合せ | フロー |
---|---|
OracleAS Single Sign-OnとLiberty 1.x/SAML 2.0 |
ユーザーが |
Oracle Access ManagerとLiberty 1.x/SAML 2.0 |
ユーザーがwebgateによって保護されたリソースにアクセスすると、SAML2.0/Liberty 1.xシングル・サインオンがトリガーされ、Oracle Identity FederationはSPとして動作します。 |
Oracle Access ManagerとSAML 1.x/WS-Federation |
ユーザーがwebgateによって保護されたリソースにアクセスすると、SAML 1.x/WS-Federationシングル・サインオンがトリガーされ、Oracle Identity FederationはSPとして動作します。 |
eTrust SiteMinderとSAML 2.0/Liberty 1.x |
ユーザーがeTrust SiteMinder Agentによって保護されたリソースにアクセスすると、SAML2.0/Liberty 1.xシングル・サインオンがトリガーされ、Oracle Identity FederationはSPとして動作します。 |
eTrust SiteMinderとSAML 1.x/WS-Federation |
ユーザーがeTrust SiteMinder Agentによって保護されたリソースにアクセスすると、SAML 1.x/WS-Federationシングル・サインオンがトリガーされ、Oracle Identity FederationはSPとして動作します。 |
SPが開始するシングル・サインオンとSAML2.0/Liberty 1.x |
ユーザーが直接Oracle Identity Federation URLにアクセスすることでLiberty 1.x/SAML 2.0シングル・サインオンを開始し、Oracle Identity FederationはSPとして動作します。 |
SPが開始するシングル・サインオンとSAML 1.x |
ユーザーが直接Oracle Identity Federation URLにアクセスすることでSAML 1.xシングル・サインオンを開始し、Oracle Identity FederationはSPとして動作します。 |
SPが開始するシングル・サインオンとWS-Federation |
ユーザーが直接Oracle Identity Federation URLにアクセスすることでWS-Federationシングル・サインオンを開始し、Oracle Identity FederationはSPとして動作します。 |
IdPが開始するシングル・サインオンとSAML2.0/Liberty 1.x |
ユーザーが直接Oracle Identity Federation URLにアクセスすることでSAML 2.0/Liberty 1.xシングル・サインオンを開始し、Oracle Identity FederationはIdPとして動作します。 |
IdPが開始するシングル・サインオンとSAML 1.x |
ユーザーが直接Oracle Identity Federation URLにアクセスすることでSAML 1.xシングル・サインオンを開始し、Oracle Identity FederationはIdPとして動作します。 |
IdPが開始するシングル・サインオンとWS-Federation |
ユーザーが直接Oracle Identity Federation URLにアクセスすることでWS-Federationシングル・サインオンを開始し、Oracle Identity FederationはIdPとして動作します。 |
この項では、様々な組合せの構成方法を説明します。
OracleAS Single Sign-Onは、mod_osso
によって保護されたリソースをリクエストする場合に、Liberty 1.xまたはSAML 2.0でのSSO処理をトリガーするように構成できます。
注意: この機能はSAML 1.xおよびWS-Federationプロトコルではサポートされません。 |
そうするには、OracleAS Single Sign-Onパートナ・アプリケーションが定義され、mod_osso
によって守られる必要があります。また、パートナ・アプリケーションがSASSO認証プラグインに関連付けられたSSOセキュリティ・レベルを使用するように構成される必要があります。それには、Oracle SSOデプロイメントのORACLE_HOME/sso/conf/policy.properties
ファイルを編集し、パートナ・アプリケーション(ホスト名とポートで定義)を、SASSOAuthLevel
と同一のセキュリティ・レベルに設定します。
例:
MediumHighSecurity_AuthPlugin = oracle.security.sso.server.auth.SASSOAuth MediumSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOServerAuth ... www.app.com\:7890 = MediumHighSecurity ... SASSOAuthnUrl = http\://oif_host\:oif_port/sso/authn SASSOLogoutUrl = http\://oif_host\:oif_port/sso/jsp/sasso_logout_success.jsp SASSOAuthLevel = MediumHighSecurity
ファイルを保存し、OC4J_SECURITY
を再起動して変更を適用します。
次にユーザーが保護されたリソースへの未認証アクセスを試みると、そのユーザーはOracle Identity Federationにリダイレクトされ、そこでLiberty 1.x/SAML 2.0 SSO処理が行われます。
保護されたリソースをリクエストする場合、Oracle Identity FederationがSSO処理を実行するために使用するURL問合せパラメータを指定できます。パラメータは次のとおりです。
providerid
: SSO処理を実行するために使用するLiberty 1.xまたはSAML 2.0 IdPの識別子です(オプション)。これがない場合、Oracle Identity Federation管理コンソールの「サービス・プロバイダ」→「グローバル設定」→「デフォルトSSOアイデンティティ・プロバイダ」で構成されたデフォルトのSSOプロバイダが使用されます。
federationid
: SSOで使用するアフィリエーションの識別子です(オプション)。そうしたURLの例を次に示します。
http://protected_app:port/path?providerid=http://idp.com
詳細は「アフィリエーション関連の作業」を参照してください。
注意: URL問合せパラメータ値が正しくエンコードされていることを確認します。 |
OracleAS Single Sign-Onの構成の詳細は、Oracle SSOのマニュアルを参照してください。
Oracle Access Manager WebGateエージェントによって保護されているリソースをユーザーがリクエストした場合にLiberty 1.x/SAML 2.0 SSOが開始されるようにOracle Accessポリシーを構成できます。
それには、Oracle Access Policy Managerを使用して、ポリシー・ドメイン、またはリソースを保護するポリシーを構成します。ポリシー・ドメインまたはポリシー用に認証ルールを作成する場合は、Fed SSO – SAML 2.0/Liberty 1.x認証スキームを選択します。Oracle Accessを使用するように構成する場合、Oracle Identity Federationは自動的にこの認証スキームを作成します。リソースがアクセスされるとスキームによりLiberty 1.xまたはSAML 2.0シングル・サインオンが開始され、結果としてフェデレーテッド・ユーザーに関連付けられたローカル・ユーザーのためのセッションが作成されます。ポリシー・ドメインまたはポリシーのための認可ルールと式を設定して、結果的に作成されたローカル・ユーザーにアクセスを割り当てます。
保護されたリソースをリクエストする場合、Oracle Identity FederationがSSO処理を実行するために使用するURL問合せパラメータを指定できます。パラメータは次のとおりです。
providerid
: SSO処理を実行するために使用するLiberty 1.xまたはSAML 2.0 IdPの識別子です(オプション)。これがない場合、Oracle Identity Federation管理コンソールの「サービス・プロバイダ」→「グローバル設定」→「デフォルトSSOアイデンティティ・プロバイダ」で構成されたデフォルトのSSOプロバイダが使用されます。
federationid
: SSOで使用するアフィリエーションの識別子です(オプション)。そうしたURLの例を次に示します。
http://protected_app:port/path?providerid=http://idp.com
詳細は「アフィリエーション関連の作業」を参照してください。
注意: URL問合せパラメータ値が正しくエンコードされていることを確認します。 |
構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
Oracle Access Manager WebGateエージェントによって保護されているリソースをユーザーがリクエストした場合にSAML 1.xまたはWS-Federation SSOが開始されるようにOracle Access Managerポリシーを構成できます。
それには、Oracle Access Policy Managerを使用して、ポリシー・ドメイン、またはリソースを保護するポリシーを構成します。ポリシー・ドメインまたはポリシー用に認証ルールを作成する場合は、Fed SSO – SAML 1.xまたはFed SSO – WS-Federation認証スキームを選択します。Oracle Accessを使用するように構成する場合、Oracle Identity Federationは自動的にこれらの認証スキームを作成します。リソースがアクセスされると、このスキームはSAML 1.xまたはWS-Federationを使用してフェデレーテッドSSOを開始し、結果としてフェデレーテッド・ユーザーに関連付けられたローカル・ユーザーのためのセッションが作成されます。ポリシー・ドメインまたはポリシーのための認可ルールと式を設定して、結果的に作成されたローカル・ユーザーにアクセスを割り当てます。
内容は次のとおりです。
FedSSO–SAML 1.x認証スキームを使用している場合、Oracle Identity Federationは、SSOで使用するIdPを示すHTTPリクエスト中で、ObSAMLDomain
という名前のCookieを見つけようとします。Oracle Identity Federationは、SAML 1.x SSOの最後で、この永続CookieをIdPの構成済ドメインの名前に自動的に設定します。したがって、この機能が動作するためには、少なくとも1回、ユーザーによるSAML 1.x SSOの実行が成功する必要があります。Oracle Identity FederationがObSAMLDomain
Cookieを検索しない場合は、ユーザーはローカルで、ローカルのAccess Managerログインを実行すると想定されています。
注意: この機能はOracle COREid FederationではSmartMarksと呼ばれていましたが、現在、リリース10.1.4.2では、SPが開始するIdP検出と呼ばれています。 |
SAML 1.x認証スキームが機能するには、SP側に多少のOracle Identity Federation追加構成が必要です。IdP用のSAML 1.xまたはWS-Federationドメインの構成で、SPが開始するIdP検出が有効にされ、転送URLと転送問合せ文字列フィールドが構成されている必要があります。転送URLはIdPでSAML 1.x SSOを開始するために使用されるURLであり、転送問合せ文字列は、SSOがSPに戻されるためのパラメータを提供します。
注意: このURLと問合せ文字列はSAML 1.x仕様で指定されていないため、IdPが使用するSAML実装により異なます。Oracle Identity FederationがSSOを処理する場合、IdPへのリダイレクションで使用するために、転送URL、送信問合せ文字列、およびリクエストされたリソース(ターゲット)のURLが連結されます。これには、ターゲットURLパラメータが転送問合せ文字列の最後のパラメータである必要があります。次のOracle Identity Federationの例を参照してください。 |
IdPが別にインストールされたOracle Identity Federationである場合、転送URLと転送問合せ文字列はOracle Identity Federationの規則に従って部分的に設定されます。転送問合せ文字列の末尾は、そのSPに対するIdP構成に固有の情報(IdPで構成されたSPドメイン名と、使用されるSSO方式)である必要があります。
例
どちらもOracle Identity Federationを使用する、Acmeという名前のIdPとZenithという名前のSPを考えます。Zenithに構成されたAcmeドメインでは、次のようになります。
転送URL = https://fed.acme.com/shareid/saml/ObSAMLTransferService
転送問合せ文字列 = DOMAIN=Zenith&METHOD=post&TARGET=
ターゲットURLがhttps://www.acme.com/
の場合、完全なリダイレクションURLは次のとおりです。
https://fed.acme.com/shareid/saml/ObSAMLTransferService?DOMAIN=Zenith&METHOD=post&TARGET=https://www.zenith.com/
前述のとおり、Fed SSO – WS-フェデレーション認証スキームを使用している場合、Oracle Identity FederationはObSAMLDomain
Cookieを使用してSAML 1.xのためのIdPを判定します。ただしSAML 1.xと異なり、ObSAMLDomain
Cookieがない場合は、WS-Federationで使用できる構成済IdPを列挙したIdP選択ページがOracle Identity Federationにより表示されます。そのようなIdPが1つのみの場合、Oracle Identity Federationは選択ページを省略してそのIdPを使用します。WS-Federation SSOが正常に完了すると、Oracle Identity FederationはIdPドメインにObSAMLDomain
Cookieを設定します。このため、ユーザーはSPへの最初のアクセスの際にIdPを選択するだけでかまいません。
SPが開始するSSOを実行する方法はWS-Federationパッシブ・リクエスタ・プロファイルにより指定されるため、WS-Federation認証スキームが機能するために、追加のOracle Identity Federation構成は必要ありません。
すべてのAccess認証スキームと同様に、Fed SSO – SAML 1.xとFed SSO – WS-Federationスキームは、認証方式の強さを表す認証レベルを持っています。Fed SSOスキームのデフォルト認証レベルは1(最も低い強さ)ですが、アクセス・システム・コンソールを使用してレベルを調整できます。
注意: Oracle Identity Federationは、構成済アサーション・マッピングのための他の認証スキームを作成します。このアサーション・マッピング・スキームはローカル・セッションを作成するために使用され、その認証レベルは、WS-Federation SSOのスキーム・レベル以上の強さである必要があります。 |
Liberty 1.x/SAML 2.0 SSOをトリガーできるのは、eTrust SiteMinderポリシーによって保護されたリソースをリクエストした場合です。
このためにeTrust SiteMinderの下でポリシーを作成すると、リソースがフォーム認証スキームを使用して保護されます。eTrust SiteMinder管理コンソールを使用してフォーム認証スキームを追加する必要があります。認証スキームを追加する場合は、HTMLフォーム・テンプレートとしてスキーム・タイプを選択し、続いて次のように変更します。
保護レベルを1
に設定します。
「Scheme Setup」タブで、
「Server name」をCASiteMinderHost.domain:Port
と設定します。
「Target」を/siteminderagent/forms/login.fcc.redirect.html
と設定します。
「Advance」タブで、「Library」をsmauthhtml
と設定します。
フォーム認証スキームを構成したら、次に示すHTMLファイルを、login.fcc.redirect.html
という名前で<NetegritySMInstallArea>\SMWebAgent\Samples\Forms
の下に追加します。
<html> <!--Redirect to OIF--> <body onload="setTimeout(location.href=getRedirectURL(), 1);"/> <script> //<!-- function getRedirectURL () { var targetParam = getQueryParam("TARGET"); if (targetParam.indexOf("$SM$") == 0) targetParam = targetParam.substring (4, targetParam.length); // Redirect var redirectURL = "http://<SPHost.Domain>:<Port>/fed/sp/smredirect?providerid=" + escape("http://<idPHost.Domain>:<Port>/fed/idp") +"&targetURL=" + targetParam; return redirectURL; } function getQueryParam (param) { var result = ""; var url = location.href; var qIndex = url.indexOf("?"); if (qIndex > -1) { var queryString = url.substring(qIndex + 1, url.length); var params = queryString.split("&"); for (var i = 0, n = params.length; i < n; ++i) { var nvPair = params[i].split("="); if (nvPair[0] == param) { result = nvPair[1]; break; } } } return result; } //--> </script> </html>
このフォームは、ユーザーをSP上のサーブレットにリダイレクトします。このサーブレットは、次のとおりに動作します。
targetURL問合せパラメータを処理します。
シングル・サインオンの完了後、ユーザーが最終的にこのパラメータが指定するURLにリダイレクトされるフローを開始します。
保護されたリソースをリクエストする場合、Oracle Identity FederationがSSO処理を実行するために使用するURL問合せパラメータを指定できます。パラメータは次のとおりです。
providerid
: SSO処理を実行するために使用するLiberty 1.xまたはSAML 2.0 IdPの識別子です(オプション)。これがない場合、Oracle Identity Federation管理コンソールの「サービス・プロバイダ」→「グローバル設定」→「デフォルトSSOアイデンティティ・プロバイダ」で構成されたデフォルトのSSOプロバイダが使用されます。
federationid
: SSOで使用するアフィリエーションの識別子です(オプション)。そうしたURLの例を次に示します。
http://protected_app:port/path?providerid=http://idp.com
詳細は「アフィリエーション関連の作業」を参照してください。
注意: URL問合せパラメータ値が正しくエンコードされていることを確認します。 |
構成の詳細は、eTrust SiteMinderのマニュアルを参照してください。
SAML 1.x/WS-Federation SSOをトリガーできるのは、固有フォーマットのURLをリクエストした場合です。
IdPからSAML 1.x SSOをトリガーするには、次の形式のURLを使用します。
http(s)://<idPHost.Domain>:<Port>/shareid/saml/ObSAMLTransferService?DOMAIN=<SP-DomainName>&METHOD=POST&TARGET=<Resource-protected-by-CASiteMinder>
ここで、Resource-protected-by-CASiteMinder
は、eTrust SiteMinderによって保護されている任意のリソースです。
SPからSAML 1.x SSOを開始するには、「eTrust SiteMinderとLiberty 1.x/SAML 2.0」で説明したように、eTrust SiteMinder側でフォーム認証スキームによってリソースを保護します。次のような形式を使用します。
<html> <!--Redirect to OSFS--> <body onload="setTimeout(location.href=getRedirectURL(), 1);"/> <script> //<!-- function getRedirectURL () { var targetParam = getQueryParam("TARGET"); if (targetParam.indexOf("$SM$") == 0) targetParam = targetParam.substring(4, targetParam.length); // Redirect var redirectURL = "http://<SPHost.Domain>:<Port>/shareid/saml/ObSAMLTransferForm?"+ "&TARGET=" + targetParam; return redirectURL; } function getQueryParam (param) { var result = ""; var url = location.href; var qIndex = url.indexOf("?"); if (qIndex > -1) { var queryString = url.substring(qIndex + 1, url.length); var params = queryString.split("&"); for (var i = 0, n = params.length; i < n; ++i) { var nvPair = params[i].split("="); if (nvPair[0] == param) { result = nvPair[1]; break; } } } return result; } //--> </script> </html>
SPリソースにアクセスすると、ユーザーはOracle Identity Federationサーブレットにリダイレクトされます。このサーブレットは、SSOでどのIdPを使用するかを示すHTTPリクエスト内でObSAMLDomain
という名前のCookieを探し、続いてユーザーを認証のためにそのIdPにリダイレクトします。Oracle Identity Federationは、IdPが開始するSAML 1.xシングル・サインオンの最後で、この永続CookieをIdPの構成済ドメインの名前に自動的に設定します。これは、この機能が動作するためには、少なくとも1回、ユーザーによるSAML 1.x SSOの実行が成功する必要があることを意味します。Oracle Identity FederationがObSAMLDomain
Cookieを検索しない場合は、ユーザーはローカルで、サービス・プロバイダ・ドメインへのローカル・ログインを実行すると想定されています。
注意: この機能はOracle COREid FederationではSmartMarksと呼ばれていました。 |
SAML 1.x認証スキームが機能するには、SP側に多少のOracle Identity Federation追加構成が必要です。IdP用のSAML 1.x/WS-Federationドメインの構成で、SPが開始するIdP検出が有効にされ、転送URLと転送問合せ文字列フィールドが構成されている必要があります。転送URLはIdPでSAML 1.x SSOを開始するために使用されるURLであり、転送問合せ文字列は、SSOがSPに戻されるためのパラメータを提供します。
注意: このURLと問合せ文字列はSAML 1.x仕様で指定されていないため、IdPが使用するSAML実装により異なます。Oracle Identity FederationがSSOを処理する場合、IdPへのリダイレクションで使用するために、転送URL、送信問合せ文字列、およびリクエストされたリソース(ターゲット)のURLが連結されます。これには、ターゲットURLパラメータが転送問合せ文字列の最後のパラメータである必要があります。 |
IdPが別にインストールされたOracle Identity Federationである場合、転送URLと転送問合せ文字列はOracle Identity Federationの規則に従って部分的に設定されます。転送問合せ文字列の末尾は、そのSPに対するIdP構成に固有の情報(IdPで構成されたSPドメイン名と、使用されるSSO方式)である必要があります。
WS-Federation SSOをトリガーするには、次の形式のURLを使用します。
http(s)://<SPHost.Domain>:<Port>/shareid/wsfederation/ObWSFedResourceSTS?wa=wsignin1.0&wctx=<Resource-Protected-by-CASiteMinder>
ここで、Resource-protected-by-CASiteMinder
は、eTrust SiteMinderによって保護されている任意のリソースです。
Oracle Identity Federationは、認証で使用されるIdPを示すHTTPリクエスト内のObSAMLDomain
Cookieを使用します。ObSAMLDomain
Cookieがない場合は、WS-Federationで使用できる構成済IdPを列挙したIdP選択ページがOracle Identity Federationにより表示されます。そのようなIdPが1つのみの場合、Oracle Identity Federationは選択ページを省略してそのIdPを使用します。WS-Federation SSOが正常に完了すると、Oracle Identity FederationはIdPドメインにObSAMLDomain
Cookieを設定します。ユーザーはSPへの最初のアクセスの際にIdPを選択するだけでかまいません。
URLの例を示します。
http://costarica.myorg.co.in:7779/shareid/wsfederation/ObWSFedResourceSTS?wa=wsignin1.0&wctx=http://mulshi.myorg.co.in/mytest/index.html
Oracle Identity FederationサーバーがOracleAS Single Sign-On、Oracle Access ManagerまたはCA eTrust SiteMinderと統合される場合、ユーザーは、Oracle Identity Federation /SPインスタンスで直接サービスをリクエストすることによって、Liberty 1.x/SAML 2.0のSSO処理を開始することができます。
Oracle Identity FederationサーバーでリクエストされるURLは次のとおりです。
http(s)://Oracle Identity Federation_host:Oracle Identity Federation_port/fed/sp/initiatesso
そのURLをリクエストする場合、URL問合せパラメータを指定できます。
providerid
: SSO処理を実行するために使用するLiberty 1.xまたはSAML 2.0 IdPの識別子です(オプション)。これがない場合、Oracle Identity Federation管理コンソールの「サービス・プロバイダ」→「グローバル設定」→「デフォルトSSOアイデンティティ・プロバイダ」で構成されたデフォルトのSSOプロバイダが使用されます。
federationid
: SSOで使用するアフィリエーションの識別子です(オプション)。
詳細は「アフィリエーション関連の作業」を参照してください。
returnurl
- SSO処理が成功した場合にユーザーが送られるURLです。Oracle Identity Federation管理コンソールの「サーバー・プロパティ」→「トラスト・サークル」→「設定」でIdPに対して設定された「非送信請求SSOリレー状態」プロパティが空の場合は必須です。
そうしたURLの例を次に示します。
http://oif_host:oif_port/fed/sp/initiatesso?providerid=http://idp.com&returnurl=ProtectedAppURL
問合せパラメータ値が正しくURLエンコードされていることを確認します。
Oracle Identity FederationがOracleAS Single Sign-On、Oracle Access ManagerまたはeTrust SiteMinderと統合される場合、Oracle Identity Federation /SPインスタンスで、次のURLを使用して直接サービスをリクエストすることによって、SAML 1.xのSSO処理を開始することができます。
http(s)://oif_host:oif_port/shareid/saml/ObSAMLTransferForm?TARGET=targetURL
ここで、targetURL
は、リクエストされたリソースのURLです。ObSAMLTransferFormサービスは、「Fed SSO - SAML 1.x認証スキームの使用」で説明したように、Fed SSO – SAML 1.x認証スキームと同一のルールに従います。使用するIdPを指定するObSAMLDomain
Cookieを探します。ObSAMLDomain
Cookieが発見されない場合は、ローカル・ログインが実行されます。
例:
http://oif_host:oif_port/shareid/saml/ObSAMLTransferForm?TARGEt=http://host:port/protected.html
注意: Oracle Access Managerでは、ローカル・ユーザーを作成するために使用したアサーション・マッピング認証スキーム以下の強さの認証レベルを持つ、任意の認証スキームを使用するポリシー・ドメインによってtargetURLを保護することができます。 |
Oracle Identity FederationがOracleAS Single Sign-On、Oracle Access ManagerまたはeTrust SiteMinderと統合される場合、次の形式のURLを使用して、SPからWS-Federation SSOリクエストを開始することができます。
http(s)://oif_host:oif_port/shareid/wsfederation/ObWSFedResourceSTS?wa=wsignin1.0& wctx=targetURL
ここで、targetURL
は、リクエストされたリソースのURLです。ObWSFedResourceSTSサービスは、「Fed SSO - WS-Federation認証スキームの使用」で説明したように、Fed SSO – WS-Federation認証スキームと同一のルールに従います。ObSAMLDomain
Cookieがもしあれば、IdPを決定するために使用されます。WS-Federation用に構成されたIdPが1つのみの場合は、そのIdPが使用されます。複数の場合は、IdP選択ページが表示されます。
URLの例を示します。
http://host:port/shareid/wsfederation/ObWSFedResourceSTS? wa=wsignin1.0&wctx=http://host:port/protected.html
注意: Oracle Access Managerでは、ローカル・ユーザーを作成するために使用したアサーション・マッピング認証スキーム以下の強さの認証レベルを持つ、任意の認証スキームを使用するポリシー・ドメインによってtargetURLを保護することができます。 |
Oracle Identity Federationには、Liberty 1.xおよびSAML 2.0プロトコルの場合、IdPとして動作するOracle Identity FederationインスタンスでURLを直接リクエストすることによってSSO処理を開始する機能が用意されています。
Oracle Identity FederationサーバーでリクエストされるURLは次のような形式になります。
http(s)://oif_host:oif_port/fed/idp/initiatesso
そのURLをリクエストする場合、URL問合せパラメータを指定できます。
providerid
: SSO処理を実行するために使用するLiberty 1.xまたはSAML 2.0 SPの識別子です(必須)。
federationid
: SSOで使用するアフィリエーションの識別子です(オプション)。
詳細は「アフィリエーション関連の作業」を参照してください。
returnurl
- SSO処理が成功した場合にユーザーが送られるURLです(オプション)。
そうしたURLの例を次に示します。
http://oif_host:oif_port/fed/idp/initiatesso?providerid=http://sp.com&returnurl=ProtectedAppURL
注意: 問合せパラメータ値が正しくURLエンコードされていることを確認します。 |
Oracle Identity FederationでSAML 1.xによるSSOが有効にされている場合、IdPからSSOリクエストを開始できます。リクエストのURL形式は次のとおりです。
http(s)://oif_host:oif_port/shareid/saml/ObSAMLTransferService
パラメータは次のとおりです。
DOMAIN
: そのSPに対して構成されたドメインの名前
METHOD
: POSTまたはARTIFACT
TARGET
: アクセス対象のターゲットURL
例:
http://oif_host:oif_port/shareid/saml/ObSAMLTransferService?DOMAIN=SP_domain&METHOD=post&TARGET=http://host2:port/protected.html
Oracle Identity FederationでWS-FederationによるSSOが有効にされている場合、IdPからSSOリクエストを開始できます。次の形式のURLを使用します。
http(s)://oif_host:oif_port/shareid/wsfederation/ObWSFedIdentitySTS
パラメータは次のとおりです。
wa
: wsignin1.0
wtrealm
: SPによって定義されたリクエスト・レルムURI
wctx
: アクセス対象のターゲットURL
例:
http://oif_host:oif_port/shareid/wsfederation/ObWSFedIdentitySTS?wa=wsignin1.0& wtrealm=http://sp_host/&wctx=http://sp_host:port/protected.html
アフィリエーションの実行時動作は、Oracle Identity FederationサーバーがIdPとSPのいずれとして動作しているかにより異なります。
Oracle Identity FederationがIdPとして動作している場合
Oracle Identity FederationがIdPの場合、アフィリエーション/SPがトラスト・サークルに存在し、有効であれば、Oracle Identity Federationサーバーは、アフィリエーションを使用するサービス・プロバイダが送信するあらゆるリクエストを処理する準備ができています。
Oracle Identity FederationがSPとして動作している場合
SPとして、SPが所属するアフィリエーションを使用して、IdPへのシングル・サインオン処理をトリガーできます。そのための手順は、IdMバックエンドが保護しているURLにfederationid
問合せパラメータを含め、そのアフィリエーションIDにパラメータ値を設定するだけです。
OracleASシングル・サインオン・バックエンドを例にとって、リソースがmod_osso
によって保護され、Oracle Identity Federation用に構成されていると仮定します。このとき、federationid
問合せパラメータを使用してこのリソースのURLをリクエストすると、Oracle Identity Federationは、ピアIdPに対してシングル・サインオンを実行する際にアフィリエーションを使用します。そのようなURLの例を次に示します。
http://protected_res_host:protected_res_port/path?federationid=http://affiliationid
同一のfederationid
問合せパラメータを使用して、直接http://oif_host:oif_port/fed/sp/initiatesso
URLにアクセスすることも可能です。この場合、Oracle Identity Federationはシングル・サインオン処理をトリガーし、ピアIdPの非送信請求SSOリレー状態を、ユーザーが認証成功後にリダイレクトされるURLとして使用します。
注意: 非送信請求SSOリレー状態は、Oracle Identity Federation管理コンソールの「サーバー構成」→「トラスト・サークル」→「信頼できるプロバイダの編集」ページで設定されています。 |
サービス・プロバイダのキーストアにアイデンティティ・プロバイダの自己署名証明書をエクスポートするには次の手順に従ってください。この手順はSAML 1.xおよびWS-Federation構成で使用されます。
アイデンティティ・プロバイダ側で、Oracle Identity Federationのホーム・ディレクトリでkeytoolユーティリティを実行することによって、キーストアから自己署名証明書をエクスポートします。
C:\<OIFHome>\jdk\jre\lib\security>keytool -keystore C:\<OIFHome>\fed\shareid\oblix\config\keystore -storepass <password> -export -alias shareid -file <myfile>
ここで、storepass
は、Oracle Identity Federationがインストールされたときに指定されたパスワードです。
サービス・プロバイダがアクセスできる場所に証明書ファイルをコピーします。
サービス・プロバイダで、IdPの証明書をキーストアにインポートします。
C:\<OIFHome>\jdk\jre\lib\security>keytool -keystore C:\<OIFHome>\fed\shareid\oblix\config\keystore -storepass <password> -import -alias <anyName>-file <myfile>
Oracle Enterprise ManagerコンソールからOracle Identity Federationサービス・プロバイダを再起動します。
一時/単発識別子は一般に匿名識別子と呼ばれ、サービス・プロバイダ(SP)で、ユーザーがアイデンティティ・プロバイダ(IdP)によって認証されることだけが求められ、ユーザーのIDを知る必要がない場合に使用されます。
IdPはユーザーを認証しているはずなので、一般にユーザーのアイデンティティを知っていますが、SPは、ユーザーがIdPに認証されたという事実以外、アイデンティティに関する知識は一切ありません。
一時/単発識別子は、SPとIdPの両方で構成される必要があります。
サービス・プロバイダで次の構成手順を実行します。
Oracle Identity Federation管理コンソールにログオンします。
「サーバー構成」→「トラスト・サークル」に移動します。
「匿名ユーザー識別子」フィールドに、匿名ユーザーを識別するために使用される、ユーザー・データ・ストアのアカウントのユーザーIDを入力します。このユーザーIDは、ユーザーを参照するのに使用されるIDと同タイプの(つまり、「ユーザー・データ・ストア」ページの「ユーザーID属性」または「ログインID列」に対応する)ものにします。
「保存」をクリックします。
「サーバー構成」→「サービス・プロバイダ」に移動し、Liberty 1.2とSAML 2.0のどちらか適切な方を選択します。
注意: 一時識別子はLiberty 1.1ではサポートされません。 |
「デフォルト認証リクエスト名前IDフォーマット」で、「一時/単発識別子」を選択します。
「保存」、「サーバーのリフレッシュ」の順にクリックします。
アイデンティティ・プロバイダで次の構成手順を実行します。
Oracle Identity Federation管理コンソールにログオンします。
「サーバー構成」→「アイデンティティ・プロバイダ」に移動し、Liberty 1.2とSAML 2.0のどちらか適切な方を選択します。
注意: 一時識別子はLiberty 1.1ではサポートされません。 |
「アサーション名前IDフォーマット」で「選択」をクリックします。
一時/単発識別子名前IDフォーマットを有効にするには、ボックスを選択します。
「適用」、「サーバーのリフレッシュ」の順にクリックします。
Oracle Identity Federationは、リモート・プロバイダとSAMLメッセージを交換するときにユーザーを参照するために様々な種類の名前IDをサポートしています。これには、次が含まれます。
X.509サブジェクト名
通常、このフォーマットに基づく名前IDには、LDAPディレクトリ内のユーザーを参照する識別名(DN)が含まれます(例: cn=alice,cn=users,dc=oracle,dc=com
)。このフォーマットは、URI urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
によって識別されます。
電子メール・アドレス
名前ID値は、電子メール・アドレスで構成されています(例: alice@oracle.com
)。この名前IDタイプは、URI urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
によって識別されます。
Windowsドメイン修飾名
Windowsドメイン修飾ユーザー名は、DomainName\UserName
という形式の文字列です。この名前IDタイプは、URI urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
によって識別されます。
Kerberosプリンシパル名
名前ID要素の内容がname[/instance]@REALM
というフォーマットを使用したKerberosプリンシパル名の形式であることを示します。このフォーマットは、URI urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
によって識別されます。
永続識別子
要素の内容が、1つのアイデンティティ・プロバイダおよび1つのサービス・プロバイダ(またはサービス・プロバイダのアフィリエーション)に固有のプリンシパルの不透明な永続識別子であることを示します。この名前IDタイプは、URI urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
によって識別されます。
一時識別子
要素の内容が、存続期間が現在のユーザー・セッションに限定された不透明な識別子(永続識別子と同様)であることを示します。この名前IDタイプは、URI urn:oasis:names:tc:SAML:2.0:nameid-format:transient
によって識別されます。
未指定
このフォーマットの名前IDの内容はSAML 2.0の仕様には拘束されず、緊密に相互作用するその実装に準拠します。この名前IDタイプは、URI urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
によって識別されます。
カスタマイズ可能名前IDフォーマット
Oracle Identity Federationを使用すると、管理者は、特定のデプロイメントに固有のニーズを満たす名前IDフォーマットを定義できます。カスタマイズ可能フォーマットを使用すると、フォーマットを識別するためのURIも定義できます。このフォーマットは、SAML 2.0の仕様では定義されていません。
送信メッセージに含める名前IDの生成時には、Oracle Identity Federationによって次が実行されます。
フォーマットが永続または一時などの不透明なタイプである場合、ランダム値の名前IDを作成し、フェデレーション・レコードを使用して、作成したランダムな名前IDに関する情報を格納します。
X.509サブジェクト名、電子メール・アドレス、Windowsドメイン修飾名、Kerberosプリンシパル名、未指定、およびカスタマイズ可能名前IDフォーマットなど、フォーマットが不透明でないタイプである場合、名前IDのユーザー属性を取得します。
次の構成について説明します。
X.509サブジェクト名、電子メール・アドレス、Windowsドメイン修飾名、Kerberosプリンシパル名、永続および一時名前IDフォーマットを構成するには、「SAML 2.0アイデンティティ・プロバイダ名前IDフォーマットの選択」の指示に従います。
未指定およびカスタマイズ可能フォーマットは、Oracle Identity Federation管理コンソールを使用して構成できません。これらのフォーマットを(未指定およびカスタマイズ可能を構成する場合は、有効にする必要がある他のフォーマットも)構成するには、次の手順を実行します。
$ORACLE_HOME/fed/conf/config.xml
ファイルを開きます。
FederationConfig
XML要素の場所を特定し、そのuseLocalConfig
属性をtrue
に設定します。
<FederationConfig useLocalConfig="true">
idpsaml20
という名前のXML Config
要素の場所を確認し、nameidformats
プロパティ・セットを探します。このプロパティ・セットには、Oracle Identity FederationまたはIdPで有効な名前IDフォーマットのリストが含まれています。特定のフォーマットが有効でない場合、Oracle Identity Federationではこのフォーマットが含まれるメッセージを処理できません。フォーマットを有効にするには、このフォーマットをリストに追加する必要があります。次の例では、すべての名前IDフォーマットが有効になっています。
<Config name="idpsaml20"> ... <propertyset name="nameidformats"> <propertyvalue>x509</propertyvalue> <!-- X.509 Subject Name --> <propertyvalue>emailaddress</propertyvalue> <!-- Email Address --> <propertyvalue>windowsnamequalifer</propertyvalue> <!-- Windows Domain Qualified Name --> <propertyvalue>kerberos</propertyvalue> <!-- Kerberos Principal Name --> <propertyvalue>persistent</propertyvalue> <!-- Persistent Identifier --> <propertyvalue>transient</propertyvalue> <!-- Transient Identifier --> <propertyvalue>unspecified</propertyvalue> <!-- Unspecified --> <propertyvalue>custom</propertyvalue> <!-- Customizable Name ID format --> </propertyset> ... </Config>
注意: 未指定およびカスタマイズ可能フォーマットを構成する場合、有効にする必要がある他のフォーマットもこのリストに表示される必要があることに注意してください。このため、電子メール、X509および未指定フォーマットを有効にする場合、管理者コンソールを使用してこのフォーマットの組合せを指定することはできませんが、かわりにここで示すようにファイルを編集する必要があります。 |
nameidformats
設定で使用可能な値は、次のとおりです。
x509
: X.509サブジェクト名
emailaddress
: 電子メール・アドレス
windowsnamequalifer
: Windowsドメイン修飾名
kerberos
: Kerberosプリンシパル名
persistent
: 永続識別子
transient
: 一時識別子
unspecified
: 未指定
custom
: カスタマイズ可能名前ID
名前IDフォーマットを有効にした後、不透明でない有効な名前IDタイプをユーザー属性にマップします(カスタマイズ可能名前IDフォーマットの場合は特別な構成が必要です)。
X.509サブジェクト名フォーマットをマップするには、idpsaml20
という名前のXML Config
要素の場所を確認し、nameformatx500
プロパティを探し、その値をユーザー属性に設定します。
<Config name="idpsaml20"> ... <property name="nameformatx500">dn</property> ... </Config>
電子メール・アドレス・フォーマットをマップするには、idpsaml20
という名前のXML Config
要素の場所を確認し、nameformatemail
プロパティを探し、その値をユーザー属性に設定します。
<Config name="idpsaml20"> ... <property name="nameformatemail">mail</property> ... </Config>
Windowsドメイン修飾名フォーマットをマップするには、idpsaml20
という名前のXML Config
要素の場所を確認し、nameformatwindows
プロパティを探し、その値をユーザー属性に設定します。
<Config name="idpsaml20"> ... <property name="nameformatwindows">windowsDQN</property> ... </Config>
Kerberosプリンシパル名フォーマットをマップするには、idpsaml20
という名前のXML Config
要素の場所を確認し、nameformatkerberos
プロパティを探し、その値をユーザー属性に設定します。
<Config name="idpsaml20"> ... <property name="nameformatkerberos">kerberosid</property> ... </Config>
未指定フォーマットをマップするには、idpsaml20
という名前のXML Config
要素の場所を確認し、nameformatunspecified
プロパティを探し、その値をユーザー属性に設定します。
<Config name="idpsaml20"> ... <property name="nameformatunspecified">uid</property> ... </Config>
カスタマイズ可能名前IDを構成するには、idpsaml20
という名前のXML Config
要素の場所を確認し、nameformatcustom
プロパティを探し、その値をユーザー属性に設定します。この名前IDのフォーマットも構成する必要があります。idpsaml20
という名前のXML Config
要素の場所を確認し、customnameidformat
プロパティを探し、その値を、管理者が使用するフォーマットに設定します。最後に、カスタマイズ可能名前IDフォーマット機能を有効にするとともに、これを手順3の有効な名前IDのリストに追加する必要があります。idpsaml20
という名前のXML Config
要素の場所を確認し、customnameidenabled
プロパティを探し、カスタマイズ可能名前IDを有効にする必要がある場合はその値をtrue
、そうでない場合はfalse
に設定します。
カスタマイズ可能名前IDフォーマットの構成例を次に示します。
<Config name="idpsaml20"> ... <property name="customnameidenabled">true</property> <property name="customnameidformat">Social-Security-Number</property> <property name="nameformatcustom">ssn</property> ... </Config>
最後に、デフォルト・アサーション名前IDフォーマットを設定する必要があります。この設定により、使用する名前IDがサービス・プロバイダによって指定されていないときに、SSOアサーションに送信する名前IDの種類が決まります。idpsaml20
という名前のXML Config
要素の場所を確認し、defaultnameidformat
プロパティを探し、その値を、使用する名前IDフォーマットに設定します。
<Config name="idpsaml20"> ... <property name="defaultnameidformat">x509</property> ... </Config>
defaultnameidformat
設定で使用可能な値は、次のとおりです。
x509
: X.509サブジェクト名
emailaddress
: 電子メール・アドレス
windowsnamequalifer
: Windowsドメイン修飾名
kerberos
: Kerberosプリンシパル名
persistent
: 永続識別子
transient
: 一時識別子
unspecified
: 未指定
custom
: カスタマイズ可能名前ID
ファイルを保存して終了します。
注意: 「サーバー・プロパティ」→「アイデンティティ・プロバイダ」→「SAML 2.0」ページにナビゲートし、「アサーション名前IDフォーマット」をクリックし、新しい画面で変更を行い(または変更を行わず)、「保存」をクリックすると、画面で定義されていない設定は削除されます。つまり、未指定およびカスタマイズ可能名前IDフォーマット構成は削除されます。 |
RDBMSをOracle Identity Federation一時データ・ストアとして使用する場合、OC4J_FEDを再起動します。使用しない場合は、Oracle Identity Federation管理コンソールで「サーバーのリフレッシュ」をクリックします。
Oracle Identity FederationでX.509サブジェクト名、電子メール・アドレス、Windowsドメイン修飾名、Kerberosプリンシパル名、永続および一時名前IDフォーマットを構成するには、「サービス・プロバイダ: 「SAML 2.0」プロパティ」および「SAML 2.0サービス・プロバイダ名前IDフォーマットの選択」の指示に従います。
未指定およびカスタマイズ可能フォーマットは、Oracle Identity Federation管理コンソールを使用して構成できません。これらのフォーマットを(未指定およびカスタマイズ可能を構成する場合は、有効にする必要がある他のフォーマットも)構成するには、次の手順を実行します。
$ORACLE_HOME/fed/conf/config.xml
ファイルを開きます。
FederationConfig
XML要素の場所を特定し、そのuseLocalConfig
属性をtrue
に設定します。
<FederationConfig useLocalConfig="true">
spsaml20
という名前のXML Config
要素の場所を確認し、nameidformats
プロパティ・セットを探します。このプロパティ・セットには、Oracle Identity FederationまたはSPでの自動アカウント・リンクに有効な名前IDフォーマットのリストが含まれています。特定のフォーマットが有効でない場合、Oracle Identity Federationではこのフォーマットが含まれるアサーションの処理時にフェデレーション・レコードをユーザーに自動的にリンクできません。フォーマットを有効にするには、このフォーマットをリストに追加する必要があります。次の例では、すべての名前IDフォーマットが有効になっています。
<Config name="spsaml20"> ... <propertyset name="nameidformats"> <propertyvalue>x509</propertyvalue> <!-- X.509 Subject Name --> <propertyvalue>emailaddress</propertyvalue> <!-- Email Address --> <propertyvalue>windowsnamequalifer</propertyvalue> <!-- Windows Domain Qualified Name --> <propertyvalue>kerberos</propertyvalue> <!-- Kerberos Principal Name --> <propertyvalue>unspecified</propertyvalue> <!-- Unspecified --> <propertyvalue>custom</propertyvalue> <!-- Customizable Name ID format --> </propertyset> ... </Config>
注意: 未指定およびカスタマイズ可能フォーマットを構成する場合、有効にする必要がある他のフォーマットもこのリストに表示される必要があることに注意してください。このため、電子メール、X509および未指定フォーマットを有効にする場合、管理者コンソールを使用してこのフォーマットの組合せを指定することはできませんが、かわりにここで示すようにファイルを編集する必要があります。 |
nameidformats
設定で使用可能な値は、次のとおりです。
x509
: X.509サブジェクト名
emailaddress
: 電子メール・アドレス
windowsnamequalifer
: Windowsドメイン修飾名
kerberos
: Kerberosプリンシパル名
unspecified
: 未指定
custom
: カスタマイズ可能名前ID
名前IDフォーマットを有効にした後、不透明でない有効な名前IDタイプをユーザー属性にマップします(カスタマイズ可能名前IDフォーマットの場合は特別な構成が必要です)。
X.509サブジェクト名フォーマットをマップするには、spsaml20
という名前のXML Config
要素の場所を確認し、nameformatx500
プロパティを探し、その値をユーザー属性に設定します。
<Config name="spsaml20"> ... <property name="nameformatx500">dn</property> ... </Config>
電子メール・アドレス・フォーマットをマップするには、spsaml20
という名前のXML Config
要素の場所を確認し、nameformatemail
プロパティを探し、その値をユーザー属性に設定します。
<Config name="spsaml20"> ... <property name="nameformatemail">mail</property> ... </Config>
Windowsドメイン修飾名フォーマットをマップするには、spsaml20
という名前のXML Config
要素の場所を確認し、nameformatwindows
プロパティを探し、その値をユーザー属性に設定します。
<Config name="spsaml20"> ... <property name="nameformatwindows">windowsDQN</property> ... </Config>
Kerberosプリンシパル名フォーマットをマップするには、spsaml20
という名前のXML Config
要素の場所を確認し、nameformatkerberos
プロパティを探し、その値をユーザー属性に設定します。
<Config name="spsaml20"> ... <property name="nameformatkerberos">kerberosid</property> ... </Config>
未指定フォーマットをマップするには、spsaml20
という名前のXML Config
要素の場所を確認し、nameformatunspecified
プロパティを探し、その値をユーザー属性に設定します。
<Config name="spsaml20"> ... <property name="nameformatunspecified">uid</property> ... </Config>
カスタマイズ可能名前IDを構成するには、spsaml20
という名前のXML Config
要素の場所を確認し、nameformatcustom
プロパティを探し、その値をユーザー属性に設定します。この名前IDのフォーマットも構成する必要があります。spsaml20
という名前のXML Config
要素の場所を確認し、customnameidformat
プロパティを探し、その値を、管理者が使用するフォーマットに設定します。最後に、カスタマイズ可能名前IDフォーマット機能を有効にするとともに、これを手順3の有効な名前IDのリストに追加する必要があります。spsaml20
という名前のXML Config
要素の場所を確認し、customnameidenabled
プロパティを探し、カスタマイズ可能名前IDを有効にする必要がある場合はその値をtrue
、必要がない場合はfalse
に設定します。
カスタマイズ可能名前IDフォーマットの構成例を次に示します。
<Config name="spsaml20"> ... <property name="customnameidenabled">true</property> <property name="customnameidformat">Social-Security-Number</property> <property name="nameformatcustom">ssn</property> ... </Config>
最後に、デフォルト認証リクエスト名前IDフォーマットを設定する必要があります。この設定により、認証リクエスト・メッセージをIdPに送信するときにOracle Identity Federation/SPによってリクエストされる名前IDの種類が決まります。この結果、IdPにより、ユーザーが認証され、リクエストされたフォーマットの名前IDが含まれるSSOアサーションが返信されます。spsaml20
という名前のXML Config
要素の場所を確認し、defaultauthnrequestnameidformat
プロパティを探し、その値を、使用する名前IDに設定します。
<Config name="spsaml20"> ... <property name="defaultauthnrequestnameidformat">x509</property> ... </Config>
defaultauthnrequestnameidformat
設定で使用可能な値は、次のとおりです。
x509
: X.509サブジェクト名
emailaddress
: 電子メール・アドレス
windowsnamequalifer
: Windowsドメイン修飾名
kerberos
: Kerberosプリンシパル名
persistent
: 永続識別子
transient
: 一時識別子
unspecified
: 未指定
custom
: カスタマイズ可能名前ID
ファイルを保存して終了します。
注意:
|
RDBMSをOracle Identity Federation一時データ・ストアとして使用する場合、OC4J_FEDを再起動します。使用しない場合は、Oracle Identity Federation管理コンソールで「サーバーのリフレッシュ」をクリックします。
X.509サブジェクト名、電子メール・アドレス、Windowsドメイン修飾名、Kerberosプリンシパル名、永続および一時名前IDフォーマットを構成するには、「信頼できるプロバイダの編集」および「信頼できるプロバイダの編集: 名前IDフォーマットの選択」の指示に従います。
未指定およびカスタマイズ可能フォーマットは、Oracle Identity Federation管理コンソールを使用して構成できません。これらのフォーマットを(未指定およびカスタマイズ可能を構成する場合は、有効にする必要がある他のフォーマットも)構成するには、次の手順を実行します。
$ORACLE_HOME/fed/conf/config.xml
ファイルを開きます。
FederationConfig
XML要素の場所を特定し、そのuseLocalConfig
属性をtrue
に設定します。
<FederationConfig useLocalConfig="true">
ファイルを保存して終了します。
$ORACLE_HOME/fed/conf/cot.xml
ファイルを開きます。
特定の構成を設定する必要があるリモート・プロバイダの識別子がproviderID
属性に含まれるXML PeerProvider
要素の場所を確認します。
PeerProvider
要素の子であるXML Config
要素の場所を確認します。このConfig
要素を使用して、前述の「IdPとしての名前IDフォーマットの構成」および「SPとしての名前IDフォーマットの構成」で説明した手順を実行し、名前IDフォーマットを構成します。例:
<PeerProvider providerID="http://idp.com" ...> ... <Config> ... <propertyset name="nameidformats"> <propertyvalue>x509</propertyvalue> <!-- X.509 Subject Name --> <propertyvalue>emailaddress</propertyvalue> <!-- Email Address --> </propertyset> <property name="nameformatx500">dn</property> <property name="nameformatemail">mail</property> <property name="defaultauthnrequestnameidformat">x509</property> ... </Config> ... </PeerProvider>
ファイルを保存して終了します。
注意:
|
RDBMSをOracle Identity Federation一時データ・ストアとして使用する場合、OC4J_FEDを再起動します。使用しない場合は、Oracle Identity Federation管理コンソールで「サーバーのリフレッシュ」をクリックします。
Oracle Identity FederationがIdPとして動作している場合、アサーションに含まれる名前IDフォーマットに応じてプロバイダごとにSSOアサーションで属性を送信するよう構成できます(管理者は、特定の名前IDフォーマットの属性のみをSSOアサーションに含めるようOracle Identity Federationを構成できます)。
X.509サブジェクト名、電子メール・アドレス、Windowsドメイン修飾名、Kerberosプリンシパル名、永続および一時名前IDフォーマットのSSOアサーションの属性を構成するには、「信頼できるプロバイダの編集: 属性マッピング」の指示に従います。
未指定およびカスタマイズ可能フォーマットは、Oracle Identity Federation管理コンソールを使用して構成できません。これらのフォーマットを(未指定およびカスタマイズ可能を構成する場合は、有効にする必要がある他のフォーマットも)構成するには、次の手順を実行します。
$ORACLE_HOME/fed/conf/config.xml
ファイルを開きます。
FederationConfig
XML要素の場所を特定し、そのuseLocalConfig
属性をtrue
に設定します。
<FederationConfig useLocalConfig="true">
ファイルを保存して終了します。
$ORACLE_HOME/fed/conf/cot.xml
ファイルを開きます。
特定の構成を設定する必要があるリモート・プロバイダの識別子がproviderID
属性に含まれるXML PeerProvider
要素の場所を確認します。
PeerProvider
要素の子であるXML Config
要素の場所を確認し、sendattributefornameid
という名前のプロパティ・セット要素を探します。このpropertyset
要素には、この名前IDフォーマットが含まれるSSOアサーションに属性を含める必要があることをOracle Identity Federationに伝えるアサーション名前IDフォーマットのリストが含まれます。次のように、目的の名前IDフォーマットをリストに追加します。
<PeerProvider providerID="http://idp.com" ...> ... <Config> ... <propertyset name="sendattributefornameid"> <propertyvalue>x509</propertyvalue> <!-- X.509 Subject Name --> <propertyvalue>emailaddress</propertyvalue> <!-- Email Address --> <propertyvalue>windowsnamequalifer</propertyvalue> <!-- Windows Domain Qualified Name --> <propertyvalue>kerberos</propertyvalue> <!-- Kerberos Principal Name --> <propertyvalue>persistent</propertyvalue> <!-- Persistent Identifier --> <propertyvalue>transient</propertyvalue> <!-- Transient Identifier --> <propertyvalue>unspecified</propertyvalue> <!-- Unspecified --> <propertyvalue>custom</propertyvalue> <!-- Customizable Name ID format --> </propertyset> ... </Config> ... </PeerProvider>
次の値が可能です。
x509
: X.509サブジェクト名
emailaddress
: 電子メール・アドレス
windowsnamequalifer
: Windowsドメイン修飾名
kerberos
: Kerberosプリンシパル名
persistent
: 永続識別子
transient
: 一時識別子
unspecified
: 未指定
custom
: カスタマイズ可能名前ID
ファイルを保存して終了します。
注意: 「サーバー・プロパティ」→「トラスト・サークル」ページにナビゲートし、リモート・プロバイダを選択し、「更新」をクリックし、「属性マッピング」をクリックし、新しい画面で変更を行い(または変更を行わず)、「保存」をクリックすると、画面で定義されていない設定は削除されます。つまり、未指定およびカスタマイズ可能名前IDフォーマット構成は削除されます。 |
RDBMSをOracle Identity Federation一時データ・ストアとして使用する場合、OC4J_FEDを再起動します。使用しない場合は、Oracle Identity Federation管理コンソールで「サーバーのリフレッシュ」をクリックします。
一般に、シングル・サインオン処理を実行する場合、サービス・プロバイダは、アイデンティティ・プロバイダがユーザー情報を含むアサーションを送信する場合のための名前IDフォーマットを指定します。それにはサービス・プロバイダ構成の「デフォルト認証リクエスト名前IDフォーマット」を選択します。
ただし、名前IDフォーマットを指定しないようにサービス・プロバイダを構成できます。その手順を次に示します。
Oracle Identity Federation管理コンソールにログオンします。
「サーバー構成」→「サービス・プロバイダ」に移動し、Liberty 1.2とSAML 2.0のどちらか適切な方を選択します。
注意: 未指定フォーマットはLiberty 1.1ではサポートされません。 |
「デフォルト認証リクエスト名前IDフォーマット」で、「未指定」を選択します。
「保存」、「サーバーのリフレッシュ」の順にクリックします。
リクエストされた名前IDフォーマットのないシングル・サインオン・リクエストをSPから受信すると、IdPは既存のフェデレーションを使用してシングル・サインオン処理を実行します。IdPは、フェデレーションが存在しない場合、IdPに構成されたデフォルトのアサーション名前IDフォーマットに基づいて新規フェデレーションを作成します。このフォーマットを構成するには、次の手順を実行します。
Oracle Identity Federation管理コンソールにログオンします。
「サーバー構成」→「アイデンティティ・プロバイダ」に移動し、Liberty 1.2とSAML 2.0のどちらか適切な方を選択します。
注意: 未指定フォーマットはLiberty 1.1ではサポートされません。 |
「アサーション名前IDフォーマット」をクリックします。
「デフォルト・アサーション名前IDフォーマット」を選択します。
「適用」、「サーバーのリフレッシュ」の順にクリックします。
この項では、サービス・プロバイダ側の自動アカウント・リンクと、その使用方法について説明します。内容は次のとおりです。
SP側の自動アカウントにより、サービス・プロバイダはユーザーへのアサーションに含まれるアイデンティティを直接マップできます。この機能を使用した場合は、次のようになります。
ユーザーおよびピアIdP用のフェデレーションが存在しない場合、ユーザーに資格証明を求めることなく新しいフェデレーションを作成できます。これは、フェデレーション・データ・ストアとの組合せで行います。
フェデレーション・データ・ストアを使用してフェデレーション・レコードを格納するのに、Oracle Identity Federationサーバーは必要ありません。
自動アカウント・リンクは、次のものが有効である場合、不透明でない名前識別子を使用するSAML 2.0 SSO処理に対してサポートされます。
X.509
電子メール・アドレス
Kerberosプリンシパル名
Windowsドメイン修飾名
未指定
カスタマイズ可能名前IDフォーマット
この機能は、次の場合、サポートされません。
Liberty 1.x SSO
永続名前識別子および一時名前識別子を使用するSAML 2.0 SSO処理
この機能を使用する場合、フェデレーションの作成が許可されていることを確認します(「サービス・プロバイダ」 - 「グローバル設定」)。
SPで自動アカウント・リンクを構成するには、次の手順を実行します。
サービス・プロバイダを、不透明でないSAML 2.0名前IDをリクエストするように構成します。
Oracle Identity Federation管理コンソールに移動します。
「サーバー構成」→「サービス・プロバイダ」に移動し、「SAML 2.0」を選択します。
「デフォルト認証リクエスト名前IDフォーマット」で、「X.509」、「電子メール・アドレス」、「Kerberosプリンシパル名」または「Windowsドメイン修飾名」のいずれかを選択します。
注意: 「未指定」も選択できます。この場合、IdPが決定する名前IDフォーマットは不透明でない必要があります。 |
「適用」をクリックします。
選択された名前IDフォーマットを、ユーザー・レコードを一意に参照するユーザー属性にマップします。
「サーバー構成」→「サービス・プロバイダ」に移動し、「SAML 2.0」を選択します。
「アカウント・リンク名前IDフォーマット」をクリックします。
有効にする名前IDフォーマットと、指定された名前IDのユーザー情報を含む属性名を確認します。
注意: dn は、LDAPエントリのDNを参照します。 |
「適用」をクリックします。
自動アカウント・リンク機能を有効にします。
「サーバー構成」→「サービス・プロバイダ」に移動し、「SAML 2.0」を選択します。
「自動アカウント・リンク有効」 プロパティを選択します。
「適用」、「サーバーのリフレッシュ」の順にクリックします。
この項では、アイデンティティ・プロバイダ側の自動アカウント・リンクと、その使用方法について説明します。内容は次のとおりです。
アイデンティティ・プロバイダ側で自動アカウント・リンクを使用すると、フェデレーションが存在せず、SPがフェデレーションの作成をリクエストしなかった場合に、IdPがフェデレーションを自動的に作成できます。この機能を使用した場合は、次のようになります。
ユーザーおよびピアSP用のフェデレーションが存在しない場合、SPによるリクエストがなくても新しいフェデレーションを作成できます。これは、フェデレーション・データ・ストアとの組合せで行います。
フェデレーション・データ・ストアを使用してフェデレーション・レコードを格納するのに、Oracle Identity Federationサーバーは必要ありません。
自動アカウント・リンクは、次のものが有効である場合、不透明でない名前識別子を使用するSAML 2.0 SSO処理に対してサポートされます。
X.509
電子メール・アドレス
Kerberosプリンシパル名
Windowsドメイン修飾名
未指定
カスタマイズ可能名前IDフォーマット
この機能は、次の場合、サポートされません。
Liberty 1.x SSO
永続名前識別子および一時名前識別子を使用するSAML 2.0 SSO処理
IdPを自動アカウント・リンク用に構成するには、次の手順を実行します。
名前IDフォーマット・マッピングを指定します。
「サーバー構成」→「アイデンティティ・プロバイダ」に移動し、「SAML 2.0」を選択します。
「アサーション名前IDフォーマット」をクリックします。
有効にする名前IDフォーマットと、指定された名前IDのユーザー情報を含む属性名を確認します。
注意: dn は、LDAPエントリのDNを参照します。 |
「適用」をクリックします。
オプションで、デフォルトのアサーション名前IDフォーマットを、不透明でない名前IDを使用するように構成します。
自動アカウント・リンク機能を有効にします。
「サーバー構成」→「アイデンティティ・プロバイダ」に移動し、「SAML 2.0」を選択します。
「自動アカウント・リンク有効」 プロパティを選択します。
「適用」、「サーバーのリフレッシュ」の順にクリックします。
Microsoft Active Directory Federation Services(ADFS)とOracle Identity Federationは両方とも、フェデレーテッド環境でアイデンティティ・プロバイダ(IdP)またはサービス・プロバイダ(SP)ロールを実行できます。
この項では、これらの製品が互いに連携して動作するよう構成する方法について説明します。内容は次のとおりです。
ここでは参考のため、Oracle Identity FederationとMicrosoft Active Directory Federation Services(ADFS)で使用されるフェデレーション用語の定義の比較を示します。
アイデンティティ・プロバイダ/アカウント・パートナ/IdP
アイデンティティ・プロバイダ/アカウント・パートナは、指定されたトラスト・サークル内でIDの集合を管理、認証および宣言します。
アイデンティティ・プロバイダは、他のサービス・プロバイダと連携するためのビジネス・インセンティブを提供するサービス・プロバイダです。
サービス・プロバイダ/リソース・パートナ/SP
サービス・プロバイダ/リソース・パートナは、プリンシパルにサービスや商品を提供します。ただし、プリンシパルのID認証はアイデンティティ・プロバイダ/アカウント・パートナに委ねます。
この項では、Active Directory Federation Services(ADFS)をIdPとしてOracle Identity Federationと統合するために必要な手順について説明します。この構成は、次の2つのノードから構成されます。
ノードAには、Oracle Identity Federationがサービス・プロバイダ(SP)・タイプのサーバーとしてインストールされています。
ノードBには、ADFSがアイデンティティ・プロバイダ(IdP)・タイプのサーバーとしてインストールされています。
この項で説明する構成に関するトピックは、次のとおりです。
この構成を実行する前に、Oracle Identity FederationがノードAにすでにインストールされ、サービス・プロバイダとして構成されていることを確認します。また、ADFSがノードBにインストールされ、アイデンティティ・プロバイダとして構成されていることを確認します。
Oracle Identity FederationがインストールされているノードAで次の手順を実行します。
Oracle Identity Federationにoif_admin
ユーザーとしてログインします。
「SAML 1.x/WSフェデレーション」をクリックします。
「ドメイン」タブを選択します。
「マイ・ドメイン」をクリックします。
次の情報を収集します。
リソース・レルムURI: このURIはIdPにSPを識別します。
リソース・レルム・セキュア・トークン・サービス(STS) URL: IdPがセキュリティ・トークンとともにユーザーをリダイレクトするURLです。
ADFSがインストールされているノードBで次の情報を収集します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
コンソール・ツリーで、「フェデレーション サービス」をダブルクリックし、「信頼ポリシー」を右クリックして、「プロパティ」をクリックします。
次の情報を収集します。
フェデレーション サービスの URI: SPにIdPを識別します。
フェデレーション サービス エンドポイントの URL: セキュリティ・トークンを取得するためにSPがユーザーをリダイレクトするIdP URLです。
アカウント・フェデレーション・サービスでADFSのフェデレーション・サービス・コンポーネントを実行しているサーバーは、作成するセキュリティ・トークンに署名するためにトークン署名証明書を要求します。ここでは、ADFSノードBからファイルにトークン署名証明書をエクスポートします。証明書をエクスポートするには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」を右クリックし、「プロパティ」をクリックします。
「表示」をクリックし、証明書を確認します。
「詳細」タブで、「ファイルへコピー」をクリックします。
「証明書のエクスポート ウィザードの開始」ページが表示されます。
「次へ」をクリックします。
「秘密キーのエクスポート」ページが表示されます。
「いいえ、秘密キーをエクスポートしません」を選択し、「次へ」をクリックします。
「エクスポート ファイルの形式」ページが表示されます。
「DER encoded binary X.509 (.Cer)」を選択し、「次へ」をクリックします。
注意: DER encoded Binary X.509およびBase-64 encoded X.509証明書では、ファイル名の拡張子として.cer が使用されます。Cryptographic Message Syntax Standard - PKCS #7証明書では、ファイル名の拡張子として.P7B が使用されます。 |
「エクスポートするファイル」ページが表示されます。
フォーマットFile_Name.cer
を使用してディレクトリおよびファイル名を選択し、「次へ」をクリックします。
ウィザードで指定した証明書のエクスポート・オプションを確認し、「完了」をクリックします。
この項では、ADFSをアイデンティティ・プロバイダとして認識するようOracle Identity Federationのサービス・プロバイダ・インスタンスを構成する方法について説明します。
ADFSアイデンティティ・プロバイダのトークン署名証明書をSPのキーストアにインポートするには、次の手順を実行します。
サービス・プロバイダがアクセスできる場所に、「トークン署名証明書のエクスポート」で収集した証明書ファイルをコピーします。
サービス・プロバイダで、IdPのトークン署名証明書をキーストアにインポートします。
C:\OIF Home\jdk\bin>keytool -keystore C:\OIF Home\fed\shareid\oblix\config\keystore -storepass password -import -alias anyName -file myfile
パラメータは次のとおりです。
password: oif_admin
ユーザーのパスワード
anyName: 別名を示す一意の名前
myfile: 以前に収集したFile_Name.cer
フォーマットの証明書ファイル
Oracle Enterprise ManagerコンソールからOracle Identity Federation SPインスタンスを再起動します。
Oracle Identity Federationでアサーションからユーザーへのマッピングを追加するには、次の手順を実行します。
Oracle Identity Federationにoif_admin
ユーザーとしてログインします。
「SAML 1.x/WSフェデレーション」→「宛先マッピング」をクリックします。
現在のアサーションからユーザーへのマッピングが表示されます。
「追加」をクリックし、新しいアサーションからユーザーへのマッピングを追加します。
次の情報を追加します。
マッピング名: ユーザー定義の名前です。目的の名前を入力します。
説明: マッピングの簡単な説明を入力します。
認証スキーム・レベル: Oracle Access Managerが使用する認証レベルを入力します。
検索ベース: Oracle Identity Federationがユーザーの場所を確認するために検索を開始するLDAPディレクトリ情報ツリー(DIT)・ノードを入力します(例: o=company, c=us
)。
個人オブジェクト・クラス: Oracle Access Managerが個人オブジェクト・クラスとして使用するオブジェクト・クラスを入力します(例: gensiteorgperson
)。
注意: 「認証スキーム・レベル」、「検索ベース」および「個人オブジェクト・クラス」にはデフォルト値はありません。これらのデータは指定する必要があります。 |
スクロールダウンしてローカル・ユーザー属性マッピングを追加します。
ローカル・ユーザーを識別するためにアサーション属性をローカル・ユーザー属性にマップします。属性を追加するには、「新規行の追加」をクリックします。
「送信」をクリックします。宛先マッピング・リストを確認し、新しいマッピングが作成されていることを確認します。
ADFS用としてOracle Identity Federationサーバーで非Oracle Identity Federationドメインを作成するには、次の手順を実行します。
Oracle Identity Federationサーバーにoif_admin
ユーザーとしてログインします。
「SAML 1.x/WSフェデレーション」タブをクリックし、「ドメイン」→「非Oracle Identity Federationドメインの追加」にナビゲートします。
「非Oracle Identity Federationドメインの追加」をクリックします。
次の情報を追加します。
ドメイン名
ドメインの説明
発行者: 「前提条件」で収集したフェデレーション・サービスのURIを入力します。
「このドメインを有効化」ボックスを選択します。
必要な「サポートされているプロトコル」を選択します。
スクロールダウンしてこのドメインをIdPとして構成します。
次の情報を指定します。
応答者URL: 「前提条件」で収集したフェデレーション・サービス・エンドポイントのURLを入力します。
注意: Oracle Identity Federationでは、この応答者URLに基づいてソースIDが生成されます。ソースIDを変更するには、応答者URLを変更し、「ソースID」フィールドの情報を削除し、「送信」をクリックし、ソースIDを再生成します。ソースIDは手動で再生成しないでください。 |
アイデンティティ・レルムURI: 「前提条件」で収集したフェデレーション・サービスのURIを入力します。
アイデンティティ・レルム・セキュア・トークン・サービス(STS) URL: 「前提条件」で収集したフェデレーション・サービス・エンドポイントのURLを入力します。
マッピング名: 「アサーションからユーザーへのマッピングの作成」で以前に作成したマッピングを選択します。
スクロールダウンして「リソース・レルムURI」および「リソース・レルム・セキュア・トークン・サービス(STS) URL」を構成します。
次の情報を指定します。
「送信」をクリックし、構成を送信します。
ドメイン・リストを確認し、ドメインが作成されており、有効であることを確認します。
リソース・パートナを追加することにより、Oracle Identity Federationをサービス・プロバイダとして認識するようADFSアイデンティティ・プロバイダを構成するには、次の手順を実行します。
「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「パートナーの組織」の順にダブルクリックし、「リソース パートナー」を右クリックします。「新規」をポイントし、「リソース パートナー」をクリックします。
「リソース パートナー追加のウィザードの開始」ページが表示されます。
「次へ」をクリックします。
「ポリシー ファイルのインポート」ページが表示されます。
質問に対して「いいえ」を選択し、「次へ」をクリックします。
「リソース パートナーの詳細」ページが表示されます。
次の情報を指定します。
表示名: 「Resource Partner」と入力します。
フェデレーション サービスの URI: 「前提条件」で収集したリソース・レルムURIを入力します。
フェデレーション サービス エンドポイントの URL: 「前提条件」で収集したリソース・レルム・セキュア・トークン・サービス(STS)URLを入力します。
「次へ」をクリックします。
「フェデレーションのシナリオ」ページが表示されます。
「フェデレーション Web SSO」を選択し、「次へ」をクリックします。
「リソース パートナー ID 要求」ページが表示されます。
「UPN 要求」チェック・ボックスを選択し、「次へ」をクリックします。
「UPN サフィックスの選択」ページが表示されます。
「すべての UPN のサフィックスを変更しないで渡す」を選択し、「次へ」をクリックします。
「このリソース パートナーを有効にする」ページが表示されます。
「このリソース パートナーを有効にする」ボックスを選択し、「次へ」をクリックします。
ウィザードの完了ページが表示されます。
新しいリソース・パートナの設定を確認し、「完了」をクリックします。
要求を構成するには、カスタム要求を作成し、カスタム要求の抽出をこの要求にマップし、出力方向のカスタム要求マッピングを作成する必要があります。
組織カスタム要求を作成するには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「自分の組織」の順にダブルクリックし、「組織の要求」を右クリックして、「新規」をポイントし、「組織の要求」をクリックします。
「組織の要求の新規作成」のダイアログ・ボックスの「要求の名前」に、「ADFS-OIF Test」と入力し、「カスタム要求」を選択し、「OK」をクリックします。
カスタム要求抽出を作成するには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「自分の組織」、「アカウント ストア」の順にダブルクリックし、「Active Directory」を右クリックして、「新規」をポイントし、「カスタム要求抽出」をクリックします。
ダイアログ・ボックスで、「この組織の要求にマップする」として「ADFS-OIF Test」を選択します。
アサーション属性をマップする属性名を入力します。
「OK」をクリックします。
組織カスタム要求にマップする出力方向のカスタム要求を作成するには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「パートナーの組織」、「リソース パートナー」の順にダブルクリックし、「リソース パートナー」を右クリックして、「新規」をポイントし、「出力方向のカスタム要求マッピング」をクリックします。
次の情報を指定します。
組織のカスタム要求: 「ADFS-OIF Test」と入力します。
出力方向のカスタム要求名: 「MyUserID」と入力します。(この属性は、宛先ドメインの管理者から収集されます。)
「OK」をクリックします。
ADFSでWS-Federationによるシングル・サインオン(SSO)が有効にされている場合、フォーマットhttps://adfs_host/adfs/ls/
のURLを使用してIdPからSSOリクエストを開始できます。
パラメータは次のとおりです。
wa
: 実行するアクションを指定します。アクションを含めることにより、URIをオーバーロードして複数の機能を実行できます。サインインの場合、この文字列は「wsignin1.0」である必要があります。
wtrealm
: SPによって定義されたリクエスト・レルムURI
wctx
: SPのドメインでアクセス対象となる保護されたリソースURL
wreply
: オプションのパラメータで、レスポンスの送信先のURL
例:
https://adfs_host/adfs/ls/?wa=wsignin1.0&wtrealm=http://oif_host:oif_port /&wctx=<protected_resource_url>&wreply=http://oif_host:oif_port /shareid/wsfederation/ObWSFedResourceSTS
Oracle Identity FederationでWS-FederationによるSSOが有効にされている場合、SPからSSOリクエストを開始できます。次の形式のURLを使用します。
http(s)://oif_host:oif_port/shareid/wsfederation/ObWSFedResourceSTS
パラメータは次のとおりです。
wa: この必須パラメータにより、実行するアクションを指定します。アクションを含めることにより、URIをオーバーロードして複数の機能を実行できます。サインインの場合、この文字列は「wsignin1.0」である必要があります。
wctx: アクセス対象となる保護されたリソースURL
例:
http(s)://oif_host:oif_port/shareid/wsfederation/ObWSFedResourceSTS?wa=wsignin1.0&wctx=<protected resource url>
IdPが開始するログアウトとWS-FederationのURLは、次のとおりです。
https://adfs_host/adfs/ls/?wa=wsignout1.0
SPが開始するログアウトとWS-FederationのURLは、次のとおりです。
http(s)://oif_host: oif_port/shareid/wsfederation/ObWSFedResourceSTS?wa=wsignout1.0
waは、実行するアクションを指定する必須パラメータです。アクションを含めることにより、URIをオーバーロードして複数の機能を実行できます。ログアウトの場合、この文字列は「wsignout1.0」である必要があります。
この項では、Oracle Identity Federationがアイデンティティ・プロバイダとして機能する状態で、Microsoft Active Directory Federation Services(ADFS)をサービス・プロバイダとして構成する方法について説明します。この手順では、2つのノードから構成される構成シナリオを説明します。
ノードA: Oracle Identity Federation
ノードB: ADFS
Oracle Identity Federationがアイデンティティ・プロバイダ(IdP)・タイプのサーバーとしてインストールされており、ADFSがサービス・プロバイダ(SP)・タイプのサーバーとしてインストールされていることを確認します。
Oracle Identity FederationがインストールされているノードAに移動し、次の情報を収集します。
Oracle Identity Federationにoif_admin
ユーザーとしてログインします。
「SAML 1.x/WSフェデレーション」→「ドメイン」→「マイ・ドメイン」にナビゲートします。
「マイ・ドメイン」ページが表示されます。
次の情報を収集します。
アイデンティティ・レルムURI: SPにIdPを識別します。
アイデンティティ・レルム・セキュア・トークン・サービス(STS) URL: セキュリティ・トークンを取得するためにSPがユーザーをIdPにリダイレクトするURLです。
Oracle Identity FederationのSAML1.x/WS-Fedキーストアからアイデンティティ・プロバイダの署名証明書をエクスポートするには、次の手順を実行します。この手順はSAML 1.xおよびWS-Federation構成で使用されます。
アイデンティティ・プロバイダ側で、Oracle Identity Federationのホーム・ディレクトリでkeytool
ユーティリティを実行することによって、キーストアから自己署名証明書をエクスポートします。
C:\<OIF Home>\jdk\bin>keytool -keystore C:\OIF_Home\fed\shareid\oblix\config\keystore -storepass password -export -alias shareid -file myfile
パラメータは次のとおりです。
password: oif_admin
ユーザーのパスワード
myfile: 証明書を格納するためのフォーマットFile_Name.cer
のファイル名
サービス・プロバイダがアクセスできる場所にこの証明書ファイルをコピーします。
ADFSがインストールされているノードBに移動し、次の情報を収集します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
コンソール・ツリーで、「フェデレーション サービス」をダブルクリックし、「信頼ポリシー」を右クリックして、「プロパティ」をクリックします。
次の情報を収集します。
フェデレーション サービスの URI: IdPにSPを識別します。
フェデレーション サービス エンドポイントの URL: IdPがセキュリティ・トークンとともにユーザーをリダイレクトするSP URLです。
ADFSをサービス・プロバイダとして認識するよう(アイデンティティ・プロバイダとして動作する)Oracle Identity Federationを構成するには、次の手順を実行します。
ユーザーがリソースをリクエストすると、ソース・サイト(IdP)は、ユーザーのIDが真正であることを証明するアサーションを宛先サイトに提供します。宛先に送信されるアサーションの内容を定義するアサーション・プロファイルを定義するには、次の手順を実行します。
Oracle Identity Federationにoif_admin
ユーザーとしてログインします。
「SAML 1.x/WSフェデレーション」→「アサーション・プロファイル」にナビゲートします。
「追加」をクリックし、新しいアサーションを追加します。
次の情報を追加します。
アサーション・プロファイル名。
説明
発行者: http://
oif_host:oif_port/
など
サブジェクト名クオリファイア: このオプションのサブジェクト名クオリファイアを使用して、SAML準拠サーバーはユーザーのネームスペースを確認できます。この情報は、ソース・ドメインに関する情報用として有用な場合があります。たとえば、jsmith@oblix.comのアサーションにはJ. Smithの部門が含まれる場合があります(例: ou=Department,o=Company,c=US
)。
サブジェクト・フォーマット: アサーションによって識別されるユーザーであるサブジェクトのフォーマットです。サブジェクトは、アサーション・サブジェクト要素のNameIdentifier
サブ要素としてアサーションに表示されます。次の属性フォーマットのリストからフォーマットを選択します。
なし: フォーマットは指定されません。
電子メール・アドレス: NameIdentifier
が電子メール・アドレスとしてフォーマットされます。
X.509サブジェクト名: NameIdentifier
はDN形式になります(例: cn=myname,dc=example,dc=com
)。
Windowsドメイン: DomainName\UserNameとしてフォーマットされたWindowsドメイン修飾ユーザー名です(例: oblix\jsmith)。
未指定: アサーション・サブジェクトのNameQualifierサブ要素の内容は指定されず、このデータの解析方法は個々の実装によって決まります。この値は、shareid-config.xml
ファイルでurn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
に設定されます。アサーションにはフォーマット値が使用されます。SAML仕様により、未指定フォーマットはフォーマット属性のURI値として定義されます。
その他: SAML仕様に定義されている事前定義値の1つではないフォーマット値です。その他のフォーマットの場合、SAMLパートナによって使用される任意のURI値を使用できます。たとえば、<http://company.com/saml/nameid-format/company-id>やurn:company.com:saml:nameid-format:company-idなどです。これらのフォーマットは、company.comによってそのURNパスが登録されていることを前提としています。このフィールドで指定する値は、shareid-config.xmlファイルに設定されます。
サブジェクトのユーザー属性: 値がサブジェクト・アサーション要素の値として使用されるローカルLDAPユーザー属性です。具体的には、このフィールドにより、アサーションのサブジェクト要素のNameIdentifier
サブ要素の値が決まります。サブジェクト要素は、ソース・ドメイン・ユーザーを識別します。このフィールドを空白にしておくと、ユーザーのディレクトリ・エントリのDNが使用されます。
スクロールダウンしてアサーション・プロファイルに属性を追加します。
次のデータを指定します。
アサーション属性: このフィールドは、ピアサイトからデータ・ストアのユーザー属性へアサーション属性をマップするために使用します。
データ・ストアの中の属性: ローカル・データ・ストア属性を入力します。
ネームスペース: 他のSAML対応の製品またはアプリケーションによってネームスペースまたはタイプが使用される場合、ネームスペースおよびタイプを指定します。
SSOアサーション内: この属性がSSOアサーションで使用されているかどうかを指定します。
「送信」をクリックし、アサーション・プロファイルを追加します。
Microsoft ADFS用としてOracle Identity Federationサーバーで非Oracle Identity Federationドメインを追加するには、次の手順を実行します。
Oracle Identity Federationにoif_admin
ユーザーとしてログインします。
「SAML 1.x/WSフェデレーション」→「ドメイン」にナビゲートします。
「非Oracle Identity Federationドメインの追加」ボタンをクリックします。
次の情報を追加します。
ドメイン名
ドメインの説明
「このドメインを有効化」ボックスを選択します。
要件に応じて「サポートされているプロトコル」を選択します。
発行者: 「前提条件」で収集したフェデレーション・サービスのURI
セクション「このドメインをソース/アイデンティティ・プロバイダとして構成します」までスクロールダウンします。
応答者URLを入力します。これは、「前提条件」で収集したフェデレーション・サービス・エンドポイントのURLです。Oracle Identity Federationでは、応答者URLに基づいてソースIDが生成されます。
注意: ソースIDを変更するには、応答者URLを変更し、「ソースID」フィールドの情報を削除し、「送信」をクリックし、ソースIDを再生成します。ソースIDは手動で再生成しないでください。 |
セクション「このドメインを宛先/サービスまたはリソース・プロバイダとして構成します。」までスクロールダウンします。
次の情報を入力します。
受信者URL: 「前提条件」で収集したフェデレーション・サービス・エンドポイントのURLです。宛先ドメインの受信者サービスによってアサーションが処理されます。
ソース・アサーション: 自ドメインからこの宛先にユーザーに関するアサーションを送信するときに使用するアサーション・プロファイルを示します。
リソース・レルムURI: 「前提条件」で収集したフェデレーション・サービスのURIです。
リソース・レルム・セキュア・トークン・サービス(STS) URL: 「前提条件」で収集したフェデレーション・サービス・エンドポイントのURLです。
「送信」をクリックし、構成を送信します。
ドメイン・リストを確認し、ドメインが作成されており、有効であることを確認します。
この項では、Oracle Identity Federationをアイデンティティ・プロバイダとして認識するためにサービス・プロバイダとしてのADFSで必要な構成について説明します。これには、ADFSの新しいアカウント・パートナの追加も含まれます。
アカウント・パートナを追加するには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「パートナーの組織」の順にダブルクリックし、「アカウント パートナー」を右クリックして、「新規」をポイントし、「アカウント パートナー」をクリックします。
「アカウント パートナー追加のウィザードの開始」ページが表示されます。
「次へ」をクリックします。
「ポリシー ファイルのインポート」ページが表示されます。
「いいえ」を選択し、「次へ」をクリックします。
「アカウント パートナーの詳細」ページが表示されます。
次の情報を入力します。
表示名: 「Account Partner」と入力します。
フェデレーション サービスの URI: 「前提条件」で収集したアイデンティティ・レルムURIを入力します。注意: この値は大/小文字が区別されます。
フェデレーション サービス エンドポイントの URL: 「前提条件」で収集したアイデンティティ・レルム・セキュア・トークン・サービス(STS)URLを入力します。
「次へ」をクリックします。
「アカウント パートナーの検証証明書」ページが表示されます。
「参照」をクリックします。「前提条件」で収集した証明書を選択し、「次へ」をクリックします。
「フェデレーションのシナリオ」ページが表示されます。
「フェデレーション Web SSO」を選択し、「次へ」をクリックします。
「アカウント パートナー ID 要求」ページが表示されます。
「電子メールの要求」チェック・ボックスを選択し、「次へ」をクリックします。
「受け取った電子メールのサフィックス」ページが表示されます。
接尾辞(この例では「company.com」)を入力し、「追加」をクリックします。
接尾辞が追加され、ページが再表示されます。
「次へ」をクリックします。
「このアカウント パートナーを有効にする」ページが表示されます。
「このアカウント パートナーを有効にする」ボックスを選択し、「次へ」をクリックします。
「アカウント パートナー追加のウィザードの完了」の完了ページが表示されます。「完了」をクリックします。
Active Directory Federation Services(ADFS)では、組織グループ要求は、グループまたはロール内のユーザーのメンバーシップを表します。組織カスタム要求は、従業員のID番号などのユーザーに関するカスタム情報を提供するためにフェデレーション・サービスによって使用されます。
この項では、カスタム要求を構成する方法と、要求変換を作成して組織カスタム要求にマップする方法について説明します。
主なタスクは次のとおりです。
要求対応アプリケーションのカスタム要求の作成
カスタム要求抽出の作成
入力方向のカスタム要求マッピングの作成
アプリケーションの電子メールID要求の有効化
アプリケーションの要求の有効化
カスタム要求を作成するには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「自分の組織」の順にダブルクリックし、「組織の要求」を右クリックして、「新規」をポイントし、「組織の要求」をクリックします。
「組織の要求の新規作成」ダイアログ・ボックスが表示されます。
次の情報を指定します。
要求の名前: 要求の名前を入力します(この例では「ADFS-OIF Test」)。
「カスタム要求」ボックスを選択します。
「OK」をクリックします。
ADFSでは、組織カスタム要求はユーザー属性にマップされます。
要求対応アプリケーションのカスタム要求をマップするためにLDAP属性を定義するには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「自分の組織」、「アカウント ストア」の順にダブルクリックし、「Active Directory」を右クリックして、「新規」をポイントし、「カスタム要求抽出」をクリックします。
「新しいカスタム要求抽出の作成」ダイアログ・ボックスが表示されます。
次の情報を指定します。
属性: アサーション属性をマップする名前を入力します(この例では「sAmAccountName」)。
この組織の要求にマップする: 以前に定義した要求を選択します(この例では「ADFS-OIF Test」)。
「OK」をクリックします。
リソース・フェデレーション・サービスは、入力方向のカスタム要求マッピングを使用して、アカウント・パートナが出力したカスタム要求を、認可に関する意思決定を行うためにリソース・パートナが使用できる要求にマップします。
要求変換のマッピングを作成するには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「パートナーの組織」、「アカウント パートナー」の順にダブルクリックし、「アカウント パートナー」を右クリックして、「新規」を選択し、「入力方向のカスタム要求のマッピング」をクリックします。
「新しい入力方向カスタム要求マッピングの作成」ダイアログ・ボックスが表示されます。
次の情報を指定します。
組織のカスタム要求: カスタム要求名を入力します(この例では「ADFS-OIF Test」)。
入力方向のカスタム要求名: 属性名を入力します(この例では「sAmAccountName」)。注意: この属性は、アサーション・プロファイルの作成に使用するために、宛先ドメイン管理者によってソース・ドメイン管理者に渡されます。
Active Directory Federation Services(ADFS)では、組織ID要求はアカウントまたはリソース・パートナとともに作成されます。これらは、リソース・パートナでは入力方向の要求、アカウント・パートナでは出力方向の要求となります。ID要求は、UPN、電子メールまたは共通名などのIDタイプを指定するときに有効になります。
要求の電子メールIDタイプを確立するには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「管理ツール」→「Active Directory フェデレーション サービス」にナビゲートします。
「フェデレーション サービス」、「信頼ポリシー」、「自分の組織」、「アカウント ストア」の順にダブルクリックし、「Active Directory」をクリックし、「電子メールID要求」を右クリックし、「プロパティ」をクリックします。
「要求抽出のプロパティ」ダイアログが表示されます。
LDAP属性を入力し、「有効」チェック・ボックスを選択します。
「OK」をクリックします。
Oracle Identity FederationでWS-FederationによるSSOが有効にされている場合、IdPからSSOリクエストを開始できます。次の形式のURLを使用します。
http://oif_host:oif_port/shareid/wsfederation/ObWSFedIdentitySTS/
パラメータは次のとおりです。
wa: 実行するアクションを指定する必須パラメータです。アクションを含めることにより、URIをオーバーロードして複数の機能を実行できます。注意: サインインの場合、この文字列は「wsignin1.0」である必要があります。
wtrealm: SPによって定義されたリクエスト・レルムURI
wctx: SPのドメインでアクセス対象となる保護されたリソースURL
例:
http://oif_host:oif_port /shareid/wsfederation/ObWSFedIdentitySTS/?wa=wsignin1.0 &wtrealm=Federation_Service_URI &wctx=https://protected_resource/claimapp/\https://protected_resource/claimapp/
ADFSでWS-FederationによるSSOが有効にされている場合、SPからSSOリクエストを開始できます。次の形式のURLを使用します。
https://adfs_host/adfs/ls/
パラメータは次のとおりです。
wa: この必須パラメータにより、実行するアクションを指定します。アクションを含めることにより、URIをオーバーロードして複数の機能を実行できます。サインインの場合、この文字列は「wsignin1.0」である必要があります。
wctx: SPのドメインでアクセス対象となる保護されたリソースURLです。
wreply: オプションのパラメータで、レスポンスの送信先のURLです。
例:
https://adfs_host /adfs/ls/?wa=wsignin1.0 &wreply=https://protected_resource/claimapp/ &wct=2007-02-16T14:41:01Z &wctx=https://protected_resource/claimapp/
この項では、パッチ・セット10.1.4.2で導入された、ログアウト中のエラー発生時に失敗をレポートしないオプションについて説明します。
Liberty 1.x / SAML 2.0のログアウト操作時に、Oracle Identity Federationは、ユーザーがフェデレーテッドSSO操作を実行するために使用したリモート・プロバイダと連絡を取り、そのユーザーのローカル・セッションを終了するよう指示します。
Oracle Identity Federationリリース10.1.4.0.1では、リモート・プロバイダがグローバル・ログアウト・プロトコルをサポートしていない場合、Oracle Identity Federationはユーザーのブラウザに内部サーバー・エラーをレポートしていました。
10.1.4.2.0パッチ・セット・リリースでは、管理者は、ログアウト・フローでエラーが発生したときにOracle Identity Federationがどのように反応するかを構成できます。管理者は次を選択できます。
ログアウト操作を正常に終了するようOracle Identity Federationに強制します。
ユーザーのブラウザにエラーをレポートします。
ログアウト時のOracle Identity Federationの動作を構成するには、次の手順を実行します。
$ORACLE_HOME/fed/conf/config.xml
ファイルを開きます。
FederationConfig
XML要素の場所を特定し、そのuseLocalConfig
属性をtrue
に設定します。
<FederationConfig useLocalConfig="true">
serverconfig
という名前のXML Config
要素の場所を確認し、slofailonerror
プロパティを探します。
<Config name="serverconfig"> ... <property name="slofailonerror">false</property> ... </Config>
プロパティの値を設定します。
true
: エラーが発生したときに、ユーザーのブラウザに失敗をレポートするようOracle Identity Federationに強制します。
false
: エラーが発生しても、ログアウト操作を正常に終了するようOracle Identity Federationに指示します。
ファイルを保存して終了します。
OC4J_FEDインスタンスを再起動します。
Oracle Identity Federationには、ユーザー・セッションをサインオフするログアウト機能が用意されています。ログアウトは次の方法によってトリガーされます。
リモート・プロバイダによってログアウト操作が呼び出されたときにWS-Fed/Liberty 1.x/SAML 2.0プロトコルを使用します。
ログアウト・フローを開始したOracle Identity Federationサーバー上でURLを呼び出します。これには、リモート・プロバイダとの対話によるユーザーのサインオフも含まれます。
/fed/user/logout
URLを介してOracle Identity Federationログアウト・サービスを呼び出す場合、ユーザーがリダイレクトされる戻り先URLパラメータを指定できます。
ログアウト操作の最後に、Oracle Identity Federationは必要に応じて、グローバル・ログアウト操作が成功したかどうかをレポートするためにサインオフ操作のステータスを示すことができます。場合によっては、リモート・サーバーでエラーが発生したり、1つのピア・プロバイダがグローバル・ログアウト・プロトコルをサポートしていないことがあるため、ステータスを把握していると役に立ちます。
デフォルトでは、Oracle Identity Federationでは、ログアウト・ステータスは戻されません。この機能を構成すると、ログアウト・ステータスを示すために問合せパラメータが戻り先URLに追加されます。
orafed_slostatus
問合せパラメータは、Liberty 1.x/SAML 2.0ログアウト・ステータスを示します。これには、次の値があります。
0: 成功
1: 失敗
orafed_slowsfed
問合せパラメータは、WS-Fedログアウト・ステータスを示します。これには、次の値があります。
0: 成功
1: 失敗
ログアウト・ステータス機能を構成するには、次の手順を実行します。
$ORACLE_HOME/fed/conf/config.xml
ファイルを開きます。
FederationConfig
XML要素の場所を特定し、そのuseLocalConfig
属性をtrue
に設定します。
<FederationConfig useLocalConfig="true">
serverconfig
という名前のXML Config
要素の場所を確認し、sloreturnstatus
プロパティを探します。
<Config name="serverconfig"> ... <property name="sloreturnstatus">false</property> ... </Config>
プロパティの値を設定します。
true
: Liberty 1.x/SAML 2.0プロトコルの使用時に戻り先URLにグローバル・ログアウトのステータスを追加するようOracle Identity Federationに指示します。
false
: Liberty 1.x/SAML 2.0プロトコルの使用時にグローバル・ログアウトのステータスを省略するようOracle Identity Federationに指示します。
ファイルを保存して終了します。
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml
ファイルを開きます。
useLocalConfig
属性をtrue
に設定し、再起動時に変更を強制的に持続させます。
<SHAREidConfiguration … useLocalConfig="true">
LogoutConfig
XML要素の場所を確認します。
SloReturnStatus
属性をtrue
またはfalse
に設定します。
true
: WS-Fedプロトコルの使用時に戻り先URLにグローバル・ログアウトのステータスを追加するようOracle Identity Federationに指示します。
false
: WS-Fedプロトコルの使用時にグローバル・ログアウトのステータスを省略するようOracle Identity Federationに指示します。
OC4J_FEDインスタンスを再起動します。
リリース10.1.4.2.0では、Oracle Identity Federationは、IdP側でSAML 2.0認証問合せプロトコル(AuthnQuery
)をサポートしています。このプロトコルを使用して、指定されたサブジェクトと認証局(IdP)間の以前の対話で行われた認証処理に関する文をリクエストするようIdPに問い合せます。
注意: このプロトコルは、問合せに指定される資格証明を使用した新しい認証のリクエストとして使用しないでください。 |
認証問合せに応答するようOracle Identity Federationを構成するには、次の手順を実行します。
$ORACLE_HOME/fed/conf/config.xml
ファイルを開きます。
FederationConfig
という名前のXML要素の場所を確認し、そのuseLocalConfig
属性をtrue
に設定します。
<FederationConfig useLocalConfig="true">
idpsaml20
という名前のXML Config
要素の場所を確認し、authnresponderenabled
プロパティを探します。
<Config name="idpsaml20"> ... <property name="authnresponderenabled">false</property> ... </Config>
Oracle Identity FederationがAuthnQuery
メッセージに応答するようにするには、プロパティの値をtrueに設定します。
ファイルを保存して終了します。
OC4J_FEDインスタンスを再起動します。
この方法でOracle Identity Federationを構成した後、SAML 2.0 AuthnQuery
メッセージ要素を使用して、IdPに対する認証問合せを実行できます(AuthnQuery
の詳細は、表B-1の[SAMLCore]を参照してください)。これに対して、IdPは、問合せ要件を満たす認証文とともにアサーションを戻します。
場合によっては、SPリクエスタは、1つ以上のアサーション(過去に交換されたもの)の一意の識別子を把握しており、これらのアサーションを新たに取得できます。
リリース10.1.4.2.0では、Oracle Identity Federationは、SAML 2.0アサーションIDリクエスト・プロトコル(AssertionIDRequest
)をサポートしています。これにより、SPは識別子別に既存のアサーションを問い合せることができます。
AssertionIDRequest
メッセージをサポートするようOracle Identity Federationを構成するには、次の手順を実行します。
$ORACLE_HOME/fed/conf/config.xml
ファイルを開きます。
FederationConfig
という名前のXML要素の場所を確認し、そのuseLocalConfig
属性をtrue
に設定します。
<FederationConfig useLocalConfig="true">
idpsaml20
という名前のXML Config
要素の場所を確認し、assertionidresponderenabled
プロパティを探します。
<Config name="idpsaml20"> ... <property name="assertionidresponderenabled">false</property> ... </Config>
プロパティの値をtrue
に変更し、アサーションIDリクエスト機能を有効にします。
ファイルを保存して終了します。
OC4J_FEDインスタンスを再起動します。
この方法でアサーションIDリクエスト機能を有効にした後、Oracle Identity Federationにより、SAML認証局によって生成された最新のアサーションがキャッシュされ、後でSPリクエスタが取得できるようになります。SAML 2.0 AssertionIDRequest
メッセージ要素を使用して、Oracle Identity Federationから古いアサーションをリクエストできます。これらのアサーションはResponse
メッセージで戻されます(AssertionIDRequest
の詳細は、表B-1の[SAMLCore]を参照してください)。
この項では、eTrust SiteMinderを使用したOracle Identity Federationの構成に関する次のトピックについて説明します。
Oracle Identity FederationサーバーをeTrust SiteMinderと統合する場合、SiteMinderポリシー・サーバーでポリシー・オブジェクトを作成する必要があります。これらのオブジェクを作成する方法は、次のとおりです。
SiteMinderポリシー・マシン上でPerlスクリプトを実行します。
Oracle Identity Federationの起動時にオブジェクトが自動的に作成されるようにします。
次のポリシー・オブジェクトが作成されます。
AgentGroup
AgentGroupにより、Oracle Identity Federationクラスタによって定義されたWebエージェントが再度グループ化されます(ロード・バランシング/HAシナリオ内など)。
グループのデフォルト名はOracleFederationですが、PerlスクリプトやOracle Identity Federation構成ファイル内で変更できます。
Webエージェント
Oracle Identity Federationの物理サーバーに固有のWebエージェントを使用して実行時にSiteMinderポリシー・サーバーと対話することにより、ユーザーを認証し、ユーザー・セッションを作成できます。
このエージェントは、フェデレーションAgentGroupのメンバーであり、その名前はSMBridgeAgent.
OIF_INSTANCE_NAME
として定義されます。OIF_INSTANCE_NAME
は、Oracle Identity Federationが実行されているOracle Application Serverのインスタンス名です(このインスタンス名はEnterprise Managerコンソール上にあり、ようこそページの左上に表示されます。例: アプリケーション・サーバー: orclfed.stadm04.us.oracle.com)。
Perlスクリプトを使用してポリシー・オブジェクトを作成する場合、実行されているアプリケーション・サーバーのインスタンス名が反映されるようスクリプトを編集する必要があります。
注意: アプリケーション・サーバーのインスタンス名は、ロード・バランシング/HAシナリオであっても、すべてのデプロイメントにわたって一意です。 |
その他のポリシー・オブジェクト
Oracle Identity Federationでは、様々なポリシー・オブジェクトを作成および使用して、ユーザーを認証したり、eTrust SiteMinderセッションをSPモードで作成します。
これらのオブジェクトには、接頭辞が付いた名前があります。これらを構成することにより、複数のOracle Identity Federationの論理サーバーを特定のeTrust SiteMinderサーバーと統合できるようになります。デフォルトでは、この接頭辞名はOracleFederationであり、様々なOracle Identity Federationの論理インスタンス/クラスタがeTrust SiteMinderサーバーと対話しないかぎり、(ロード・バランシング/HAシナリオであっても)変更しないでください。特定の接頭辞を使用する必要がある場合、PerlスクリプトおよびOracle Identity Federation構成ファイルを編集する必要があります。
Oracle Identity Federationでは、認証手順で使用されるレルムが定義されます。このレルムの詳細は、次のとおりです。
PREFIX
_Login
という名前です。
前述のAgentGroupにリンクされています。
/
PREFIX
/Login
リソースを保護しています。
PREFIX
_Login
という名前の認証スキームがあります。
PREFIX
_Login
という名前のルールが関連付けられています。
Oracle Identity Federationでは、eTrust SiteMinderユーザー・セッションをSPモードで作成するために使用される第2レルムが定義されます。このレルムの詳細は、次のとおりです。
PREFIX
_LoginNoPwd
という名前です。
前述のAgentGroupにリンクされています。
/
PREFIX
/LoginNoPwd
リソースを保護しています。
PREFIX
_LoginNoPwd
という名前の認証スキームがあります。
最後に、Oracle Identity Federationでは、実行時にeTrust SiteMinderサーバーからユーザー属性を取得するために使用するレスポンス・オブジェクトが定義されます。このオブジェクトは、PREFIX
_UserAttributes
という名前です。
Oracle Identity FederationをeTrust SiteMinderサーバーと統合する場合、ポリシー・オブジェクトは自動的に作成したり、Perlスクリプトを使用して作成できます。
スクリプトを使用したポリシー・オブジェクトの作成
createSMConfig.pl
スクリプトを開発および実装するには、次の手順を実行します。
$ORACLE_HOME/fed/setup/sm/createSMConfig.pl
ファイルを開きます。
次の変数を設定します。
$adminName
: eTrust SiteMinder管理者IDです。
$adminPwd
: eTrust SiteMinder管理者パスワードです。
$domain_name
: ポリシー・オブジェクトを含むeTrust SiteMinderです。
$userdir_name
: ドメインのユーザー・ディレクトリをeTrust SiteMinderが構成した名前です。
$ip_address
: Oracle Identity FederationサーバーがインストールされているマシンのIPアドレスです。
$shared_secret
: : エージェントとポリシー・サーバーに共有される秘密の文字列です。
$oif_instance_name
: Oracle Identity Federationが実行されているOracle Application Serverのインスタンス名です。
$prefix
: Oracle Identity Federationポリシー・オブジェクトが使用する接頭辞です。デフォルトではOracleFederation
です。
eTrust SiteMinder管理者が、AgentGroupを作成し、Perlスクリプトによって作成されたすべてのWebエージェントをこのエージェント・グループに追加します。サーバー・インスタンスごとに1つのエージェントが追加されます。
管理者は、新しく作成された2つのレルムを編集し、Oracle Identity Federation WebエージェントのかわりにAgentGroupを参照する必要があります。
スクリプトの変更を保存します。
注意: スクリプトを使用してポリシー・オブジェクトを作成し、AgentGroup名および接頭辞をデフォルト値から変更する場合、Oracle Identity Federation構成を更新する必要があります。詳細は、「ポリシー・オブジェクトの自動作成」を参照してください。 |
ポリシー・オブジェクトの自動作成
次の手順を実行します。
「ユーザー・データ・ストアの編集」に記載されている手順に従い、eTrust SiteMinder構成情報を設定します。
保存します。
AgentGroup名または接頭辞を変更する必要がある場合、残りの手順を実行します。必要がない場合、OC4J_FEDインスタンスを再起動します(最後の手順)。
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml
ファイルを開きます。
useLocalConfig
属性をtrue
に設定し、再起動時に変更を強制的に持続させます。
<SHAREidConfiguration … useLocalConfig="true">
Name
属性がSM
であるIdMBridge XML要素の場所を確認します。
AgentGroupName
という名前のXML属性を追加し、使用するAgentGroupの名前を指定します。
<IdMBridge Name="SM" ... AgentGroupName="OIFGroup" ...></IdMBridge>
PrefixName
という名前のXML属性を追加し、使用する接頭辞を指定します。
<IdMBridge Name="SM" ... PrefixName="OIFPrefix" ...></IdMBridge>
ファイルを保存します。
OC4J_FEDを再起動します。
Oracle Identity Federationは、起動するたびに様々なチェックおよび操作を実行するよう構成できます。
ポリシー・オブジェクトの作成(欠落している場合)
eTrust SiteMinderポリシー・サーバーでポリシー・オブジェクトが存在するかどうか確認し、欠落している場合に作成するには、次の手順を実行します。
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml
ファイルを開きます。
useLocalConfig
属性をtrue
に設定し、再起動時に変更を強制的に持続させます。
<SHAREidConfiguration … useLocalConfig="true">
Name
属性がSM
であるIdMBridge XML要素の場所を確認します。
SkipInitialize
という名前のXML属性をfalse
に設定し、Oracle Identity Federationがポリシー・オブジェクトを確認する必要があることを示します。
<IdMBridge Name="SM" ... SkipInitialize="false" ...></IdMBridge>
AllowSMCreation
という名前のXML属性をtrue
に設定し、ポリシー・オブジェクトが欠落している場合は作成できることを示します。
<IdMBridge Name="SM" ... AllowSMCreation="true" ...></IdMBridge>
OC4J_FEDを保存および再起動します。
ポリシー・オブジェクトが欠落しているかどうかの確認
eTrust SiteMinderポリシー・サーバーでポリシー・オブジェクトが存在するかどうか確認し、欠落している場合にエラーをレポートする(が、オブジェクトは作成しない)には、次の手順を実行します。
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml
ファイルを開きます。
useLocalConfig
属性をtrue
に設定し、再起動時に変更を強制的に持続させます。
<SHAREidConfiguration … useLocalConfig="true">
Name
属性がSM
であるIdMBridge XML要素の場所を確認します。
SkipInitialize
という名前のXML属性をfalse
に設定し、Oracle Identity Federationがポリシー・オブジェクトを確認する必要があることを示します。
<IdMBridge Name="SM" ... SkipInitialize="false" ...></IdMBridge>
AllowSMCreation
という名前のXML属性をfalse
に設定し、ポリシー・オブジェクトが欠落している場合はエラーをレポートする必要があることを示します。
<IdMBridge Name="SM" ... AllowSMCreation="false" ...></IdMBridge>
OC4J_FEDを保存および再起動します。
ポリシー・オブジェクトの検証および作成の省略
Oracle Identity Federationポリシー・オブジェクトの検証および作成を省略するには、次の手順を実行します。
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xml
ファイルを開きます。
useLocalConfig
属性をtrue
に設定し、再起動時に変更を強制的に持続させます。
<SHAREidConfiguration … useLocalConfig="true">
Name
属性がSM
であるIdMBridge XML要素の場所を確認します。
SkipInitialize
という名前のXML属性をtrue
に設定し、Oracle Identity Federationがポリシー・オブジェクトを確認する必要がないことを示します。
<IdMBridge Name="SM" ... SkipInitialize="true" ...></IdMBridge>
OC4J_FEDを保存および再起動します。
CA SiteMinderサーバーによって使用されているものとは異なるユーザー・リポジトリを使用するようOracle Identity Federationサーバーを構成できます。たとえば、CA SiteMinderポリシー・サーバーではLDAPサーバーをユーザー・リポジトリとして使用できるが、Oracle Identity FederationではRDBMSを使用するよう構成できます。
「ユーザー・データ・ストアの編集」に記載されている手順に従い、CA SiteMinder構成情報の設定を開始します。
次に、次の手順を実行し、ユーザー・データ・ストアがCA SiteMinderによって使用されているものとは異なることをOracle Identity Federationに示します。
$ORACLE_HOME/fed/shareid/oblix/config/shareid-config.xmlファイルを開きます。
useLocalConfig
属性をtrue
に設定し、再起動時に変更を強制的に持続させます。
<SHAREidConfiguration … useLocalConfig="true">
Name
属性がSM
であるIdMBridge XML要素の場所を確認します。
SecondaryBridgeEqualToSMUserDir
という名前のXML属性を次のように設定します。
false
: ユーザー・データ・ストアがCA SiteMinderポリシー・サーバーによって使用されているものとは異なることを示します。
true
: ユーザー・データ・ストアが両方とも同じであることを示します。
例:
<IdMBridge Name="SM" ... SecondaryBridgeEqualToSMUserDir="false" ...></IdMBridge>
OC4J_FEDを保存および再起動します。