Oracle® Fusion Middleware Oracle WebCenter Portal管理者ガイド 11g リリース1(11.1.1.6.0) B72085-01 |
|
前 |
次 |
この章では、WebCenter Portalアプリケーションで利用できるシングル・サインオン(SSO)ソリューションと各ソリューションの構成方法について説明します。
この章の内容は次のとおりです。
対象読者
この章の内容は、Fusion Middleware管理者(Oracle WebLogic Server管理コンソールを使用してAdmin
ロールを付与されたユーザー)を対象としています。Monitor
またはOperator
ロールを持つユーザーは、セキュリティ情報を表示できますが変更することはできません。第1.8項「管理操作、ロールおよびツールの理解」も参照してください。
いくつかのソリューションを使用して、WebCenter Portalアプリケーション(SpacesおよびFrameworkアプリケーション)向けにシングル・サインオンを実装できます。この項では、その利点と推奨アプリケーションを説明します。
オラクル社のエンタープライズ・クラスのアイデンティティ管理およびセキュリティ製品スイートの一部であるOracle Access Manager(OAM)は、SpacesおよびFrameworkアプリケーション用のいくつかのシングル・サインオン・オプションを含む広範なアイデンティティ管理およびセキュリティ機能を提供します。OAM(特にOAM 11g)は、Oracle WebCenter Portal 11gのインストールに推奨されるシングル・サインオン・ソリューションです。
Oracle 10gインフラストラクチャに投資済のデプロイメント環境で、Oracle Application Server Single Sign-On(OSSO)サーバーがプライマリSSOソリューションとして使用されている場合は、OSSOを使用してシングル・サインオンを提供するようにWebCenter Portal 11gを構成することもできます。
Oracle Access ManagerやOracle SSOのようなエンタープライズ・クラスのシングル・サインオン・インフラストラクチャを装備していない本番以外の開発環境で、Spaces、ディスカッションのような関連するWebアプリケーションおよびワークリスト内でのみシングル・サインオン機能を提供する必要がある場合は、SAMLベースのSSOソリューションを構成できます。他のエンタープライズ・アプリケーションにもシングル・サインオンを提供する必要がある場合は、このソリューションはお薦めできません。
Active Directoryのユーザー・アカウントによってMicrosoftドメイン・コントローラを使用して認証を行うMicrosoftデスクトップ・ログインを使用している場合は、Microsoftのクライアントに対するSSOの構成も検討できます。
Oracle Access Manager(OAM)は、柔軟で拡張可能な認証と認可のほか、監査サービスを提供します。この項では、WebLogicサーバー側およびSSOに参加するパートナ・アプリケーションとしてのWebCenter Portalアプリケーションの構成方法を含め、OAMシングル・サインオン認証のためにSpacesおよびFrameworkアプリケーションを構成する方法を説明します。第32.4項「OAMに対するFrameworkアプリケーションおよびポートレット・プロデューサ・アプリケーションの構成」で説明されているように、Frameworkアプリケーションの場合は、追加の構成がいくつか必要になることに注意してください。
次の項で、OAM 11gおよび10gのインストールおよび構成手順を示します。
図31-1は、WebCenter Portalアプリケーション用にOracle Access Managerを使用してシングル・サインオンをセットアップするために必要なコンポーネントとトポロジを示しています。
OAMは次のコンポーネントから構成されます。
アクセス・サーバー - 認証、認可およびアクセス・ゲートの監査サービスを提供するスタンドアロン・サーバー。OAMには1台のアクセス・サーバーがセットアップされます。これはOAMのインストール自体の一環として行われます。
WebGate - Webリソース(HTTP)リクエストをインターセプトして認証と認可のためにアクセス・サーバーに転送する、すぐに利用可能なプラグイン。
IDアサーション・プロバイダ(IAP) - 境界認証によって設定されるヘッダー情報に基づいてユーザーのアイデンティティをアサートするセキュリティ・プロバイダの種類。OAMの統合により、OAM IAPとして構成できるOAM IDアサータが提供されます。OAM IDアサータは、認証またはアイデンティティ・アサーションに使用できます。OAM SSOの統合では、プロバイダの「共通」設定の「アクティブなタイプ」でobSSOCookie
を選択して、アイデンティティ・アサーション・プロバイダ(IAP)としてOAM IDアサータを構成することが必要です。
OAMシングル・サインオン・プロセスのフロー
図31-2は、OAMのシングル・サインオン・プロセスのフローを示しています。
OAMエージェントによるSSOログイン処理
ユーザーがリソースをリクエストします。
ポリシー評価のためにWebGateがOAMにリクエストを転送します。
OAMが次を行います。
SSO Cookieの有無をチェックします。
ポリシーをチェックして、リソースが保護されているかどうか、保護されている場合はどのような方法で保護されているかを判断します。
OAMサーバーが判定をログして返します。
WebGateは、次のように応答します。
無保護リソース: リソースはユーザーに提供されます。
保護リソース:
リクエストは資格証明コレクタにリダイレクトされます。
認証ポリシーに基づいてログイン・フォームが提供されます。
認証処理が開始します。
ユーザーが資格証明を送信します。
OAMが資格証明を検証します。
OAMがセッションを開始して、次のホストベースのCookieを作成します。
パートナ当たり1つ: 認証に成功した後でOAMサーバーから受信される認証トークンを使用して、11g WebGateがOAMAuthnCookie
を設定します(10g WebGateの場合はObSSOCookie
)。
注意: セッションには有効なCookieが必要です。
OAMサーバーに1つ: OAM_ID
OAMが成功または失敗をログします。
OAM資格証明コレクタがWebGateにリダイレクトし、認可処理が開始します。
ポリシーをルックアップして、それらをユーザーのアイデンティティと比較し、ユーザーの認可レベルを判定するようにWebGateがOAMに指示します。
OAMがポリシーに関する判定をログして、セッションCookieをチェックします。
OAMサーバーが認可ポリシーを評価して、結果をキャッシュします。
OAMサーバーが判定をログして返します。
WebGateは、次のように応答します。
認可ポリシーでアクセスが許可されている場合は、次に示すように、リクエストはmod_wl
にリダイレクトされ、さらにSpacesアプリケーションを実行中のWLSサーバーにリダイレクトされて、そこから希望のコンテンツやアプリケーションがユーザーに提供されます。
WebGate→mod_wl→Spaces(ディスカッションなど)→コンテンツが認証されたユーザーに提供されます
認可ポリシーでアクセスが拒否されている場合は、管理者が決定した別のURLにユーザーはリダイレクトされます。
この項のフロー・チャート(図31-3)と表(表31-1)は、OAMを使用してWebCenter Portalのシングル・サインオンを構成する際の前提条件と必要なタスクの概要を示しています。
表31-1は、OAMを使用してWebCenter Portalのシングル・サインオンを構成するためのタスクとサブタスクを示しています。
表31-1 OAMを使用したWebCenter Portalのシングル・サインオンの構成
担当者 | タスク | サブタスク | ノート |
---|---|---|---|
管理者 |
1. OAMのインストールと構成 |
OAM 10gまたは11gのインストールと構成 |
|
2. OAM用のWebLogicドメインの構成 |
2.a OIDオーセンティケータの構成 |
||
2.b OAMアイデンティティ・アサータの構成 |
|||
2.c デフォルト・オーセンティケータとプロバイダの順序の構成 |
|||
2.d OAM SSOプロバイダの追加 |
|||
3. OHSのインストールと構成 |
|||
4. 必要に応じた追加構成の実行 |
4.a SSO用のSpacesの構成 |
||
4.b SSO用のディスカッション・サーバーの構成 |
|||
4.c SSO用のワークリスト・サービスの構成 |
|||
4.d 外部リーダーを使用したRSSフィード用のOAMの構成 |
|||
4.e WLS管理コンソールとEnterprise Managerの構成(OAM 11gまたはOAM 10g用) |
|||
4.f OAM用のContent Serverの構成 |
|||
4.g 接続フィルタを使用したアクセスの制限 |
|||
5. OAMインストールのテスト |
この項では、OAM 11gまたはOAM 10gのインストールおよび構成方法と、WebCenter Portalのインストールに推奨されるシングル・サインオン・ソリューションを説明します。
この項の内容は次のとおりです。
この項ではOAM 11gのインストールおよび構成方法について説明し、次の内容を含みます。
Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOracle Identity Management 11gソフトウェアのインストールに関する項の説明に従って、Oracle Access Manager(OAM)をインストールします。理想的なシナリオは、OAMとシングル・サインオンに参加するすべてのアプリケーションが同じアイデンティティ・ストアを共有することです。デフォルトでは、OAMは組込みのLDAPアイデンティティ・ストアを使用します。
OIDのような外部アイデンティティ・ストアを使用するようにOAMを構成するには、Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドの新規アイデンティティ・ストアの登録に関する項を参照してください。この項には、デフォルトまたはシステム・ストアとして構成された外部アイデンティティ・ストアを設定し、このストアをポイントするように1つ以上の認証モジュールを構成するためのポインタが示されています。デフォルトでは、OAMに構成されたWebCenterポリシーは、OAMに指定されたデフォルト認証スキーム(通常はフォームベースの認証スキームLDAPScheme
)を使用します。デフォルト・スキームを使用する場合は、スキームが使用する認証モジュールは、WebCenterのインストールと同じアイデンティティ・ストアをポイントする必要があります。オプションとして、デフォルト以外の認証スキームを構成することができます。この場合も、WebCenterが使用するアイデンティティ・ストアをこれが確実にポイントするようにしてください。それから、Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOracle Access Manager(OAM)の構成に関する項の説明に従って、WebLogic管理ドメインでOracle Access Managerを構成します。
Oracle HTTP Server (OHS)がインストールされていない場合、第31.2.5項「Oracle HTTP Serverのインストールと構成」の説明に従ってOHS (11.1.1.4.0)をインストールします。
既存のインストールがある場合は、Oracle Fusion Middlewareパッチ適用ガイドの最新のOracle Fusion Middlewareパッチ・セットの適用に関する項の説明に従ってパッチを適用して、OHS (11.1.1.4.0)にする必要があります。
OHSのインストールまたはパッチ適用が終了したら、第31.2.3.1.3項「Web層でのWebGateのインストール」の説明に従ってWebGateをインストールします。
この項では、OHS WebGateのインストールおよび構成方法について説明します。
注意: OHS WebGateのインストール中は必ずOracle HTTP Serverを停止し、第31.2.3.1.4項「WebGateエージェントの登録」の説明に従ってWebGateエージェントを登録した後でのみ再起動してください。 |
LinuxおよびSolarisオペレーティング・システムの場合は、Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのサードパーティ製GCCライブラリのインストール(LinuxおよびSolarisオペレーティング・システムのみ)に関する項の説明に従って、サードパーティ製のGCCライブラリをダウンロードして、OHSのインストール先と同じ場所にインストールします。
Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOracle Access Manager用のOracle HTTP Server 11g WebGateのインストールに関する項の説明に従って、WebGateをインストールします。OHSのインストール時に指定したものと同じミドルウェア・ホームを使用します。インストール時に、前の手順でダウンロードしたGCCライブラリを含むディレクトリをポイントする必要があることに注意してください。
Oracle Access Manager用のOracle HTTP Server 11g WebGateをインストールしたら、WebGate用のOracleホームの下にある次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:
<Webgate_Home>/webgate/ohs/tools/deployWebGate
Windowsオペレーティング・システムの場合:
<Webgate_Home>\webgate\ohs\tools\deployWebGate
コマンド・ラインで次のコマンドを実行して、必要なエージェントの部分をWebgate_Home
ディレクトリからWebGateインスタンスの場所にコピーします。
UNIXオペレーティング・システムの場合:
./deployWebGateInstance.sh -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home>
Windowsオペレーティング・システムの場合:
deployWebGateInstance.bat -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home>
<Webgate_Oracle_Home>
には、次の例のように、Oracle HTTP Server WebGateがインストールされており、かつWebGateのOracleホームとして定義されているディレクトリを指定します。
<MW_HOME>/Oracle_OAMWebGate1
<Webgate_Instance_Directory>
には、次の例のように、WebGateインスタンス・ホームの場所を指定します(これはOracle HTTP Serverのインスタンス・ホームと同じであることが必要です)。
<MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1
Oracle HTTP Serverのインスタンス・ホームは、Oracle HTTP Serverの構成後に作成されることに注意してください。この構成は、Oracle HTTP Server 11.1.1.4.0のインストールまたはパッチ適用後に実行する必要があります。
次のコマンドを実行して、LD_LIBRARY_PATH
変数に<Oracle_Home_for_Oracle_HTTP_Server>
/lib
が含まれていることを確認します。
UNIXオペレーティング・システムの場合(シェルにより異なる):
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<Oracle_Home_for_Oracle_HTTP_Server>/lib
Windowsオペレーティング・システムの場合:
<Webgate_Installation_Directory>
\webgate\ohs\lib
および<Oracle_Home_for_Oracle_HTTP_Server>
\bin
の場所をPATH
環境変数に追加します。PATH環境変数のエントリの末尾に、セミコロン(;)に続けてこのパスを追加します。
現在の作業ディレクトリから1つ上位に移動します。
UNIXオペレーティング・システムの場合は、次に移動します。
<Webgate_Home>/webgate/ohs/tools/setup/InstallTools
Windowsオペレーティング・システムの場合は、次に移動します。
<Webgate_Home>\webgate\ohs\tools\EditHttpConf
コマンド・ラインで次のコマンドを実行して、apache_webgate.template
をWebgate_Home
ディレクトリからWebGateインスタンスの場所にコピーします(webgate.conf
にその名前を変更します)。さらに、httpd.conf
ファイルを更新し、1行を追加してwebgate.conf
ファイルの名前を含めます。
UNIXオペレーティング・システムの場合:
./EditHttpConf -w <Webgate_Instance_Directory> [-oh <Webgate_Oracle_Home>] [-o <output_file>]
Windowsオペレーティング・システムの場合:
EditHttpConf.exe -w<Webgate_Instance_Directory>
[-oh<Webgate_Oracle_Home>
] [-o<output_file>
]
注意:
|
<Webgate_Oracle_Home>
には、次の例のように、Oracle HTTP Server WebGateがインストールされており、かつWebGateのOracleホームとして定義されているディレクトリを指定します。
<MW_HOME>/Oracle_OAMWebGate1
<Webgate_Instance_Directory>
には、次の例のように、WebGateインスタンス・ホームの場所を指定します(これはOHSのインスタンス・ホームと同じであることが必要です)。
<MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1
Web層にWebGateをインストールしたら、WebGateエージェントの登録も行う必要があります。次の手順では、OAMのインストールで構成されたデフォルト認証スキーム(通常はフォームベースの認証スキームLDAPScheme
)を使用する保護されたポリシーを自動的に作成します。WebCenter Portalのシングル・サインオンのログイン・ページをカスタマイズしたい場合、または他の認証スキームでWebCenter Portalリソースを保護したい場合は、OAMコンソールを使用してそれを変更してください(詳細は、Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドの認証スキームの管理に関する項を参照)。
注意: 環境でWebCenter Portalとともに他のアプリケーションを使用しており、これらのアプリケーションにシングル・サインオンが必要な場合は、これらのアプリケーションで使用される認証スキームが同じであるか、少なくとも同じレベルで、同じアイデンティティ・ストアをポイントしていることが必要です。 |
WebGateエージェントの登録に関する詳細は、Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOracle Access Manager用の新しいOracle HTTP Server 11g WebGateエージェント・スタート・ガイドに関する項も参照してください。
次の手順に従って、インバンド・モードでoamreg
ツールを使用して、OAMがインストールされているマシン上でWebGateエージェントを登録します。
ディレクトリを<RREG_Home>
/input
に変更します。
このWebCenter Portalのインストールから$WEBCENTER_HOME/webcenter/scripts/webcenter.oam.conf
を上書きします。
SOAとContent Serverのインストールから、$SOA_HOME/soa/prov/soa.oam.conf
および$WC_CONTENT_ORACLE_HOME/common/security/oam.conf
をそれぞれ上書きします。
oamreg
ツールのパラメータ・ファイルとして機能するWebCenterOAM11gRequest.xml
という名前の新しいファイルを作成します。
次の例で、$$webtier..$$
内の内容は該当するWeb層ホストとポートIDで置き換え、$$oam...$$
はOAMホストと管理サーバー・ポートで置き換えます。
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved. NAME: OAM11GRequest_short.xml - Template for OAM 11G Agent Registration Request file (Shorter version - Only mandatory values - Default values will be used for all other fields) DESCRIPTION: Modify with specific values and pass file as input to the tool. --> <OAM11GRegRequest> <serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress> <hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier> <agentName>$$webtierhost$$_webcenter</agentName> <logOutUrls> <url>/oamsso/logout.html</url> </logOutUrls> </OAM11GRegRequest>
ディレクトリを<RREG_Home>
に変更します。
次のコマンドを実行します。
<RREG_Home>/bin/oamreg.sh inband input/WebCenterOAM11gRequest.xml
エージェントの資格証明を入力するように求められたら、OAM管理者の資格証明を入力します。
WebGateのパスワードを入力します。
URIファイルをインポートするかどうか尋ねられたら、yes
と入力します。以前コピーした<RREG_HOME>/input/webcenter.oam.conf
ファイルのフルパスを指定します。
登録が成功したことを示す次のような出力が表示されます。
---------------------------------------- Request summary: OAM11G Agent Name:example_webcenter URL String:example_webcenter Registering in Mode:inband Your registration request is being been sent to the Admin server at: http://example.com:7001 ---------------------------------------- Inband registration process completed successfully! Output artifacts are created in the output folder.
生成されたファイルとアーティファクト(ObAccessClient.xml
とcwallet.sso
)を<RREG_Home>
/output/
$$webtierhost$$
_webcenter
からWebGateインスタンスの構成ディレクトリ(<Webgate_Instance_Directory>/webgate/config
)にコピーします。次の例のように、<Webgate_Instance_Directory>
は、OHSのインスタンス・ホームと一致する必要があることに注意してください。
<MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config
ディレクトリを<RREG_Home>
/input
に変更します。
SOAまたはWebCenter Content Serverがインストールされている場合は、次の手順に従います。
次の例に示されているように、WebCenterOAM11gPolicyUpdate.xml
というポリシー更新ファイルを作成します。以前に行ったように、$$webtier..$$
内の内容はWeb層ホストとポートIDに、$$oam...$$
はOAMホストと管理サーバー・ポートに置き換えます。
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. NAME: UpdatePolicyRequest.xml - Template for updating application domain and/or policies without changes to any agent profile DESCRIPTION: Modify with specific values and pass file as input to the tool --> <PolicyRegRequest> <serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress> <hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier> <applicationDomainName>$$webtierhost$$_webcenter</applicationDomainName> </PolicyRegRequest>
次のコマンドを実行します。
<RREG_Home>/bin/oamreg.sh policyUpdate input/WebCenterOAM11gPolicyUpdate.xml
入力を要求されたら、OAMの資格証明を入力します。URIファイルをインポートするかどうか尋ねられたら、yes
と入力して、<RREG_HOME>/input/soa.oam.conf
を指定します。
ポリシーはSOAリソースを使用して更新されます。
再度policyUpdate
コマンドを実行します。今回は<RREG_HOME>/input/oam.conf
を指定して、Content Serverのリソースを使用してポリシーを更新します。これでポリシーに、WebCenter Portal、SOAおよびContent Serverのアーティファクトが含まれます。
OAMコンソールから、次のアーティファクトを表示できるはずです。
$$webtierhost$$_webcenter
という名前の11g WebGateエージェント
同じ名前の11gホスト識別子
認証ポリシーと認可ポリシー(保護されたポリシーとパブリック・ポリシーを含む)を含む同じ名前のアプリケーション・ドメイン
「アプリケーション・ドメイン」→$$webtierhost$$_webcenter→「認証ポリシー」に移動します。次のポリシーを表示できるはずです。
除外スキーム
保護されたリソース・ポリシー
パブリック・リソース・ポリシー
WebCenter RESTポリシー
WebCenter RESTポリシーを開いて、認証スキームがBasicSessionlessScheme
またはBasicScheme
に設定されていることを確認します。
「リソース」タブを開いて、認証ポリシーがExclusion Scheme
に設定されているリソースを検索します。次のリソースが表示されるはずです。
/rsscrawl*
/rsscrawl/.../*
/sesUserAuth*
/sesUserAuth/.../*
/services-producer/portlets*
/services-producer/portlets/.../*
/wsrp-tools/portlets
/wsrp-tools/portlets/.../*
検索結果の/rsscrawl*
リソースを選択して、「編集」をクリックします。
保護レベルをProtected
からExcluded
に変更して、「適用」をクリックします。リソースの認証ポリシーと認可ポリシーが削除されることに注意してください。
「リソース」タブを閉じて、残りのExclusion Scheme
リソースについてこの手順を繰り返します。
この時点で認証ポリシーがExclusion Scheme
に設定されているリソースを検索すると、結果はゼロになります。
OHSを再起動します。
Web層と関連するコンポーネントをインストールおよび構成したら、第31.2.4項「OAM用のWebLogicドメインの構成」の説明に従ってポリシー・マネージャを構成し、第31.2.6項「追加のシングル・サインオン構成」の説明に従って適用される追加のサービスとコンポーネントの構成を実行します。
この項では、OAM 10gのインストールおよび構成方法について説明し、次の内容を含みます。
まだOracle Access Manager (OAM) 10gをインストールしていない場合は、Oracle Access Managerインストレーション・ガイドの説明に従ってOAM 10gをインストールします。
Oracle HTTP Server (OHS)がインストールされていない場合、第31.2.5項「Oracle HTTP Serverのインストールと構成」の説明に従ってOHS (11.1.1.4.0)をインストールします。
既存のインストールがある場合は、Oracle Fusion Middlewareパッチ適用ガイドの最新のOracle Fusion Middlewareパッチ・セットの適用に関する項の説明に従ってパッチを適用して、OHS (11.1.1.4.0)にする必要があります。
OHSのインストールまたはパッチ適用を行ったら、第31.2.3.2.3項「WebCenter Portalポリシー・ドメインの構成」の説明に従ってWebGateをインストールします。
この手順では、Oracle WebCenterをインストール済であることを前提としています(WebCenter Portalを参照)。デフォルトでは、Oracle WebCenter Portalのインストールによって、1台の管理サーバーと4台の管理対象サーバー(WC_Spaces
、WC_Collaboration
、WC_Utilities
およびWC_Portlet
)を含むWebLogic Serverドメインが作成されます。
使用するアクセス・サーバーを決定します。
Access Managerにログオンします。
「アクセス・システム・コンソール」をクリックします。
「アクセス・システム構成」タブを開きます。
「アクセス・サーバー構成」をクリックして、すべてのアクセス・サーバーのリストを表示します。
リスト内のアクセス・サーバーをクリックして、サーバーの詳細を表示します。
ホストの名前とポートは、それぞれ、スクリプトのoam_aaa_host
およびoam_aaa_port
パラメータに必要な値です。
OAM 10gのインストールにOraDefaultExclusionAuthNScheme
があることをチェックします。ない場合は、次のようにOraDefaultExclusionAuthNSchemeを作成します。
OAMアクセス・システム・コンソールを開きます。
「認証管理」をクリックします。
「追加」をクリックします。
「名前」フィールドにOraDefaultExclusionAuthNScheme
と指定します。
「説明」フィールドにTo exclude resources from being protected by OAM
と入力します。
「レベル」フィールドに0
と入力します。
「チャレンジ・メソッド」フィールドにNone
と指定します。
「チャレンジ・パラメータ」フィールドにunprotected:true
を追加します。
「保存」をクリックします。
この認証スキームの「プラグイン」タブを開いて「変更」をクリックします。
ドロップダウン・リストからcredential_mapping
を選択します。
次のように値を指定します。
obMappingBase="dc=us,dc=oracle,dc=com",obMappingFilter="(uid=OblixAnonymous)"
この値がOraDefaultAnonAuthNScheme
の対応するフィールドと一致することを確認してください。
「保存」をクリックします。
再度「一般」タブを開いて、「変更」をクリックします。
「有効」についてYes
をチェックします。
「保存」をクリックします。
次のコマンドを実行します。
oamcfgtool.jar
は、WebCenter PortalインストールのORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
にあります。太字の値は、WebCenter PortalおよびOAMインスタンスの設定に基づいて指定する必要があります。
java -jar ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar mode=CREATE app_domain=<your_domain_name> uris_file=WEBCENTER_HOME/webcenter/scripts/webcenter.oam.conf" app_agent_password=<Password to be provisioned for App Agent> ldap_host=<Hostname of LDAP server> ldap_port=<Port of LDAP server> ldap_userdn=<DN of LDAP Admin User, usually "cn=orcladmin"> ldap_userpassword=<Password of LDAP Admin User> oam_aaa_host=<HOST of OAM server> oam_aaa_port=<Port of OAM server>
ドメイン(<your_domain_name>)はwebtier.example.com
のように登録することをお薦めします。OAM内の各種ポリシーを容易に区別できるように、webtier.example.com
にはWeb層を指定します。
コマンドが正常に実行されると、使用した値に応じて次のような出力が表示されます。
Processed input parameters Initialized Global Configuration Successfully completed the Create operation. Operation Summary: Policy Domain : webtier.example.com Host Identifier: webtier.example.com Access Gate ID : webtier.example.com_AG
また、Validateコマンドを実行して、構成を検証できます。
java -jar WC_ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar mode=VALIDATE app_domain=<your_domain_name> ldap_host=<Hostname of LDAP server> ldap_port=<Port of LDAP server> *ldap_userdn=<DN of LDAP Admin User, usually "cn=orcladmin">* ldap_userpassword=<Password of LDAP Admin User> oam_aaa_host=<HOST of OAM server> oam_aaa_port=<Port of OAM server> test_username=<Username to be used for policy validation> test_userpassword=<Userpassword to be used for policy validation>
コマンドが正常に実行されると、前述と同じ出力が表示されます。
インスタンスにSOAインストールも含まれている場合は、再度oamcfgtool
を実行して、前の手順で作成したポリシー・ドメインのSOA URIを保護します。既存のポリシー・ドメインがsoa.oam.conf
ファイルのURIで更新されるように、前の手順で使用したものと同じパラメータを使用してください。
java -jar ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar mode=CREATE app_domain=<your_domain_name> uris_file="SOA_HOME/soa/prov/soa.oam.conf" app_agent_password=<Password to be provisioned for App Agent> ldap_host=<Hostname of LDAP server> ldap_port=<Port of LDAP server> ldap_userdn=<DN of LDAP Admin User, usually "cn=orcladmin"> ldap_userpassword=<Password of LDAP Admin User> oam_aaa_host=<HOST of OAM server> oam_aaa_port=<Port of OAM server>
インストールにContent Serverが含まれている場合は、これらのURIも保護する必要があります。既存のポリシー・ドメインがContent Serverのoam.conf
ファイルのURIで更新されるように、前の手順で使用したものと同じパラメータを使用してください。
java -jar ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar mode=CREATE app_domain=<your_domain_name> uris_file="WC_CONTENT_ORACLE_HOME/common/security/oam.conf" app_agent_password=<Password to be provisioned for App Agent> ldap_host=<Hostname of LDAP server> ldap_port=<Port of LDAP server> ldap_userdn=<DN of LDAP Admin User, usually "cn=orcladmin"> ldap_userpassword=<Password of LDAP Admin User> oam_aaa_host=<HOST of OAM server> oam_aaa_port=<Port of OAM server>
ポリシー・ドメインの設定をチェックします。
Oracle Access Managerにログオンします。
「ポリシー・マネージャ」をクリックします。
「ポリシー・ドメイン」をクリックします。
ポリシー・ドメインのリストに、今作成したドメインが表示されているはずです。また、URL接頭辞列に、webcenter.oam.conf
スクリプト・ファイルの一部として指定されたURIも表示されます。SOAおよびContent Serverドメインからoamcfgtool
を実行すると、SOAおよびContent Server OAM構成ファイルからURIを表示できます。
今作成したドメインをクリックして、「リソース」タブを開きます。
指定したURIが表示されます。また、他のタブを開いて他の設定を表示および確認したり、後で必要に応じて他のリソースを手動で追加したりすることもできます。
アクセス・ゲートの構成をチェックします。
「アクセス・システム・コンソール」をクリックします。
「アクセス・システム構成」タブを開きます。
「アクセス・ゲート構成」をクリックします。
検索条件を入力して「実行」をクリックします。
作成したドメインのアクセス・ゲートが表示されたら(これは_AG
という接尾辞を持ちます)、これをクリックして設定の詳細を表示します。
前の手順で作成および確認したポリシー・ドメインを見つけて、「ポリシー」タブを開きます。
作成済の4つのポリシーが表示されます。
WebCenter REST Policy
Exclusion Scheme
Protected_JSessionId_Policy
Default Public Policy
WebCenter REST Policy
を選択し、「認証ルール」を選択して「変更」をクリックします。
AuthenticationScheme
を(OraDefaultFormAuthNScheme
から)OraDefaultBasicAuthNScheme
に変更します。
「除外スキーム・ポリシー」→「認証ルール」に移動して、それがAuthenticationScheme
としてOraDefaultExclusionAuthNScheme
(前の手順で作成)を使用していることを確認します。
「保存」をクリックします。
「ポリシー」タブを開き、ポリシーが次の順序になっていることを確認します。
Protected_JSessionId_Policy WebCenter REST Policy Exclusion Scheme Default Public Policy
第31.2.3.2.4項「Web層でのWebGate 10gのインストール」の説明に従って、WebGateのインストール手順を続行します。
この項では、WebGateのインストール方法を説明します。
WebGateをインストールする手順は次のとおりです。
インストールに必要な2つのgcc
ライブラリ(libgcc_s.so.1とlibstdc++.so.5
)を含むZIPファイル(Oracle_Access_Manager10_1_4_3_0_linux_GCClib.zip
)を/tmp
ディレクトリにコピーします。詳細は、Oracle Access Managerインストレーション・ガイドの「WebGateのインストール」に関する章を参照してください。
root
としてインストールを実行します。たとえば、/tmp
ディレクトリから次を実行します。
sudo -u root ./Oracle_Access_Manager10_1_4_3_0_linux_OHS11g_WebGate
インストール実行時の指示に従って、インストール・ディレクトリ、以前に作成したアクセス・ゲートの情報およびWebサーバーのhttpd.conf
ファイルの絶対パスを指定します。次に例を示します。
WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/httpd.conf
アクセス・ゲートの情報は、アクセス・システム・コンソールにあります。
インストール後、httpd.conf
ファイルの次のエントリの間に新しいセクションが挿入されます。
#** BEGIN WEBGATE SPECIFIC *** #** END Oblix NetPoint Specific ***
この内容が環境と一致していることをチェックしてください。
WebGate 10gをインストールおよび構成したら、第31.2.4項「OAM用のWebLogicドメインの構成」の説明に従ってWeblogicドメインを構成し、第31.2.6項「追加のシングル・サインオン構成」の説明に従って適用される追加のサービスとコンポーネントの構成を行います。
環境が複数のドメインにまたがっている場合(例: Spacesのドメイン、別個のSOAのドメインおよび別個のContent Serverのドメイン)、それぞれのドメインについてこの項の手順を繰り返してください。
この項の内容は次のとおりです。
Oracle Internet DirectoryがOAMアイデンティティ・ストアをバッキングしている場合、Oracle Internet Directoryオーセンティケータ(OracleInternetDirectoryAuthenticator
)はOAMのアイデンティティ・ストアとして使用されているLDAPサーバー用に構成し、プロバイダはSUFFICIENT
に設定する必要があります。
Oracle Internet Directoryオーセンティケータを構成する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます(図31-4を参照)。
OIDオーセンティケータを構成するレルム・エントリをクリックします。
レルムの設定ペインが表示されます(図31-5を参照)。
「プロバイダ」タブを開きます。
プロバイダの設定が表示されます(図31-6を参照)。
「新規」をクリックして、プロバイダを作成します。
「新しい認証プロバイダの作成」ペインが表示されます(図31-7を参照)。
新しいプロバイダの名前(例: OID Authenticator
)を入力し、そのタイプとしてOracleInternetDirectoryAuthenticator
を選択して、「OK」をクリックします。
「プロバイダ」タブで、新しく追加したプロバイダをクリックします。
オーセンティケータの共通設定ペインが表示されます(図31-8を参照)。
制御フラグをSUFFICIENT
に設定し、「保存」をクリックします。
「プロバイダ固有」タブを開きます。
オーセンティケータのプロバイダ固有の設定ペインが表示されます(図31-9を参照)。
次の表に示されているように、各フィールドに値を入力します。これら以外のフィールドは、デフォルト値のままにします。
フィールド | 値 | コメント |
---|---|---|
ホスト: |
LDAPサーバーのホストID |
|
ポート: |
LDAPサーバーのポート番号 |
|
プリンシパル: |
LDAP管理者プリンシパル(例: cn=orcladmin) |
|
資格証明: |
|
管理者プリンシパルのパスワード |
資格証明の確認: |
|
|
ユーザー・ベースDN: |
ユーザー検索ベース - この値はOAM Access Managerのセットアップの値と同じであることが必要 |
|
すべてのユーザーのフィルタ: |
"(&(uid=*)(objectclass=person))" |
|
ユーザー名属性: |
"uid" |
|
グループ・ベースDN: |
グループ検索ベース - ユーザー・ベースDNと同じ |
|
取得したユーザー名をプリンシパルとして使用する |
選択 |
通常はユーザー・ログインIDでは大/小文字は区別されません。このフラグは、設定されたサブジェクトに、OIDに格納されたユーザー名が含まれるようにするために必要とされます。 |
「保存」をクリックします。
OAMアイデンティティ・アサータは、プロバイダの制御フラグをREQUIRED
に設定して構成する必要があります。
OAMアイデンティティ・アサータを構成する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます(図31-10を参照)。
OAMアイデンティティ・アサータを構成するレルム・エントリをクリックします。
レルムの設定ペインが表示されます(図31-11を参照)。
「プロバイダ」タブを開きます。
プロバイダの設定が表示されます(図31-12を参照)。
「新規」をクリックして、プロバイダを作成します。
「新しい認証プロバイダの作成」ペインが表示されます(図31-13を参照)。
新しいプロバイダの名前(例: OAM ID Asserter
)を入力し、そのタイプとしてOAMIdentityAsserter
を選択して、「OK」をクリックします。
「プロバイダ」タブで、新しく追加したプロバイダをクリックします。
オーセンティケータの共通設定ペインが表示されます(図31-14を参照)。
制御フラグをREQUIRED
に設定し、OAM_REMOTE_USER
とObSSOCookie
が「アクティブなタイプ」に設定されていることをチェックします。
「保存」をクリックして、設定を保存します。
OAMアイデンティティ・アサータを構成したら、デフォルト・オーセンティケータの制御フラグがSUFFICIENT
に設定されていることを確認して、次のようにプロバイダを並べ替えます。
プロバイダの設定ペインに移動します(図31-12を参照)。
デフォルト・オーセンティケータを開き、制御フラグがSUFFICIENT
に設定されていることを確認します。
先ほど作成した2つのプロバイダ以外の全プロバイダについて、同じことを行います。
設定ペインで、プロバイダを次のように並べ替えます。
OAMIdentityAsserter
(REQUIRED
)
OracleInternetDirectoryAuthenticator
(SUFFICIENT
)
DefaultAuthenticator
(SUFFICIENT
)
DefaultIdentityAsserter
第31.2.6.1項「SSO用のWebCenter Portal: Spacesの構成」の説明に従って、シングル・サインオン・モード用にSpacesを構成します。また、第31.2.6項「追加のシングル・サインオン構成」の説明に従って、環境に適用される他のサービスおよびコンポーネントの構成を行ってください。
デフォルト・オーセンティケータの制御フラグが適切に設定されていることとプロバイダの順序が正しいことをチェックしたら、次で説明されているように、OAM SSOプロバイダを追加して、すべてのサーバーを再起動します。
注意: これはOAM 11gの場合は必要ですが、OAM 10gの場合はログアウトURIが明示的に構成されている場合のみ必要です。 |
WLSTを使用してWebLogicドメインに接続し、次のコマンドを実行します。
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html")
すべてのサーバーを再起動します。
この手順はOAM 10gとOAM 11gの両方に共通で、OAMのインストールおよび構成後、WebLogicドメインの構成前に実行する必要があります。
Oracle HTTP Server(OHS)をインストールおよび構成する手順は次のとおりです。
使用したいOHSのインストールがまだない場合は、Oracle Fusion Middleware Oracle Web層インストレーション・ガイドのOracle Web層のインストールに関する項の指示に従ってOracle HTTP Server(11.1.1.4.0)をインストールします。既存のインストールがある場合は、Oracle Fusion Middlewareパッチ適用ガイドの最新のOracle Fusion Middlewareパッチ・セットの適用に関する項の説明に従ってパッチを適用して、OHS (11.1.1.4.0)にする必要があります。
mod_wl_ohs.conf
の次の例を使用して、WebCenter Portal用のOracle WebLogic Serverにリクエストを転送するようにWeb層OHSを構成します。WebLogicポート番号が構成と一致するようにしてください。詳細は、Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOAM用のOracle HTTP Server 11g WebGateのインストールと構成に関する項を参照してください。
注意: この例では、WebCenter Portalが非クラスタベースのインストールであることを前提としています。クラスタ環境の場合は、 |
# NOTE : This is a template to configure mod_weblogic. LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so" # This empty block is needed to save mod_wl related configuration from EM to this file when changes are made at the Base Virtual Host Level <IfModule weblogic_module> # WebLogicHost <WEBLOGIC_HOST> # WebLogicPort <WEBLOGIC_PORT> # Debug ON # WLLogFile /tmp/weblogic.log # MatchExpression *.jsp <Location /webcenter> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /webcenterhelp> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /rss> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /rest> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /rsscrawl> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /sesUserAuth> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /owc_discussions> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8890 </Location> <Location /activitygraph-engines> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8891 </Location> <Location /wcps> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8891 </Location> <Location /workflow> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /integration/worklistapp> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /integration/services> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /soa-infra> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /sdpmessaging/userprefs-ui> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /DefaultToDoTaskFlow> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /cs> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location> <Location /adfAuthentication> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location> <Location /pagelets> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8889 </Location> <Location /services-producer> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8889 </Location> <Location /wsrp-tools> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8889 </Location> </IfModule> # <Location /weblogic> # SetHandler weblogic-handler # PathTrim /weblogic # ErrorPage http:/WEBLOGIC_HOME:WEBLOGIC_PORT/ # </Location>
注意: 前述の |
次の項で説明する構成は、サイトのセキュリティを強化するために必要であるか、または役に立ちます。これらの構成が完了したら、第31.2.7項「OAMインストールのテスト」の説明に従ってOAMインストールのテストを行ってください。
第31.2.6.5項「OAM 10g用のWebLogic Server管理コンソールとEnterprise Managerの構成」
第31.2.6.6項「OAM 11g用のWebLogic Server管理コンソールとEnterprise Managerの構成」
SpacesアプリケーションをSSO用に構成するには、EXTRA_JAVA_PROPERTIES
に設定を追加します。
アプリケーションがSSOモードに構成されており、特別な処理が必要であることをWebCenter PortalとADFに伝えるシステム・プロパティがあります。このモードでは、次のシステム・プロパティが必要とされます。
フィールド | 値 | コメント |
---|---|---|
|
|
このフラグはSSOが使用されていることをWebCenter Portalに告げるため、デフォルトのランディング・ページにログイン・フォームは表示されなくなります。そのかわりにログイン・リンクが表示され、ユーザーはこれをクリックしてSSO認証を呼び出すことができます。 |
このプロパティを設定するには、<domain>/bin
ディレクトリにあるsetDomainEnv.sh
スクリプトを編集し、次のようなエントリを追加します。
EXTRA_JAVA_PROPERTIES="-Doracle.webcenter.spaces.osso=true ${EXTRA_JAVA_PROPERTIES}" export EXTRA_JAVA_PROPERTIES
この変更を行ったら、WC_Spaces
サーバーを再起動します。
この項では、シングル・サインオン用のOracle WebCenter Portalのディスカッション・サーバーを構成する方法について説明します。SSO用のディスカッション・サーバーを構成する前に、第29.1項「外部LDAPサーバーへのアイデンティティ・ストアの再関連付け」の説明に従って、Spacesと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。デフォルトの管理者アカウントを外部LDAPに移動しない場合は、第29.5.1項「外部LDAPを使用するためのWebCenter Portalのディスカッション・サーバーの移行」の手順にも従ってください。
SSO用のディスカッション・サーバーを設定する手順は次のとおりです。
Oracle WebCenter Portalのディスカッション・サーバー管理コンソールにログインします。
http://host:port/owc_discussions/admin
host
およびport
は、WC_Collaboration
管理対象サーバーのホストIDとポート番号です。
「システム・プロパティ」ページを開き、owc_discussions.sso.mode
プロパティを編集(存在している場合)または追加します(値をtrue
に設定します)。
Web層のベースURLをポイントするようにjiveURL
プロパティを編集または追加します。次に例を示します。
jiveURL = webtier.example.com:7777/owc_discussions
jiveURL
プロパティは、電子メールのフォーラムへのリンクを構築する際に使用されます。
この項では、Web層のホストおよびポートの値を使用するようにSpaces用のディスカッション・サーバー接続を更新する方法を説明します。次の手順では、ディスカッション・サービスがWebCenter Portalドメインにすでにインストールおよび構成されていることを前提としています。
Fusion Middleware ControlまたはWLSTを使用して、ディスカッション・サーバーのURLホストおよびポート設定をWC_Spaces
管理対象サーバーの設定からWeb層のホストおよびポート設定に変更します。これらの設定の変更方法については、第14.5項「ディスカッション・サーバー接続の詳細の変更」を参照してください。
WC_Spaces
管理対象サーバーを再起動します。
Spacesにログインすると、ディスカッション・サーバーにも自動的にサインオンします。
すでにワークリスト接続をセットアップしてある場合は、SOAサーバーのホストとポートのかわりにWeb層のホストとポートを使用するようにURLを変更します。これは第23.4項「ワークリスト接続の設定」の説明に従って、Fusion Middleware ControlまたはWLSTコマンドを使用して行うことができます。
URLを変更してOAM SSOに必要なセットアップを完了したら、WebCenter Portal管理サーバー上で次のコマンドを実行してワークリスト・サービスの変更を有効にします。
setBPELConnection('webcenter','WebCenter-Worklist', 'http://webtier.example.com:7777')
デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護された状態では、外部リーダーでRSSフィードがうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できるWebLogic ServerのBASIC認証によってRSSサーブレットの認証が処理されるように、WebCenter Portal RSSリソースをOAMポリシーから除外することをお薦めします。
この項の内容は次のとおりです。
OAM 11gのRSSフィードを非保護にする手順は次のとおりです。
OAM管理コンソールを開きます。
「ポリシー構成」タブを開いて、「アプリケーション・ドメイン」→<該当するアプリケーション・ドメイン>を選択します。
「リソース」タブを開いて、/rss*
を検索します。
結果の中に、次のような項目が表示されるはずです。
/rss*
/rss/.../*
/rss/rssservlet*
/rss/rssservlet/.../*
それぞれのリソースについて、そのリソースを選択して「編集」をクリックします。
各リソースの保護レベルをProtected
からExcluded
に変更して、「適用」をクリックします。
リソースの認証ポリシーと認可ポリシーが削除されることに注意してください。
タブを閉じてOHSを再起動します。
OAM 10gのRSSフィードを非保護にする手順は次のとおりです。
OAM管理コンソールを開きます。
「アクセス・システム・コンソール」→「ポリシー・マネージャ」を選択し、適切なポリシー・ドメインを開きます。
「ポリシー」タブを開き、Exclusion Scheme
ポリシーを選択して、「変更」をクリックします。
除外するために次のリソースを選択します。
/rss
/rss/rssservlet
「保存」をクリックします。
Default Public Policy
を選択して、「変更」をクリックします。
/rss resource
を選択解除して、「保存」をクリックします。
OHSを再起動します。
この項では、WebLogic Server管理コンソールとEnterprise ManagerのためにオプションでOAMシングル・サインオンをセットアップする方法を説明します。
注意: Enterprise ManagerとWebLogic Server管理コンソールに対してOAM SSOをセットアップすると、OAM SSOアクセスが構成されている同じユーザー・セットでシングル・サインオン・アクセスが可能になります。OAMを通じて外部ユーザーがWeb層にアクセスできるようにし、一方、管理者はEnterprise ManagerとWebLogic Server管理コンソールに直接ログインするようにしたいときは、この追加の構成手順を実行する必要がない場合もあります。 |
WebLogic Server管理コンソールとEnterprise ManagerのOAM SSOをセットアップする手順は次のとおりです。
ブラウザを使用してOAMコンソールにログインし、次の場所に移動します。
http://host:port/access/oblix
host
はAccess ManagerをホストするサーバーのホストID(例: oam.example.com
)、port
はHTTPポート番号(例: 8888
)になります。
「ポリシー・マネージャ」をクリックします。
「ポリシー・マネージャ」ペインが表示されます(図31-15を参照)。
WebCenter Portalリソースを保護するために作成したポリシー・ドメインを見つけます。
「リソース」タブを開き、「追加」をクリックします。
「リソース」ページが表示されます(図31-16を参照)。
保護する必要のあるリソースを追加します。各リソースに対して、次の手順を実行します。
「リソース・タイプ」としてhttp
を選択します。
WebCenter Portal Web層のホストIDを選択します。
「URL接頭辞」に、WebLogic Server管理コンソールのURL接頭辞(/console
)またはEnterprise ManagerのURL接頭辞(/em
)を入力します。
リソースの説明を入力します。
「キャッシュの更新」が選択されていることを確認して、「保存」をクリックします。
Web層で、mod_wl_ohs.conf
ファイル(WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/
にあります)を、WebLogic Server管理コンソールとEnterprise Managerが含まれるように変更します。それには、WebLogicHost
に、WebCenter Portal管理サーバーの実際のホストIDを使用して、場所のエントリを2つ追加します。
<Location /console> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 7001 </Location> <Location /em> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 7001 </Location>
変更を有効にするために、Oracle HTTP Serverを再起動します。
これで、次のリンクでWebLogic Server管理コンソールとEnterprise Managerにアクセスできるようになります。
http://host:OHS port/console
http://host
:OHS port/em
OAM SSOログイン・フォームが表示されます。
この項では、WebLogic Server管理コンソールとEnterprise ManagerのためにオプションでOAM 11gシングル・サインオンをセットアップする方法を説明します。
注意: Enterprise ManagerとWebLogic Server管理コンソールに対してOAM SSOをセットアップすると、OAM SSOアクセスが構成されている同じユーザー・セットでシングル・サインオン・アクセスが可能になります。OAMを通じて外部ユーザーがWeb層にアクセスできるようにし、一方、管理者はEnterprise ManagerとWebLogic Server管理コンソールに直接ログインするようにしたいときは、この追加の構成手順を実行する必要がない場合もあります。 |
WebLogic Server管理コンソールとEnterprise Managerに対してOAM 11g SSOをセットアップする手順は次のとおりです。
ブラウザを使用してOAMコンソールにログインします。
http://host:port/oamconsole
「ポリシー構成」→「アプリケーション・ドメイン」に移動します。
「ポリシー・マネージャ」ペインが表示されます。
WebGateエージェントの登録時の名前を使用して、作成したアプリケーション・ドメインを見つけます。
リソース・ノードを展開して「作成」をクリックします。
「リソース」ページが表示されます。
保護する必要のあるリソースを追加します。各リソースに対して、次の手順を実行します。
「リソース・タイプ」としてhttp
を選択します。
WebGateエージェントの登録時に作成されたホストIDを選択します。
「リソースURL」に、WebLogic Server管理コンソールのリソースURL(/console
)またはEnterprise ManagerのリソースURL(/em
)を入力します。
リソースの「説明」を入力して、「適用」をクリックします。
「認証ポリシー」→「保護されたリソース・ポリシー」に移動して、新しく作成されたリソースを追加します。
「認可ポリシー」→「保護されたリソース・ポリシー」についても同じことを行います。
Web層で、mod_wl_ohs.conf
ファイル(WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/
にあります)を、WebLogic Server管理コンソールとEnterprise Managerが含まれるように変更します。それには、WebLogicHost
に、WebCenter Portal管理サーバーの実際のホストIDを使用して、場所のエントリを2つ追加します。
<Location /console> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 7001 </Location> <Location /em> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 7001 </Location>
変更を有効にするために、Oracle HTTP Serverを再起動します。
これで、次のリンクでWebLogic Server管理コンソールとEnterprise Managerにアクセスできるようになります。
http://host:OHS port/console
http://host
:OHS port/em
OAM SSOログイン・フォームが表示されます。
WebCenter PortalとSESに定義された対応する認証エンド・ポイントが使用するWebCenter Portalデータとリポジトリをクロールするために定義されるクロール・ソースは、適切に認証されるようにWeb層OHSポートを通してルーティングする必要があります(認証方式は引き続きBASICおよびレルムjazn.comになります)。SES接続の構成に関する詳細は、第22.4項「Oracle SES接続の設定」を参照してください。
SSOのセットアップが完了し、Content Serverの接続をセットアップしたら、Fusion Middleware Controlを使用して、または次のWLSTの例のように、JCRContentServerConnection
にWebコンテキスト・ルートを指定します。
setJCRContentServerConnection(appName, name, webContextRoot='/cs')
Webコンテキスト・ルートを設定することで、SSOがセットアップされていることをドキュメント・ライブラリのコードに伝えます。この設定は、SSOを完全にセットアップするまでは設定しないでください。
ユーザーが適切に認証されるように、Web層OHSポートを通してのみWebCenter Portalと他のサービスへのアクセスを許可するには、次の手順に従います。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
ドメイン構造ペインで、構成するドメインを選択します(例: webcenter
)。
「セキュリティ」タブを開き、「フィルタ」サブタブを開きます。
セキュリティ・フィルタの設定ペインが表示されます(図31-17を参照)。
「接続ログの有効化」を選択して、受け入れられたメッセージのログを有効にします。
接続ログは、成功した接続と接続データをサーバーにログします。この情報を使用して、サーバー接続に関する問題をデバッグできます。
「接続フィルタ」フィールドに、ドメインで使用する接続フィルタ・クラスを指定します。
デフォルトの接続フィルタを構成するには、weblogic.security.net.ConnectionFilterImpl
と指定します。
カスタム接続フィルタを構成するには、ネットワーク接続フィルタを実装するクラスを指定します。このクラスはWebLogic ServerのCLASSPATHにも指定されていることが必要です。
「接続フィルタ・ルール」フィールドに、接続フィルタ・ルールの構文を入力します。
次に例を示します。
<webtier IP>/0 * * allow 0.0.0.0/0 * * deny
これは、ローカル・ホストからの全トラフィックを許可し、他のIPアドレスからの全トラフィックを拒否するように指定しています。もちろん、環境に適切なネットワーク・フィルタを作成する必要があります。接続フィルタの作成に関する詳細は、Oracle Fusion Middleware Oracle WebLogic Serverプログラミング・セキュリティのカスタム接続フィルタの開発に関する項を参照してください。
「保存」をクリックして、変更を有効にします。
すべての管理対象サーバーと管理サーバーを再起動します。
WebLogic Serverへのすべての直接トラフィックが、次へのナビゲートを試行することでブロックされることを検証します。
http://host:WLS_port/webcenter
これによって次のエラーが生成されます。
"The Server is not able to service this request: [Socket:000445]Connection rejected, filter blocked Socket, weblogic.security.net.FilterException: [Security:090220]rule 3"
ただし、OHSポートを通してWebCenter Portalにアクセスすることは今でも可能です。
http://host:OHS_port/webcenter
OHSを通してルーティングされるようにポートレット・プロデューサ・アプリケーションをセットアップした場合は、登録用のプロデューサURLを指定する際に必ずOHSホストおよびポートを使用してください。これは、wsrp-toolsのようなデフォルトのプロデューサ、サービス・プロデューサ、ページレット・プロデューサおよび明示的に構成した他のプロデューサに適用されます。
OAM 10gまたは11gをインストールおよび構成したら、構成された次のすべての(環境に適用される)アプリケーションにアクセスできることと、グローバル・ログインおよびログアウトによって再度サインインを要求されることなく構成されたすべてのアプリケーションにアクセスできることをチェックします。また、利用できる状況でグローバル・ログアウトもテストして、関連する他のすべてのアプリケーションからログアウトすることを確認してください。
Spaces: 保護されたすべてのSpaces URL(例: 保護されたスペース)にアクセスして、SSOログイン・チャレンジが表示されることを確認します。同じSSOを使用する別の関連アプリケーションにすでにログインしている場合は、コンテンツが自動的に表示されます。
REST: http://ohshost:ohsport/rest/api/resourceIndex
にアクセスします。BASIC認証チャレンジが表示されるはずです。同じSSOを使用する別の関連アプリケーションにすでにログインしている場合は、コンテンツが自動的に表示されます。
REST: http://ohshost:ohsport/rest/api/cmis/....
にアクセスします (これは前の手順のresourceIndex
アクセス出力から取得します)。ログイン・チャレンジは表示されず、パブリック・コンテンツを表示できるはずです。ログイン後にこれにアクセスすると、アクセス権を持つすべてのコンテンツが表示されるはずです。
アクティビティ・グラフ・エンジン: http://host:port/activitygraph-engines
にアクセスします。SSOログイン・チャレンジが表示されるはずです。ログインすると、コンテンツを表示できるはずです。
Content Server: プロファイルのUIに移動して、ログインへのチャレンジなしでiFramesに埋め込まれたContent Server画面を表示できることをチェックします。また、すでにSpacesアプリケーションにログインしているので、ログインしないでコンテンツ・プレゼンタ・テンプレートでSite Studioのコンテンツにアクセスできるはずです。
SOA: ワークフロー・タスク・フローのリンクにアクセスして、ログインをチャレンジされないことを確認します。
ディスカッション・フォーラム: http://host:port/owc_discussions
のディスカッション・アプリケーションにアクセスし、ログインします。ログインがSSOログインのチャレンジであることをチェックします。同様に、http://host:port/owc_discussions/admin
のディスカッション・サーバーへの管理ログインも、SSOログイン・チャレンジを通したものになるはずです。
デフォルトのインストールでは、WebCenter PortalはWebCenter Portal用に作成された管理対象サーバーのHTTPポートを使用します。Oracle Single Sign-Onを使用してWebCenter Portalアプリケーションを構成するためには、WebCenter PortalはOracle Single Sign-On(OSSO)と統合するために、Oracle HTTP Serverおよび関連付けられたモジュールmod_osso
を必要とします。第32.5項「OSSOに対するFrameworkアプリケーションの構成」で説明されているように、Frameworkアプリケーションの場合は、追加の構成がいくつか必要になることに注意してください。
注意: BPELコンソールはSSOの統合をサポートしません。WebCenter PortalがSSO用に構成されている場合も、BPELへのログインはBPELコンソール上で標準ログイン・ページを通して行う必要があります。 |
この項の内容は次のとおりです。
この項のフロー・チャート(図31-18)と表(表31-2)は、OSSOを使用してWebCenter Portalのシングル・サインオンを構成する際の前提条件と必要なタスクの概要を示しています。
表31-2は、OSSOを使用してWebCenter Portalのシングル・サインオンを構成するためのタスクとサブタスクを示しています。
表31-2 OSSOを使用したWebCenter Portalのシングル・サインオンの構成
担当者 | タスク | サブタスク | ノート |
---|---|---|---|
Administrator |
1. Oracle HTTP Serverと関連モジュールの構成 |
1.a Web層のインストール |
|
1.b Web層OHS内のmod_wlモジュールの構成 |
|||
2. OSSOIdentityAsserterの構成 |
|||
3. Oracle SSOへのOHSの登録 |
|||
4. 必要に応じた追加構成の実行 |
4.a SSO用のSpacesの構成 |
||
4.b Web層OHSポートを通したWebCenterとサービスへのアクセスの制限 |
|||
4.c SSO用のディスカッション・サーバーの構成 |
デフォルトのインストールでは、WebCenter PortalはWebCenter Portal用に作成された管理対象サーバーのHTTPポートを使用します。Oracle Single Sign-Onを使用してWebCenter Portalを構成するためには、WebCenter PortalはOracle SSOと統合するために、Oracle HTTP Serverおよび関連付けられたモジュールmod_osso
を必要とします。次の図(図31-19)は、この統合の全体的なアーキテクチャを示しています。
この項では、Oracle HTTP Serverと関連付けられたモジュールのロードおよび構成方法を説明します。
Oracle HTTP Serverおよび関連付けられたモジュールをロードおよび構成する手順は次のとおりです。
Oracle HTTP Server(OHS)および関連付けられたモジュール(mod_osso
およびmod_wl
)を含むOracle Web層ソフトウェアをインストールします。
WebCenter Portal用のOracle WebLogic Serverにリクエストを転送するようにWeb層OHS内のmod_wl
モジュールを構成します。ホストとポートの値には、ローカル環境の値を指定してください。
${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so
の行を非コメント化します。このファイルは次のような内容で、httpd.conf
ファイルによりインクルードされます。
# NOTE : This is a template to configure mod_weblogic. LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so" # This empty block is needed to save mod_wl related configuration from EM to this file when changes are made at the Base Virtual Host Level <IfModule weblogic_module> # WebLogicHost <WEBLOGIC_HOST> # WebLogicPort <WEBLOGIC_PORT> # Debug ON # WLLogFile /tmp/weblogic.log # MatchExpression *.jsp <Location /webcenter> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /webcenterhelp> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /rss> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /rest> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /rsscrawl> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /sesUserAuth> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /services-producer> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8889 </Location> <Location /wsrp-tools> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8889 </Location> <Location /owc_discussions> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8890 </Location> <Location /activitygraph-engines> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8891 </Location> <Location /wcps> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8891 </Location> <Location /workflow> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /integration/worklistapp> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /integration/services> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /soa-infra> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /sdpmessaging/userprefs-ui> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /DefaultToDoTaskFlow> SetHandler weblogic-handler WebLogicHost soa.example.com WebLogicPort 8001 </Location> <Location /cs> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location> <Location /adfAuthentication> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location> </IfModule> # <Location /weblogic> # SetHandler weblogic-handler # PathTrim /weblogic # ErrorPage http:/WEBLOGIC_HOME:WEBLOGIC_PORT/ # </Location>
WebCenter Portal用のOracle WebLogicドメインにOSSO Identity Assertion Provider(IAP)プロバイダを追加します。次の手順に従って、WebLogic Server管理コンソールを使用してOSSO IAPをドメインに追加します。環境が複数のドメインにまたがっている場合(例: Spacesのドメイン、別個のSOAのドメインおよび別個のContent Serverのドメイン)、それぞれのドメインについてこの項の手順を繰り返してください。
OSSOIdentityAsserterを構成する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます(図31-20を参照)。
プロバイダを追加するレルム・エントリをクリックします。
レルムの設定ペインが表示されます(図31-21を参照)。
「プロバイダ」タブをクリックします。
プロバイダの設定が表示されます(図31-22を参照)。
「新規」をクリックして、プロバイダを作成します。
「新しい認証プロバイダの作成」ペインが表示されます(図31-23を参照)。
新規のプロバイダの名前を入力し、タイプとして「OSSOIdentityAsserter」を選択して「OK」をクリックします。
「プロバイダ」タブで、新しく追加したプロバイダをクリックします。
制御フラグをOPTIONAL
に設定します。
関連付けられたOracle Internet Directoryサーバーからユーザー・プロファイルを取得できるように、OracleInternetDirectoryAuthenticator(または外部LDAPを使用するようにアイデンティティ・ストアを構成した際に選択したプライマリ・オーセンティケータ)がドメインのプライマリ・オーセンティケータとして設定されていることを確認します。外部LDAPを使用するようにアイデンティティ・ストアを構成する方法については、第29章「アイデンティティ・ストアの構成」を参照してください。
OIDについて、次のようにプロバイダ・リストが表示されます。
OSSOIdentityAsserter (OPTIONAL
)
OracleInternetDirectoryAuthenticator (SUFFICIENT
)
DefaultAuthenticator (SUFFICIENT
)
DefaultIdentityAsserter (OPTIONAL
)
次の手順に従って、Web層OHS内のモジュールmod_osso
をパートナ・アプリケーションとしてSSOサーバーに登録します。
Oracle SSOにOHSを登録する手順は次のとおりです。
SSOサーバーからssoreg
を実行してosso.conf
ファイルを生成し、バイナリ・モードでFTPを使用してWeb層ホスト(WT_ORACLE_HOME
)にこれを転送します。
次の例に、SSOサーバーでリモート・パートナ・アプリケーションを登録する方法を示します。ssoreg.sh
を実行する前に、ORACLE_HOME
環境変数が設定されていることをチェックします(ここでのORACLE_HOME
は、SSOサーバー上のOSSOインストールのORACLE_HOME
です)。
bash-3.00$ ORACLE_HOME/sso/bin/ssoreg.sh -site_name webtier.example.com:80 -config_mod_osso TRUE -mod_osso_url http://webtier.example.com:80 -remote_midtier -config_file webtier.example.com.osso.conf
このコマンドを実行すると、webtier.example.com.osso.conf
ファイルが作成されます。
WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/disabled/mod_osso.conf
ファイルをWT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/moduleconf
にコピーします。moduleconf
ディレクトリ内のすべてのファイルがhttpd.conf
ファイルにインクルードされます。
手順1でssoreg
によって生成されたwebtier.example.com.osso.conf
ファイルを、Web層のmoduleconf
ディレクトリ以外のアクセス可能な場所(例: WT_ORACLE_HOME)にコピーします。
注意: FTPを使用する場合は、必ずバイナリ・モードを使用してファイルを転送してください。 |
/webcenter
と関連するアプリケーション・リソースのURLをOracle SSOを使用して保護するためのルールをmod_osso.conf
ファイルに追加します。
mod_osso.conf
ファイルは次のようになります。
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so" <IfModule osso_module> OssoIpCheck off OssoIdleTimeout off OssoSecureCookies Off #Point to proper osso.conf file. OssoConfigFile /scratch/pyarashi/ohs/dadvmi0003.osso.conf # # Insert Protected Resources: (see Notes below for # how to protect resources) # #______- # # Notes # #______- # # 1. Here's what you need to add to protect a resource, # e.g. <ApacheServerRoot>/htdocs/private: # # <Location /private> # require valid-user # AuthType Osso # </Location> <Location /webcenter/adfAuthentication*> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /services-producer/adfAuthentication*> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rss/rssservlet> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /owc_discussions/login!withRedirect.jspa> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /owc_discussions/login!default.jspa> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /owc_discussions/login.jspa> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /owc_discussions/admin> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /integration/worklistapp> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /sdpmessaging/userprefs-ui> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /workflow/WebCenterWorklistDetail> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /workflow/sdpmessagingsca-ui-worklist> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/resourceIndex> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/spaces> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/discussions> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/tags> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/taggeditems> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/activities> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/activitygraph> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/feedback> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/people> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/messageBoards> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /rest/api/searchresults> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /pagelets/admin> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /pagelets/authenticateWithApplicationServer*> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /activitygraph-engines> OssoSendCacheHeaders off require activity-graph-admins AuthType Osso </Location> <Location /wcps/api> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /cs/groups> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /cs/idcplg> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> <Location /adfAuthentication> OssoSendCacheHeaders off require valid-user AuthType Osso </Location> </IfModule> # # To have short hostnames redirected to fully qualified # hostnames for clients that need authentication via # mod_osso to be able to enter short hostnames into their # browsers use a mod_rewrite configuration such as the following. # # e.g #RewriteEngine On #RewriteCond %{HTTP_HOST} !www.example.com #RewriteRule ^.*$ http://%{SERVER_NAME}%{REQUEST_URI} [R] #where www.example.com is the fully qualified domain name.
OssoConfigFile
パラメータは、前の手順でosso.conf
ファイルをコピーした場所(および変更した場合はファイル名)をポイントするように必ず変更してください。環境が非SSLの場合は、OSSOセキュアCookie(デフォルトでオン)を必ずオフにしてください(OssoSecureCookies Off)。
mod_osso
およびmod_wl
の構成変更が有効になるように、Web層を再起動します。
次の項で説明する構成は、サイトのセキュリティを強化するために必要であるか、または役に立ちます。Frameworkアプリケーションの場合は、第32.5項「OSSOに対するFrameworkアプリケーションの構成」で説明されている追加の構成も必要になります。
第31.2.6.1項「SSO用のWebCenter Portal: Spacesの構成」の説明に従ってEXTRA_JAVA_PROPERTIES
に設定を追加してリブートすることで、Spaces用のOracle Single Sign-on(OSSO)の構成を行ってください。
ユーザーが適切に認証されるように、Web層OHSポートを通してのみWebCenter Portalと他のサービスへのアクセスを許可するには、第31.2.6.9項「接続フィルタを使用したアクセスの制限」の手順に従います。
この項では、シングル・サインオン用のOracle WebCenter Portalのディスカッション・サーバーを構成する方法について説明します。SSO用のディスカッション・サーバーを構成する前に、第29.5.1項「外部LDAPを使用するためのWebCenter Portalのディスカッション・サーバーの移行」の説明に従って、Spacesと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。
SSO用のディスカッション・サーバーを設定する手順は次のとおりです。
Oracle WebCenter Portalのディスカッション・サーバー管理コンソールにログインします。
http://host:port/owc_discussions/admin
host
およびport
は、WC_Collaboration
管理対象サーバーのホストIDとポート番号です。
「システム・プロパティ」ページを開き、owc_discussions.sso.mode
プロパティを編集(存在している場合)または追加します(値をtrue
に設定します)。
Web層のベースURLをポイントするようにjiveURL
プロパティを更新します。
第31.3.5項「Oracle SSOへのOHSの登録」の説明に従ってOracle SSOにOHSを登録したら、WebCenter Portal管理サーバーで次のコマンドを実行して、ワークリスト・サービスの変更を有効にします。
setBPELConnection('webcenter','WebCenter-Worklist', 'http://webtier.example.com:7777')
Content ServerリポジトリにはSpacesから直接アクセスできるので、これもシングル・サインオン構成に含めることが可能です。Content Serverの接続をセットアップしたら、Fusion Middleware Controlを使用して、または次の例のようにWLSTを使用して、JCRContentServerConnection
にWebコンテキスト・ルートを指定します。
setJCRContentServerConnection(appName, name, webContextRoot='/cs')
Content Serverの構成方法の詳細は、Oracle WebCenter Content Content Serverシステム管理者ガイドのシングル・サインオンを使用するためのContent Serverの構成に関する項を参照してください。
デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護された状態では、外部リーダーでRSSフィードがうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できるWebLogic ServerのBASIC認証によってRSSサーブレットの認証が処理されるように、WebCenter Portal RSSリソースを非保護にすることをお薦めします。
次の手順に従って、RSSフィードを非保護にします。
mod_osso.conf
から次のエントリを削除します。
<Location /rss/rssservlet> OssoSendCacheHeaders off require valid-user AuthType Osso </Location>
OHSを再起動します。
インスタンスにSESを構成してある場合は、オプションとしてWeb層URLを使用するようにWebCenter Portalのクロールおよび認証エンド・ポイントを更新できます。詳細は第22章「WebCenter PortalでのOracle SES検索の管理」を参照してください。
Security Assertion Markup Language(SAML)によって、WebLogic ServerドメインおよびWebブラウザまたは他のHTTPクライアントで実行されているWebアプリケーションやWebサービス間でクロスプラットフォームの認証が可能になります。WebLogic Serverは、ページレット・プロデューサ・アプリケーションを除くすべてのWebCenter Portalアプリケーションに対して、SAMLに基づくシングル・サインオン(SSO)をサポートします。シングル・サインオン(SSO)構成に参加する1つのサイトでユーザーが認証されると、SSO構成の他のサイトでも自動的に認証され、別途ログインする必要はありません。ページレット・プロデューサ・アプリケーションはSAML SSOに参加しないので、ページレット・プロデューサ・アプリケーションにアクセスするユーザーは明示的にログインする必要があることに注意してください。また、第32.6項「SAML SSOに対するFrameworkアプリケーションの構成」で説明されているように、Frameworkアプリケーションの場合は、追加の構成がいくつか必要になることにも注意してください。
注意: SAMLベースのシングル・サインオンは、初回サインオン後の後続のアプリケーションへのユーザーのログオンはサポートしますが、グローバル・ログアウトはサポートしません。このため、ユーザーは、開いた各アプリケーションを個々にログアウトする必要があります。 また、Spacesをソース・アプリケーション、ディスカッションを宛先アプリケーションとして使用して、SAMLベースのシングル・サインオンをセットアップすると、管理者はSpaces管理(「構成」→「サービス」)とSpace設定(「サービス」ページ)からディスカッション管理ページにアクセスできることにも注意してください。ただし、ディスカッション管理ページはSSOに参加しないので、管理ページに直接アクセスすると、ディスカッション・サーバーに再度ログインすることが必要となります。 さらに、SAMLベースのシングル・サインオンは、 |
このSSOメカニズムは、Oracle SSOまたはOracle Access Managerシングル・サインオン・インフラストラクチャがまだ存在しておらず、Spacesとそのサービス間のみのシングル・サインオンが必要とされる部門別のWebCenter Portalのインストールに使用できます。大規模エンタープライズの高可用性展開では、Oracle Access Manager SSO構成をお薦めします。
この項では、同じドメイン内の異なる管理対象サーバー上で実行されるWebCenter Portal: Spacesおよびワークリスト・サービスに対してSAML 1.1ベースのシングル・サインオンをセットアップする方法を説明します。
この項の内容は次のとおりです。
図31-25は、Spacesとディスカッション・サービスを含むSAMLベースのシングル・サインオン構成のコンポーネントとその対話を示しています。
SAMLベースのシングル・サインオン・ソリューションは、次のコンポーネントから構成されます。
SAML資格証明マッパー - SAML資格証明マッピング・プロバイダは、SAMLセキュリティ・アサーションのプロデューサとして動作して、シングル・サインオンにSAMLを使用するためのソース・サイトとしてWebLogic Serverが動作することを可能にします。SAML資格証明マッピング・プロバイダは、ターゲット・サイトまたはリソースの構成に基づいて、認証されたサブジェクトのために有効なSAML 1.1アサーションを生成します。
サイト間転送サービス(ITS) - アイデンティティ・アサーションを生成してユーザーを宛先サイトに転送するアドレス可能なコンポーネント。
アサーション取得サービス(ARS) - アーティファクトに対応するSAMLアサーションを返すアドレス可能なコンポーネント。アサーションIDは、アサーションの生成時に割り当てられたものです。
SAMLアイデンティティ・アサータ - SAMLアイデンティティ・アサーション・プロバイダは、SAMLセキュリティ・アサーションのコンシューマとして動作して、シングル・サインオンにSAMLを使用するための宛先サイトとしてWebLogic Serverが動作することを可能にします。SAMLアイデンティティ・アサーション・プロバイダは、ソース・サイトまたはリソースから取得された認証済サブジェクトのために、有効なSAML 1.1アサーションを処理します。
アサーション・コンシューマ・サービス(ACS) - ITSが生成したアサーションまたはアーティファクト(あるいはその両方)を受信して、宛先サイトでユーザーを認証するためにそれらを使用するアドレス可能なコンポーネント。
SAMLリライイング・パーティ - SAMLリライイング・パーティは、SAMLソース・サイトが生成したSAMLアサーションの情報に依存するエンティティです。WebLogic Serverが各リライイング・パーティ用にSAMLアサーションを別個に生成する方法を構成することも、アサーションの生成用にフェデレーション・サービスのソース・サイト構成で設定されたデフォルトを使用することもできます。
SAMLアサーティング・パーティ - SAMLアサーティング・パーティは、信頼できるSAML認証局(SAMLアサーションの形式でセキュリティ情報をアサートする権限を持つエンティティ)です。
図31-24は、WebCenter PortalとSOAドメインの両方を含む、POSTが構成されたSAML SSO構成のコンポーネントとフローを示しています。このフローは、ワークリスト・アプリケーションやディスカッションのようなシングル・サインオンに参加する他の宛先アプリケーションの場合と似ています。
図31-24 詳細なSAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)
図31-25は、Spacesとディスカッション・アプリケーションの間のSAML SSOフローを含む、POSTが構成されたSAML SSO構成の簡略化されたバージョンのコンポーネントとフローを示しています。
図31-25 SAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)
フローの手順は次のとおりです。
ユーザーのブラウザが、ユーザーの資格証明を入力して、WebCenter Portalドメイン(wc_domain
)のWebLogic管理対象サーバー(WC_Spaces
)上にホストされているSpaces(ソース・サイト)にアクセスします。
Spacesが、認証サービス・プロバイダにユーザーの資格証明を渡します。
認証に成功すると、認証されたセッションが確立されて、Spacesのようこそページが表示されます。
ユーザーがようこそページで、同じドメインの異なるWebLogic Server(WC_Collaboration
)上にホストされているディスカッション・サービス(宛先サイト)のセキュアなWebページにアクセスするためのリンクをクリックします。これによって、構成されているサイト間転送サービス(ITS)サーブレットへのコールがトリガーされます。この場合は、ITSサーブレットが、Spacesと同じJSESSIONID Cookieを共有するソース・サイト内(つまり、WC_Spaces
管理対象サーバー上のSpacesアプリケーション上)にホストされます。
ITSサーブレットが、コール元アサーションをリクエストするために、WebCenter Portalドメイン(wc_domain
)に構成されたSAML資格証明マッパーをコールします。SAML資格証明マッパーがアサーションを返します。また、宛先サイト・アプリケーションWebページ(ディスカッション・サービスのセキュアなWebページ)のURLと適切なPOSTフォームのパス(POSTプロファイルを使用するようにソース・サイトが構成されている場合)も返します。
SAML ITSサーブレットが、生成されたアサーションを含むSAMLレスポンスを生成し、それに署名して、BASE64にエンコードし、HTMLフォームに埋め込んで、そのフォームをユーザーのブラウザに返します。
ユーザーのブラウザがそのフォームを宛先サイトのアサーション・コンシューマ・サービス(ACS)にPOSTします。この場合は、ACSサーブレットが宛先サイト(ディスカッション・サービス)にホストされ、そのログインCookieを共有します。
アサーションが検証されます。
アサーションに成功すると、ユーザーがターゲット(ディスカッション・サービスのセキュアなWebページ)にリダイレクトされます。
ユーザーは再認証の必要なしで宛先サイトのディスカッション・サービスにログインします。
この項では、一連の自動化されたスクリプトを使用して、SAMLベースのシングル・サインオンのためにSpacesとサービスを構成する方法を説明します。
この項の内容は次のとおりです。
この項では、SAMLベースのシングル・サインオンを構成する前に実行する必要がある一連の手順を説明します。これらの手順では、Spacesと関連付けられたコンポーネントがインストール済で、関連する接続が構成およびテスト済であることを前提としています。
SAMLベースのSSOの前提条件について、次の項で説明します。
WebCenter PortalでContent Serverユーザー・インタフェースを表示するためにOHSを使用する必要があるドキュメント接続をインスタンスが使用する場合は、WebCenter Portalと関連アプリケーションをWeb層を使用して構成する必要があります。
Content Serverを含む構成用にSAML SSOを構成する際は、すべてのHTTP URLはWeb層ホストおよびポートをポイントすることが必要です。さらに、Content ServerのフロントエンドとしてOHSを使用する場合は、WebCenter Portalの通常の構成とは別に、次のエントリをmod_wl_ohs.conf
に指定する必要があります。
<Location /cs> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location> <Location /adfAuthentication> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location> <Location /samlacs/acs> SetHandler weblogic-handler WebLogicHost ucm.example.com WebLogicPort 16200 </Location>
OHSのインストールとmod_wl_ohs.conf
の編集に関する詳細は、第31.2.5項「Oracle HTTP Serverのインストールと構成」を参照してください。
さらに、Spacesにカスタム・ログイン・ページを使用する場合、Site Studio Designerを動作させるためには、Content Server用に生成されるHTMLページのheadセクションに次のHTMLコメントを追加する必要があります。
<!--IdcClientLoginForm=1-->
このHTMLコメントは、Spacesのデフォルト・ログイン・ページに表示されますが、SAML SSOのセットアップでログイン・ページとして新しいページを構成する場合は、手作業でコメントを追加することが必要になります。つまり、JSFページの次の例に示されているように、生成されたHTMLに追加します。
<af:document id="d1"> <f:facet name="metaContainer"> <f:verbatim> ${cb.commentText} </f:verbatim> </f:facet> .........
cb
は、次のメソッドを含むマネージドBeanです。
public String getCommentText(){ return "<!--IdcClientLoginForm=1-->"; }
af:document
のmetaContainer
facetのverbatimにcomment textが追加されたことをチェックしたら、View Sourceを使用して生成されたHTMLページをチェックして、<!--IdcClientLoginForm=1-->
がHTMLページの<head>
セクションにあることを確認します。
デフォルトでは、Oracle WebCenter Portalのディスカッション・サーバー用にデプロイされる.EARファイルは、フォームベースのOracle SSOまたはOracle Access Manager SSOをサポートします。したがって、Oracle WebCenter Portalのディスカッション・サーバーをSAMLベースのシングル・サインオン用に構成する前に、SAML SSOバージョンのディスカッション・サーバーの.EARファイルをデプロイすることが必要になります。
注意: SSO用のディスカッション・サーバーを構成する前に、第29.1項「外部LDAPサーバーへのアイデンティティ・ストアの再関連付け」の説明に従って、Spacesと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。デフォルトの管理者アカウントを外部LDAPに移動しない場合は、第29.5.1項「外部LDAPを使用するためのWebCenter Portalのディスカッション・サーバーの移行」の手順にも従ってください。 |
SAML SSOバージョンのOracle WebCenter Portalのディスカッション・サーバーをデプロイおよび構成する手順は次のとおりです。
WebLogic Serve管理コンソールに管理者としてログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「デプロイメント」をクリックします。
デプロイメントのサマリー・ペインが表示されます(図31-26を参照)。
デプロイメントのサマリー・ページで、owc_discussions stop and delete
を選択して「インストール」をクリックします。
アプリケーション・インストール・アシスタントの「パス」フィールドを使用して、SSO対応のowc_discussions .EARファイル(owc_discussions_samlsso.ear
、通常は$WC_ORACLE_HOME/discussionserver
にあります)を見つけます。
owc_discussions_samlsso.ear
ファイルを選択して「次へ」をクリックします。
「このデプロイメントをアプリケーションとしてインストールする」を選択して「次へ」をクリックします。
「名前」をowc_discussions
に設定します。
.EARファイルをデプロイします。
ディスカッション・サーバー管理コンソールに管理者としてログインします(ディスカッション・サーバー管理コンソールへのログインに関する詳細は、第31.2.6.2項「SSO用のディスカッション・サーバーの構成」を参照してください)。
「システム・プロパティ」ページを開き、owc_discussions.sso.mode
プロパティを追加または編集(すでに存在している場合)して、その値をtrue
に設定します。
(ディスカッション・サーバーがデプロイされた)WC_Collaboration
管理対象サーバーを再起動します。
SAMLのソース・サイトと宛先サイト間の通信を保護するために、通信を暗号化する必要があります。さらに、証明書を使用して、SAMLの対話時に他のパーティのアイデンティティを検証することが必要です。次の手順に従ってkeytool
ユーティリティ(JDK 6.0の一部として利用可能)を使用してキーを生成し、WebLogic Server管理コンソールを使用してそれを登録してください。
keytoolを使用して証明書を作成する手順は次のとおりです。
WebCenter PortalドメインのWC_Spaces
と管理サーバーのための必要なキーストアを構成します。このキーストアには、SAMLアサーションを保護するために使用する証明書が含まれることが必要です。
構成のテストのみを行いたい場合は、デフォルトで構成されるDemoIdentity
キーストアにパッケージされるdemoidentity証明書を作成するか、keytool
を使用してDemoIdentity
キーストアに新しい証明書を生成することができます。カスタムIDキーストアの構成に関する詳細は、第33.1.2項「カスタムIDキーストアおよびJava信頼キーストアの構成」を参照してください。
keytool
を使用して、SAMLアサーションの暗号化に使用するために選択した証明書をエクスポートします。必ずSpacesドメインの管理サーバーとWC_Spaces
に対して構成されたキーストア上でexport
コマンドを実行するようにしてください。
keytool -export -keystore <keystore_name> -storepass <keystore_password> -alias <certificate_alias> -keypass <certificate_password> -file <certificate.der>
各要素の意味は次のとおりです。
keystore_name
は、Spacesドメインの管理サーバーとWC_Spaces
に対して構成されたキーストアの名前
keystore_password
は、Spacesドメインの管理サーバーとWC_Spaces
に対して構成されたキーストアのパスワード
certificate_alias
は別名(例: demoidentity
)
certificate_password
は証明書のパスワード
certificate.der
は証明書ファイルの名前
keytool -export
コマンドはSpacesマシンから実行する必要があることと、Spacesサーバーに構成されたキーストアに常駐するSAML SSOのセットアップで使用されている証明書をエクスポートする必要があることに注意してください。
(SOA、Content Serverおよびコラボレーションなどの)宛先ドメインにファイルをコピーまたは転送し、第31.4.2.2.1項「シングル・サインオンのスクリプト」で説明されているSAML SSOスクリプトを実行する準備が整ったら、wcsamlsso.properties
ファイルのcertPath
値を構成します。
トランスポートレベルのセキュリティを提供するためにWebCenter PortalのインストールでSSLを必要とする場合は、第33章「SSLの構成」で説明されているようにシングル・サインオンを構成する前にSSLを構成する必要があります。SSLのセットアップはSSOの有効化とは無関係であることに注意してください。
Spacesと環境に必要なサービスをインストールしたら、この項で説明されているスクリプトを使用してSAMLベースのシングル・サインオンを構成します。
このスクリプトでは、次を構成することで、WebLogic環境にSAMLベースのシングル・サインオンをセットアップします。
SAML資格証明マッピング・プロバイダ
必要なリライイング・パーティ
ソース・サイトのフェデレーション・サービス
SAMLアイデンティティ・アサータ
必要なアサーティング・パーティ
宛先サイトのフェデレーション・サービス
この項の内容は次のとおりです。
Spacesおよび関連するアプリケーション用にSAML 1.1 SSOを構成するためのシングル・サインオン・スクリプトは、$WC_ORACLE_HOME/webcenter/scripts/samlsso
フォルダに格納されています。SAMLの構成に関係するのは、次のファイルです。
wcsamlsso.properties
このプロパティ・ファイル($WC_ORACLE_HOME/common/bin/wcsamlsso.properties
)は、SAML SSOのセットアップに必要な構成情報をカプセル化します。プロパティ・ファイルには次のセクションがあります。
spaces_config
このセクションでは、資格証明マッパーおよびソース・サイト・フェデレーション・サービスの構成に必要なWebCenter Portalドメインのログイン情報、WebLogic管理URL、SpacesサーバーおよびURLなどをキャプチャします。このセクションのすべてのプロパティを指定する必要があります。
configFile
- WebCenter Portalドメイン用のweblogicユーザー・アカウントとパスワードを含む構成ファイル
keyFile
- WebCenter Portalドメイン用のweblogicユーザー・アカウントとパスワードを復号化するためのキー・ファイル
adminURL
- WLSTに接続するためのWebLogic管理URL
usesSSL
- SSLを使用するようにSpacesが構成されているかどうかを示します。
url
- WebCenter Portal URL。usesSSL
がtrue
の場合は、http
をhttps
に変更してください。SpacesのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
serverName
- Spacesがデプロイされているサーバー(通常はWC_Collaboration
)
certAlias
- SAMLアサーションに署名する証明書の別名
certPassword
- SAMLアサーションに署名する証明書の暗号化されたパスワード
collab_config
このセクションでは、アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスの構成に必要なコラボレーション・ドメインのログイン情報、管理URL、証明書ファイル・パスなどをキャプチャします。セットアップでディスカッションが構成されている場合のみ、このセクションを指定してください。
configFile
- サービス・ドメイン用のweblogic
ユーザー・アカウントとパスワードを含む構成ファイル
keyFile
- サービス・ドメイン用のweblogic
ユーザー・アカウントとパスワードを復号化するためのキー・ファイル
adminURL
- WLSTに接続するためのWebLogic管理URL
usesSSL
- SSLを使用するようにディスカッション・サービスが構成されているかどうかを示します。
serverName
- ディスカッションがデプロイされているサーバー(通常はWC_Collaboration
管理対象サーバー)
certAlias
- SAMLアサーションを確認するための証明書の別名
certPath
- SAMLアサーションを確認するためのエクスポート済証明書のパス。証明書のパスは、ドメインをホストしているマシン上の有効なパス(つまり、adminURL
で指定されているパス)である必要があります。
utilities_config
このセクションでは、アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスの構成に必要なユーティリティ・ドメインのログイン情報、管理URLおよび証明書ファイル・パスをキャプチャします。このセクションは、セットアップでアクティビティ・グラフ・アプリケーションが構成されている場合のみ指定してください。
configFile
- ユーティリティ・ドメイン用のweblogic
ユーザー・アカウントとパスワードを含む構成ファイル
keyFile
- ユーティリティ・ドメイン用のweblogic
ユーザー・アカウントとパスワードを復号化するためのキー・ファイル
adminURL
- WLSTに接続するためのWebLogic管理URL
usesSSL
- SSLを使用するようにユーティリティ・アプリケーションが構成されているかどうかを示します。
serverName
- ユーティリティ・アプリケーションがデプロイされているサーバー(通常はWC_Utilities
管理対象サーバー)
certAlias
- SAMLアサーションを確認するための証明書の別名
certPath
- SAMLアサーションを確認するためのエクスポート済証明書のパス。証明書のパスは、ドメインをホストしているマシン上の有効なパス(つまり、adminURL
で指定されているパス)である必要があります。
soa_config
このセクションでは、アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスの構成に必要なSOAドメインのログイン情報、管理URL、証明書ファイル・パスなどをキャプチャします。セットアップでSOAが構成されている場合のみ、このセクションを指定してください。
configFile
- SOAドメイン用のweblogic
ユーザー・アカウントとパスワードを含む構成ファイル
keyFile
- SOAドメイン用のweblogic
ユーザー・アカウントとパスワードを復号化するためのキー・ファイル
adminURL
- WLSTに接続するためのWebLogic管理URL
usesSSL
- SSLを使用するようにSOAアプリケーションが構成されているかどうかを示します。
serverName
- SOAアプリケーションがデプロイされているサーバー(通常はsoa_server1
)
certAlias
- SAMLアサーションを確認するための証明書の別名
certPath
- SAMLアサーションを確認するためのエクスポート済証明書のパス。証明書のパスは、ドメインをホストしているマシン上の有効なパス(つまり、adminURL
で指定されているパス)である必要があります。
ucm_config
このセクションでは、アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスの構成に必要なContent Serverドメインのログイン情報、管理URL、証明書ファイル・パスなどをキャプチャします。インストールでドキュメント・サービスが構成されている場合のみ、このセクションを指定してください。
configFile
- Content Server(UCM)ドメイン用のweblogicユーザー名とパスワードを含む構成ファイル
usesSSL
- SSLを使用するようにContent Serverアプリケーションが構成されているかどうかを示します。
keyFile
- Content Server(UCM)ドメイン用のweblogic
ユーザー・アカウントとパスワードを復号化するためのキー・ファイル
adminURL
- WLSTに接続するためのWebLogic管理URL
serverName
- Content Serverアプリケーションがデプロイされているサーバー(通常はUCM_server1
)
certPath
- SAMLアサーションを確認するためのエクスポート済証明書のパス。証明書のパスは、ドメインをホストしているマシン上の有効なパス(つまり、adminURL
で指定されているパス)である必要があります。
rss_config
これは必須です。
url
- RSS URL。spaces_config内のusesSSL
がtrue
である場合は、http
をhttps
に変更します。RSSのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
rest_config
このセクションは指定する必要があります。
url
- REST URL。spaces_config内のusesSSL
がtrue
である場合は、http
をhttps
に変更します。RESTのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
forum_config
構成にディスカッションがインストールされている場合は、このセクションを指定してください。
url
- OWCディスカッションURL。collab_configのusesSSL
がtrue
の場合は、http
をhttps
に変更してください。ディスカッションのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
worklist_config
Spaces用にSOAがインストールされ、ワークリストが構成されている場合は、このセクションを指定してください。
worklist_detail
- ワークリスト詳細アプリケーションURL。soa_config内のusesSSL
がtrue
である場合は、http
をhttps
に変更します。ワークリスト詳細アプリケーションのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
worklist_sdp
- ワークリストSDPアプリケーションURL。soa_config内のusesSSL
がtrue
である場合は、http
をhttpsに変更します。ワークリスト詳細アプリケーションのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
worklist_integration
- ワークリスト統合アプリケーションURL。soa_config内のusesSSL
がtrue
である場合は、http
をhttpsに変更します。ワークリスト詳細アプリケーションのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
activitygraph_config
構成にユーティリティ・サーバーがインストールされている場合は、このセクションを指定してください。
url
- ActivityGraphEngines URL。spaces_config内のusesSSL
がtrue
である場合は、http
をhttps
に変更します。アクティビティ・グラフ・アプリケーションのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
cs_config
構成にContent Serverがインストールされており、Spacesアプリケーション用にドキュメント・サービス接続が構成されている場合は、このセクションを指定してください。
url
- Content Server URL。spaces_config内のusesSSL
がtrue
である場合は、http
をhttps
に変更します。Content ServerのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。環境にSpacesとContent Serverの両方が構成されている場合は、同じWeb層を使用して両方にアクセスする必要があります。
wcsamlsso.py
残りの構成スクリプトによって呼び出されるユーティリティ関数を含むスクリプト・ファイル($WC_ORACLE_HOME/common/wlst/wcsamlsso.py
)
configureSpaces.py
SAML 1.1資格証明マッパー、SAML 1.1アイデンティティ・アサータおよびソースならびに宛先サイト・フェデレーション・サービスをWebCenter Portalドメインに構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureSpaces.py
)
configureCollab.py
SAML 1.1アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスをコラボレーション・ドメインに構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureCollab.py
)
configureUtilities.py
SAML 1.1アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスをユーティリティ・ドメインに構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureUtilities.py
)
configureSOA.py
SAML 1.1アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスをSOAドメインに構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureSOA.py
)
configureUCM.py
SAML 1.1アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスをContent Serverドメインに構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureUCM.py
)
configureREST.py
RESTアプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureREST.py
)
configureRSS.py
RSSアプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureRSS.p
y
)
configureForum.py
ディスカッション・アプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureForum.p
y
)
configureActivityGraphEngine.py
アクティブ・グラフ・エンジン・アプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureActivityGraphEngine.py
)
configureWorklistIntegration.py
ワークリスト統合アプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistIntegration.py
)
configureWorklistDetail.py
ワークリスト・コミュニティ詳細アプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistDetail.py
)
configureWorklistSDP.py
ワークリストSDPアプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistSDP.py
)
configureCS.py
Content Serverアプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureCS.py
)
SAMLベースのシングル・サインオンを構成するスクリプトを使用する手順は次のとおりです。
注意: スクリプトの実行中に構成ミスによるエラーが発生した場合、SAML SSO構成は未完了の状態で終了する可能性があります。提供された構成スクリプトを再実行できない場合は、第31.4.2.6項「SAML SSO構成の削除」の説明に従って、構成を再試行する前にSAML SSOアーティファクトをクリーンアップする必要があります。 |
この構成で使用されるすべてのドメインの管理サーバーが稼働中であることを確認してください。
プロパティ・ファイルが選択されるように、$WC_ORACLE_HOME/common/bin
からstoreUserConfig
WLSTコマンドを使用して、様々なドメインの接続情報を含む構成ファイルとキー・ファイルを生成します。使用方法と構文の詳細は、コマンド・ラインのヘルプ(help('storeUserConfig'))
を使用してください。
WLSTを使用し、管理ユーザー名とパスワードを使用してWebCenter Portalドメインに接続し、次のコマンドを実行します。
storeUserConfig('spacesconfig.secure', 'spaceskey.secure')
これによってユーザー構成ファイルと関連するキー・ファイルが作成されます。ユーザー構成ファイルには、暗号化されたユーザー名とパスワードが含まれます。キー・ファイルには、ユーザー名とパスワードの暗号化と復号化に使用される秘密鍵が含まれます。前述のコマンドは、構成ファイルとキー・ファイルを、WLSTが呼び出されたディレクトリに格納します。または、オプションでより安全なパスを指定することもできます。
管理ユーザー名とパスワードを使用してコラボレーション・ドメインに接続した後で、手順2aを繰り返します。ユーティリティ・サーバーがSpacesと同じドメイン(wc_domain
)内にある場合でも、WebCenter Portalドメインに接続し、このコマンドを実行する必要があります。
storeUserConfig('collabconfig.secure', 'collabkeykey.secure')
管理ユーザー名とパスワードを使用してユーティリティ・ドメインに接続した後で、手順2aを繰り返します。ユーティリティ・サーバーがSpacesと同じドメイン(wc_domain
)内にある場合でも、WebCenter Portalドメインに接続し、このコマンドを実行する必要があります。
storeUserConfig('utilitiesconfig.secure', 'utilitieskey.secure')
管理ユーザー名とパスワードを使用してSOAドメインに接続した後で、手順2aを繰り返します。Spacesと同じドメインにSOAがインストールされていても、WebCenter Portalドメインに接続してこのコマンドを実行する必要があります。
storeUserConfig('soaconfig.secure', 'soakey.secure')
管理ユーザー名とパスワードを使用してContent Serverドメインに接続した後で、手順2aを繰り返します。
storeUserConfig('ucmconfig.secure', 'ucmkey.secure')
WLSTを起動してWLST encrypt
コマンドを実行し、証明書パスワードを暗号化します。使用方法と構文の詳細は、コマンド・ラインのヘルプ(help('encrypt')
)を使用してください。
print encrypt(obj='<certificatePassword>', domainDir='<full path to the Spaces domain directory>')
これによって、暗号化された証明書パスワードが表示されます。暗号化コマンドは、指定されたWebLogic Serverドメイン・ルート・ディレクトリに暗号化を使用します。暗号化された出力は、次の手順に出てくるwcsamlsso.properties
でcertPassword
値として設定する必要があります。このパスワードはWebCenter Portalドメインの資格証明マッパーとソース・サイト・フェデレーション・サービスに設定され、確実にWebCenter Portalドメインから暗号化ユーティリティが実行されるようになります。
$WC_ORACLE_HOME/common/bin/wcsamlsso.properties
を編集して、セットアップに適用されるセクションを指定します。プロパティ・ファイルのセクションの詳細な説明は、第31.4.2.2.1項「シングル・サインオンのスクリプト」を参照してください。
$WC_ORACLE_HOME/common/bin
からWLSTを起動して、次に示された順番でスクリプトを実行します。
注意: スクリプトには明示的な接続コマンドが含まれているので、スクリプトはWLSTオフライン・モードで実行してください。 |
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureSpaces.py')
WebCenter Portalドメインの管理サーバーを含むすべてのサーバーを再起動します。
ディスカッション・サーバーをセットアップしてある場合は、configureCollab.py
スクリプトを実行します。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureCollab.py')
ディスカッションがSpacesと同じドメインに属している場合は、WC_Collaboration
管理対象サーバーのみを再起動します。そうでない場合は、コラボレーション・ドメインの管理サーバーを含むすべてのサーバーを再起動します。
ユーティリティ・サーバーをセットアップしてある場合は、configureUtilities.py
スクリプトを実行します。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureUtilities.py')
ユーティリティ・サーバーがSpacesと同じドメインに属している場合は、WC_Utilities
サーバーのみを再起動します。そうでない場合は、ユーティリティ・ドメインの管理サーバーを含むすべてのサーバーを再起動します。
Spacesのワークリストを構成してある場合は、configureSOA.py
スクリプトを実行します。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureSOA.py')
SOAドメインの管理サーバーを含むすべてのサーバーを再起動します。
Spacesにドキュメント・サービスを構成してある場合は、次のようにconfigureUCM.py
スクリプトを実行します。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureUCM.py')
Content Serverドメインの管理サーバーを含むすべてのサーバーを再起動します。
環境の必要に応じて次の個々のコマンドを実行します。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureREST.py')
- 再起動は不要です。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureRSS.py')
- 再起動は不要です。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureForum.py')
- セットアップにディスカッションがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureActivityGraphEngine.py')
- セットアップにユーティリティがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureWorklistIntegration.py')
- セットアップにワークリストがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('wc_oracle_home>/webcenter/scripts/samlsso/configureWorklistDetail.py')
- セットアップにワークリストがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureWorklistSDP.py')
- セットアップにワークリストがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureCS.py')
- セットアップにContent Serverがインストールされている場合はこれを行ってください。再起動は必要ありません。
第31.4.2.4項「構成のチェック」の手順を使用して、インストールをチェックします。
重要: プロパティ・ファイルには機密情報が含まれているので、SAML SSOセットアップの構成および検証後に |
注意: スクリプトの実行中にエラーが発生した場合は、第31.4.2.6項「SAML SSO構成の削除」の説明に従ってスクリプトを再度実行する前にスクリプトによってセットアップされたアサーティングおよびリライイング・パーティを削除する必要があります。 古いSAML SSO構成を削除したら、スクリプトを再実行してください。 |
デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護された状態では、外部リーダーでRSSフィードがうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できるWebLogic ServerのBASIC認証によってRSSサーブレットの認証が処理されるように、WebCenter Portal RSSリソースを非保護にすることをお薦めします。
次の手順に従って、RSSフィードを非保護にします。
SpacesドメインのWLS管理コンソールにログオンします。
セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択します。
RSSのリライイング・パーティを無効化または削除します。
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択します。
RSSのアサーティング・パーティを無効化または削除します。
次の手順に従って、シングル・サインオン構成が正しく動作することをチェックします。
シングル・サインオン構成をテストする手順は次のとおりです。
新しいブラウザを使用して、Spacesにログインし、「スペース設定」→「サービス」→「ディスカッション」の「フォーラム管理」をクリックしても、資格証明についてチャレンジされないことをチェックします(このサービスがスペース用にプロビジョニングされていると仮定します)。
ディスカッションまたはワークリスト・タスク・フローからRSSリンクにアクセスして、ログインのためにチャレンジされないことをチェックします。
Content Serverについては、プロファイル・ユーザー・インタフェースに移動して、ログインへのチャレンジなしでiFramesに埋め込まれたContent Server画面を表示できることを確認します。また、すでにSpacesにログインしているので、ログインへのチャレンジなしでコンテンツ・プレゼンタ・テンプレートでSite Studioのコンテンツにアクセスできるはずです。
http://host:port/rest/api/resourceIndex
にアクセスし、BASIC認証チャレンジが表示されることを確認します。同じSSOを使用する別の関連アプリケーションにすでにログインしている場合は、ログインへのチャレンジなしでコンテンツを表示できるはずです。
SOAをテストするには、ワークフロー・タスク・フローのリンクにアクセスして、ログインをチャレンジされないことを確認します。
SAML SSOのテスト中に404または403エラーが発生した場合は、SAML構成をチェックして、AdminServer
上でSAMLのデバッグ・ロギングをオンにしてください。また、WC_Spaces
サーバーと宛先サイトをホストするサーバーのロギングもオンにしてください。ログは、$domain.home/servers/<server>/logs/<server>.log
に格納されます。WC_Spaces
および他のアプリケーション・サーバーのロギングをオンにする方法は、第38.3項「ログ情報の表示および構成」を参照してください。スクリプトを再実行する前に、第31.4.2.6項「SAML SSO構成の削除」の説明に従ってSAML SSO構成を削除してください。
この項では、テストなどのためにSAML SSO構成を一時的に無効にする方法を説明します。
SAML SSO構成を無効にする手順は次のとおりです。
SpacesドメインのWLS管理コンソールにログオンします。
セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択し、そこに示されたリライイング・パーティをすべて無効にします。
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて無効にします。
SOAやContent Serverなど、SAML SSOで構成されている他のWLSドメインがある場合は、それらのドメインからもSAML SSO構成を削除します。
WLSドメインのWLS管理コンソールにログインします。
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて無効にします。
アプリケーションを開き、サインインを要求されないことをチェックして、SAML SSO構成が無効になっていることを確認します。
SAML SSO構成スクリプトにはクリーンアップ機能は含まれていないので、wcsamlsso.properties
ファイルの更新中やスクリプトの実行中にミスをすると、構成は無効な状態になる可能性があります。この場合は、ここですべてのSAML SSO構成をクリーンアップして、もう一度やりなおすことをお薦めします。この項では、SAML SSO構成を削除する手順を説明します。
SAML SSOを完全にセットアップした場合(つまり、スクリプトが完全に実行された場合)は、次のすべての指示が有効になることに注意してください。ただし、スクリプトの実行中にエラーが発生すると、構成は不完全なものになる可能性があります。その場合は次のアーティファクトの一部のみが存在し、削除することが必要になります。
SAML SSO構成を削除する手順は次のとおりです。
SpacesドメインのWLS管理コンソールにログオンします。
セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択し、そこに示されたリライイング・パーティをすべて削除します。
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて削除します。
「プロバイダ」→「認証」→「wcsamlia」→「管理」→「証明書」に移動し、そこで証明書をすべて削除します。
「プロバイダ」→「資格証明マッピング」→「wcsamlcm」に移動して、SAML資格証明マッパーを削除します。
「プロバイダ」→「認証」→「wcsamlia」に移動し、SAMLアイデンティティ・アサータを削除します。
Spaces WLSドメイン全体を再起動します。
SOAやContent Serverなど、SAML SSOで構成されている他のWLSドメインがある場合は、それらのドメインからもSAML SSO構成を削除します。
WLSドメインのWLS管理コンソールにログインします。
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて削除します。
「プロバイダ」→「認証」→「wcsamlia」→「管理」→「証明書」に移動し、そこで証明書をすべて削除します。
「プロバイダ」→「認証」→「wcsamlia」に移動し、SAMLアイデンティティ・アサータを削除します。
WLSドメイン全体を再起動します。
アプリケーションを開き、サインインを要求されないことをチェックして、SAML SSO構成が削除されていることを確認します。これで、スクリプトを再度安全に使用して、SAML SSOを再構成できます。
この項では、SPNEGO(Simple and Protected Negotiate)メカニズムとKerberosプロトコルに基づくWindows認証とSpacesアプリケーション用のWebLogicネゴシエート・アイデンティティ・アサーション・プロバイダを使用して、Microsoftクライアントでのシングル・サインオン(SSO)をセットアップする方法について説明します。このSSOアプローチによって、Kerberosを使用してWindowsドメイン内で認証されたMicrosoftクライアント(ブラウザなど)は、パスワードを再入力する必要なしで、同じ資格証明に基づいて、WebLogicドメイン内のWebアプリケーション(Spacesなど)に対して透過的に認証されることが可能になります。
クロスプラットフォーム認証は、Kerberosプロトコルを使用したネイティブのWindows間認証サービスのネゴシエート動作をエミュレートすることで達成されます。クロスプラットフォーム認証を有効にするためには、非Windowsサーバー(この場合はWebLogic Server)は、認証に使用されるKerberosトークンを抽出するためにSPNEGOトークンを解析する必要があります。
この項の内容は次のとおりです。
Kerberosの概要
Kerberosは、ネットワークのサービスに対するリクエストを認証するための安全な方法です。Kerberosプロトコルは、クライアント、サーバーおよびそれらを仲介するKDC(Key Distribution Center)という信頼できるサード・パーティの3つのパーティから構成されます。Kerberosでは、ユーザーがそのアイデンティティを証明するKerberosチケットをサーバーに提供できる場合は、サーバーはユーザーがそのサービスにアクセスすることを許可します。ユーザーとサービスの両方が、KDCに登録された鍵を持つ必要があります。
次の図は、クライアントがサーバーに接続する前に行われる必要がある基本的なやり取りを示しています。
SPNEGOの概要
SPNEGO(Simple and Protected GSSAPI Negotiation Mechanism)は、いくつかの可能な現実のメカニズムの1つをネゴシエートするために使用されるGSSAPI疑似メカニズムです。SPNEGOは、クライアント・アプリケーションがリモート・サーバーに対して認証したい場合に、どちらのエンドも他方がサポートする認証プロトコルがわからない場合に使用されます。この疑似メカニズムでは、あるプロトコルを使用して利用可能な共通のGSSAPIメカニズムを判断して選択し、強化されたセキュリティ操作をすべてそれにディスパッチします。このため、組織は新しいセキュリティ・メカニズムを段階的にデプロイできます。
SPNEGOは、MicrosoftのHTTP Negotiate認証拡張での使用が最も目立っています。ネゴシエート可能なサブメカニズムにはNTLMとKerberosがあり、両方ともActive Directoryで使用されています。
この機能によってクライアント・ブラウザは、WebLogic Server上の保護されたリソースにアクセスし、SPNEGOチケットを使用してKerberosデータベースの認証情報をWebLogic Serverに透過的に提供することができます。WebLogic Serverはチケットを認識して、そこから情報を抽出できます。そしてWebLogic Serverは、その情報を使用して認証を行い、認証されたユーザーがリソースへのアクセスを認可されている場合はリソースへのアクセスを付与します。(Kerberosは認証のみを担当し、認可はWebLogic Serverが処理します。)
MicrosoftクライアントでSSOを使用するには、次が必要です。
次を装備したホスト・コンピュータ:
Windows 2000以降がインストールされていること
完全に構成されたActive Directory認証サービス。具体的なActive Directory要件は次のとおりです。
Kerberosサービスをマッピングするためのユーザー・アカウント
これらのアカウントのサービス・プリンシパル名(SPN)
作成されてWebLogic Serverドメインの起動ディレクトリにコピーされたキー・タブ・ファイル
この項で説明されているように、Kerberosを通して認証するように適切にインストールおよび構成されたWebLogic Server
次を装備したクライアント・システム:
Windows 2000 Professional SP2以降がインストールされていること
次のいずれかのタイプのクライアント:
適切に構成されたInternet Explorerブラウザ。Internet Explorer 6.01以降がサポートされます。
.NET Framework 1.1および適切に構成されたWebサービス・クライアント。
注意: クライアントはWindows 2000ドメインにログオンする必要があり、そのドメインのActive Directoryサーバーから取得されたKerberos資格証明を持つ必要があります。ローカル・ログオンは機能しません。 |
MicrosoftクライアントでSSOを構成するには、図31-29に示されているMicrosoft Active Directory、MicrosoftクライアントおよびWebLogic Serverドメインを構成する必要があります。詳細な構成手順とトラブルシューティングについては、Oracle Fusion Middleware Oracle WebLogic Serverの保護のMicrosoftクライアントでのシングル・サインオンの構成に関する項を参照してください。
SSO用にMicrosoftクライアントを構成する手順は次のとおりです。
Kerberosを使用するようにネットワーク・ドメインを構成します。
WebLogic Server用のKerberos識別情報を作成します。
WebLogic Serverを実行中のホストのActive Directoryにユーザー・アカウントを作成します。
このアカウントのサービス・プリンシパル名を作成します。
このアカウントのユーザー・マッピングとキータブ・ファイルを作成します(Oracle Fusion Middleware Oracle WebLogic Serverの保護のMicrosoftクライアントでのシングル・サインオンの構成に関する項を参照)。
ブラウザ・クライアント(Internet ExplorerまたはMozilla Firefox)を選択し、Windows統合認証を使用するようにそれを構成します(Oracle Fusion Middleware Oracle WebLogic Serverの保護のWindows統合認証を使用するためのMicrosoftクライアントの構成に関する項を参照。)
Kerberos認証を使用するようにWebLogic Serverドメイン(この場合はwc_domain
)をセットアップします。
MicrosoftドメインのActive Directoryサーバーと手順2で作成したキータブ・ファイルをポイントするJAASログイン・ファイルを作成します(Oracle Fusion Middleware Oracle WebLogic Serverの保護のJAASログイン・ファイルの作成に関する項を参照)。
WebLogic Serverセキュリティ・レルムでネゴシエート・アイデンティティ・アサーション・プロバイダを構成します(第31.5.3.1項「ネゴシエート・アイデンティティ・アサーション・プロバイダの構成」を参照)。
Active Directoryオーセンティケータを使用するようにWebLogic Serverドメインを構成して、WebLogicドメインがアイデンティティ・ストアと同じActive Directoryドメインを使用するようにします。または、別のアイデンティティ・ストアを使用して、このストアのユーザーをドメインのActive Directoryユーザーと照合することもできますが、2つの異なるアイデンティティ・ストアを使用すると同期が失われる危険性があるため、Active Directoryオーセンティケータを使用することをお薦めします(第31.5.3.2項「Active Directory認証プロバイダの構成」を参照)。
注意: アイデンティティ・ストアのみをActive Directory用に構成してください。ポリシーおよび資格証明ストアはActive Directoryに対して認証されません。 |
次のシステム・プロパティを各WebCenter PortalマシンのsetDomainEnv.sh
のJAVA_OPTIONS
に追加します。それぞれの値は、特定のホストの値に変更してください(1行に指定)。
-Dnon_sso_protocol=http -Dnon_sso_host=example.com -Dnon_sso_port=8888 -Dsso_base_url=http://example.com:7777
non_sso
値は、プロトコル、ホストおよびポートについてのマシン上の値です。sso
値は、OHSを通してルーティングされた際にユーザーに表示される値です。
WebCenter Portal: Spacesに対しては、第31.6項「仮想ホストを使用したSSOの構成」の説明に従って、WebCenter Portal用のOracle WebLogic Serverにリクエストを転送するようにWeb層OHSを構成します。
手順5で指定した起動引数を使用して、WebLogic Server(管理サーバーと管理対象サーバー)を再起動します。SOAドメインについて手順4、5および6を繰り返して、SOAアプリケーションのシングル・サインオンを有効にします。
OHSを再起動して変更を有効にします。
ディスカッション・サーバーを構成します(第31.5.3.4項「SSO用のディスカッション・サーバーの構成」を参照)。
この項では、ネゴシエート・アイデンティティ・アサーション・プロバイダの作成および構成手順を説明します。ネゴシエート・アイデンティティ・アサーション・プロバイダによって、Microsoftクライアントのシングル・サインオン(SSO)が可能になります。アイデンティティ・アサーション・プロバイダは、SPNEGO(Simple and Protected Negotiate)トークンをデコードして、Kerberosトークンを取得し、それらのKerberosトークンを検証して、それらをWebLogicユーザーにマップします。ネゴシエート・アイデンティティ・アサーション・プロバイダはJava GSS(Generic Security Service) API(Application Programming Interface)を使用して、Kerberosを通してGSSセキュリティ・コンテキストを受け付けます。
ネゴシエート・アイデンティティ・アサーション・プロバイダを構成する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます(図31-30を参照)。
セキュリティ・レルムをクリックします。
セキュリティ・レルムの設定ページが表示されます(図31-31を参照)。
「プロバイダ」タブを開き、「認証」サブタブを選択します。
認証設定ペインが表示されます(図31-32を参照)。
「新規」をクリックします。
「新しい認証プロバイダの作成」ペインが表示されます(図31-33を参照)。
アイデンティティ・アサータの「名前」を入力し、「タイプ」としてNegotiateIdentityAsserter
を選択します。
「OK」をクリックします。
次の手順に従って、WebLogic管理コンソールを使用してActive Directory認証プロバイダを構成します。
Active Directory認証プロバイダを構成する手順は次のとおりです。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます(図31-34を参照)。
セキュリティ・レルムをクリックします。
セキュリティ・レルムの設定ページが表示されます(図31-35を参照)。
「プロバイダ」タブを開き、「認証」サブタブを選択します。
認証設定ペインが表示されます(図31-36を参照)。
「新規」をクリックします。
「新しい認証プロバイダの作成」ペインが表示されます(図31-37を参照)。
認証プロバイダの「名前」を入力し、「タイプ」としてActiveDirectoryAuthenticator
を選択します。
「OK」をクリックします。
プロバイダのリストで、今作成した認証プロバイダをクリックします。
プロバイダの設定ページが表示されます(図31-38を参照)。
「構成」タブを開き、「共通」サブタブを開きます。
制御フラグをSUFFICIENT
に設定し、「保存」をクリックします。
注意: 他のすべてのオーセンティケータの制御フラグの設定も、 |
「プロバイダ固有」サブタブを開きます。
プロバイダ固有の設定ペインが表示されます(図31-39を参照)。
次の表に示されているように、各フィールドに値を入力します。これら以外のフィールドは、デフォルト値のままにします。
表31-3 Active Directoryオーセンティケータの設定
パラメータ | 値 | 説明 |
---|---|---|
ホスト: |
LDAPサーバーのホストID |
|
ポート: |
LDAPサーバーのポート番号 |
|
プリンシパル: |
LDAP管理者プリンシパル |
|
資格証明: |
||
ユーザー・ベースDN: |
ユーザー検索ベース(例: OU=spnego unit,DC=admin,DC=oracle,DC=com) |
|
名前指定によるユーザー・フィルタ: |
(&(cn=%u)(objectclass=user)) |
|
ユーザー検索スコープ: |
subtree |
|
ユーザー名属性: |
cn |
|
ユーザー検索スコープ: |
user |
|
グループ・ベースDN: |
グループ検索ベース(ユーザー・ベースDNと同じ) |
|
名前指定によるグループ・フィルタ: |
(&(cn=%g)(objectclass=group)) |
|
グループ検索スコープ: |
subtree |
|
静的グループ名属性: |
cn |
|
静的グループ・オブジェクト・クラス: |
group |
|
静的メンバーDN属性: |
member |
|
メンバーDN指定による静的グループDNフィルタ: |
(&(member=%M)(objectclass=group)) |
「保存」をクリックします。
プロバイダのサマリー・ページで、次の順序にプロバイダを並べ替え、それらの制御フラグが適宜SUFFICIENT
に設定されていることを確認します。
ネゴシエート・アイデンティティ・アサータ
ActiveDirectoryAuthenticator (SUFFICIENT
)
DefaultAuthenticator (SUFFICIENT
)
他のオーセンティケータ
ネゴシエート・アイデンティティ・アサーション・プロバイダとActive Directoryオーセンティケータの構成手順を完了し、WebLogicドメインの全アプリケーションと必要なドメインのMicrosoftクライアントをシングル・サインオン用に構成したら、ユーザーがSpacesにアクセスしたときにシームレスなシングル・サインオン・エクスペリエンスを提供するための最終ステップを実行する必要があります。これは次の2通りの方法で実行できます。
管理者としてSpacesにログインし、Public-User
ロールからView
アクセスを削除することで、パブリック・アクセスをオフにします。パブリック・アクセスをオフにすると、URL http://host:port/webcenter
にアクセスしたユーザーには、ログイン・セクションを持つデフォルト・パブリック・ページではなく、認証されたビューが直接表示されます。これは、ユーザーがInternet Explorerのみを使用してSpacesにアクセスし、WNAがセットアップされたドメインに限定されている場合にお薦めします。
Spacesへのパブリック・アクセスを維持する必要がある場合は、WC_Spaces
サーバーを起動する際にoracle.webcenter.spaces.osso=true
フラグを使用することをお薦めします。このフラグはSSOが使用されていることをSpacesに告げるため、デフォルトのランディング・ページにログイン・フォームは表示されなくなります。そのかわりにログイン・リンクが表示され、これをユーザーがクリックするとSSO認証が呼び出されて、ユーザーは自動的にログインできます。Firefoxを使用してWNAに構成されたWindowsネットワーク内でSpacesにアクセスする場合、または任意のブラウザを使用してWindowsネットワーク・ドメイン外からSpacesにアクセスする場合は、ユーザーがログイン・リンクをクリックするとログイン・ページが表示されます。
この項では、シングル・サインオン用のOracle WebCenter Portalのディスカッション・サーバーを構成する方法について説明します。SSO用のディスカッション・サーバーを構成する前に、第29.5.1項「外部LDAPを使用するためのWebCenter Portalのディスカッション・サーバーの移行」の説明に従って、Spacesと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。
SSO用のディスカッション・サーバーを設定する手順は次のとおりです。
Oracle WebCenter Portalのディスカッション・サーバー管理コンソールにログインします。
http://host:port/owc_discussions/admin
host
およびport
は、WC_Collaboration
管理対象サーバーのホストIDとポート番号です。
「システム・プロパティ」ページを開き、owc_discussions.sso.mode
プロパティを編集(存在している場合)または追加します(値をtrue
に設定します)。
この項では、コンテキスト・ルートとして/を使用するアプリケーションを含む環境に必要なOHS構成と、シングル・サインオンが呼び出される際にOHSで必要な追加構成について説明します。
この項の内容は次のとおりです。
WebCenter Portal Suiteには、コンテキスト・ルートとして/を使用するデスクトップ統合アプリケーションが含まれています。シングル・サインオン環境でこのアプリケーションを使用する場合は、OHSを通してこれをルーティングする必要があります。仮想ホストを使用しないでこれを行うために、次のエントリをmod_wl_ohs.conf
に追加することもできます。
<Location /> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location>
ただし、これを行うと、明示的に定義されていないすべてのコンテキスト・ルートが影響を受けます。そのため、仮想ホストが必要になります。
仮想ホストという用語は、1台のマシン上で複数のWebサイト(www.company1.com
とwww.company2.com
など)を実行することを示します。仮想ホストはIPベース(それぞれのWebホストごとに異なるIPアドレスを持つこと)にすることも、名前ベース(各IPアドレスに複数の名前を持つこと)にすることもできます。それらが同じ物理サーバー上で動作しているという事実は、エンド・ユーザーにはわかりません。仮想ホストの詳細は、Apacheのドキュメントを参照してください。
この項では、シングル・サインオン・ソリューションとしてOSSOが構成されている場合に仮想ホストを構成する手順を説明します。これらの手順を行う前に、第31.3項「Oracle Single Sign-On(OSSO)の構成」の手順を完了していることが必要です。
OSSOで仮想ホストを使用するには、パートナ・アプリケーションを仮想ホスト・オプションに登録する必要があります。また、webtier-spaces.example.com
ではシングル・サインオンをバイパスする必要があります。この理由は、BASIC認証のみをサポートするアプリケーションや、シングル・サインオンを必要としないアプリケーションがあるからです。これらの構成について、次の手順で説明します。
mod_osso.conf
ファイルをmoduleconf
からhttpd.conf
と同じ場所に移動します。(moduleconf
内のすべてのファイルはデフォルトで自動的にロードされますが、仮想ホストに対してOSSOを無効にする必要があります。)
次の例に示されているように、httpd.conf
の仮想ホストのセットアップを更新します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName webtier.example.com include mod_osso.conf </VirtualHost> <VirtualHost *:7777> ServerName webtier-spaces.example.com <Location /> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /webcenter> Deny from all </Location> <Location /webcenterhelp> Deny from all </Location> <Location /rest> Deny from all </Location> </VirtualHost>
mod_osso.conf
をデフォルト仮想ホストにインクルードすることで、デフォルト仮想ホスト(webtier.example.com
)にシングル・サインオン・エクスペリエンスを提供します。ただし、一部のアプリケーションはこれをサポートしないため、Spaces仮想ホスト(webtier-spaces.example.com
)にはシングル・サインオン・エクスペリエンスを提供しません。
OHSを再起動します。また、必ずwebtier-spaces.example.com
のエントリを使用してDNSを更新してください。
注意: シングル・サインオンをバイパスする |
仮想ホストにOAM 10gを構成するには、BASIC認証のみをサポートするアプリケーションやシングル・サインオンを必要としないアプリケーションについてシングル・サインオンをバイパスする必要があります。詳細は、10g用のOracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドのWebGateと特定仮想ホスト、ディレクトリまたはファイルの関連付けに関する項を参照してください。
これらの手順を完了する前に、第31.2項「Oracle Access Manager(OAM)の構成」に示されているOAM 10gの構成手順を完了していることが必要です。
httpd.conf
の次の構成を見つけてコメント・アウトします。
#Comment out this and move to VirtualHost configuration #<LocationMatch "/*"> #AuthType Oblix #require valid-user #</LocationMatch>
このエントリがあると、WebGateはすべてのリクエストをインターセプトして処理します。
次の例に示されているように、シングル・サインオンが必要とされる仮想ホスト構成にこのエントリを移動します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName webtier.example.com <LocationMatch "/*"> AuthType Oblix require valid-user </LocationMatch> </VirtualHost> <VirtualHost *:7777> ServerName webtier-spaces.example.com <Location /> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /webcenter> Deny from all </Location> <Location /webcenterhelp> Deny from all </Location> <Location /rest> Deny from all </Location> </VirtualHost>
デフォルト仮想ホスト(webtier.example.com
)にはシングル・サインオン・エクスペリエンスを提供しますが、一部のアプリケーションはこれをサポートしないため、Spaces仮想ホスト(webtier-spaces.example.com
)にはシングル・サインオン・エクスペリエンスを提供しないという考え方です。
OHSを再起動します。さらに、webtier-spaces.example.com
のエントリによるDNSの更新も行ってください。
注意: シングル・サインオンをバイパスする |
仮想ホストにOAM 11gを構成するには、BASIC認証のみをサポートするアプリケーションやシングル・サインオンを必要としないアプリケーションについてシングル・サインオンをバイパスする必要があります。
これらの手順を完了する前に、第31.2項「Oracle Access Manager(OAM)の構成」に示されているOAM 11gの構成手順を完了していることが必要です。
OAM 11gの仮想ホストを構成する手順は次のとおりです。
webgate.conf
の次の構成を見つけてコメント・アウトします。
#Comment out this and move to VirtualHost configuration #<LocationMatch "/*"> #AuthType Oblix #require valid-user #</LocationMatch>
このエントリがあると、WebGateはすべてのリクエストをインターセプトして処理します。
次の例に示されているように、シングル・サインオンが必要とされるhttpd.conf
の仮想ホスト構成にこのエントリを移動します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName webtier.example.com <LocationMatch "/*"> AuthType Oblix require valid-user </LocationMatch> </VirtualHost> <VirtualHost *:7777> ServerName webtier-spaces.example.com <Location /> SetHandler weblogic-handler WebLogicHost webcenter.example.com WebLogicPort 8888 </Location> <Location /webcenter> Deny from all </Location> <Location /webcenterhelp> Deny from all </Location> <Location /rest> Deny from all </Location> </VirtualHost>
デフォルト仮想ホスト(webtier.example.com
)にはシングル・サインオン・エクスペリエンスを提供しますが、一部のアプリケーションはこれをサポートしないため、Spaces仮想ホスト(webtier-spaces.example.com
)にはシングル・サインオン・エクスペリエンスを提供しないという考え方です。
OHSを再起動します。さらに、webtier-spaces.example.com
のエントリによるDNSの更新も行ってください。
注意: シングル・サインオンをバイパスする |
この項では、仮想ホストを通してルーティングされるアプリケーションに必要な追加構成について説明します。
Sharepoint
MS Office製品の単語の編集機能または類似機能を使用すると、通常はWebCenter Portal Sharepointアプリケーションが現在のリクエストからホスト名とポート名を取得します。ただし、この場合、Sharepointアプリケーションは仮想ホストを通してルーティングする必要があり、この仮想ホストでは一部のシステム・プロパティをWebLogicドメインのsetDomainEnv
に設定することが必要とされます。クラスタ・セットアップの場合は、マシンごとに必ずこれらのプロパティを変更してください。
-Dnon_sso_host=webtier-spaces.example.com -Dsso_base_url=http://webtier.example.com:7777
この項では、仮想ホストおよびシングル・サインオン構成のテスト方法を説明します。
Sharepoint
http://webtier.example.com:7777/webcenter
にアクセスして、SSOによってチャレンジされることをチェックします。
ログインしてMS Wordドキュメントを選択し、「単語の編集」をクリックします。確認のダイアログが表示されたら、「OK」をクリックします。WordによってBASIC認証のチャレンジが実行されます。資格証明を入力すると、ドキュメントを表示できます。
Officeアイコン→「サーバー」→「ドキュメント管理情報」に移動して、「サイトをブラウザーで開く」をクリックします。これによって、デフォルト・ブラウザで、ドキュメントが属するスペースが開きます。
MS Officeの統合には、ドキュメントのURLと同じURLに移動する必要があるという制限があるため、BASIC認証チャレンジによって入力が要求されることに注意してください。webtier.example.com
を通してスペースにリダイレクトされて、まだログインしていない場合はログインするように要求されます。