| Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.8.3) E51441-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.8.3) E51441-03 |
|
前 |
次 |
この章では、WebCenter PortalまたはPortal Frameworkアプリケーションで利用できるシングル・サインオン(SSO)ソリューションと各ソリューションの構成方法について説明します。
この章には次の項が含まれます:
|
権限: この章のタスクを実行するには、Oracle WebLogic Server管理コンソールでWebLogic Serverの 第1.8項「管理操作、ロールおよびツールの理解」も参照してください。 |
いくつかのソリューションを使用して、WebCenter PortalおよびPortal Frameworkアプリケーション向けにシングル・サインオンを実装できます。この項では、その利点と推奨アプリケーションを説明します。
オラクル社のエンタープライズ・クラスのアイデンティティ管理およびセキュリティ製品スイートの一部であるOracle Access Manager (OAM)は、WebCenter PortalおよびPortal Frameworkアプリケーション用のいくつかのシングル・サインオン・オプションを含む広範なアイデンティティ管理およびセキュリティ機能を提供します。OAM(特にOAM 11g)は、Oracle WebCenter Portal 11gのインストールに推奨されるシングル・サインオン・ソリューションです。
Oracle 10gインフラストラクチャに投資済のデプロイメント環境で、Oracle Application Server Single Sign-On (OSSO)サーバーがプライマリSSOソリューションとして使用されている場合は、OSSOを使用してシングル・サインオンを提供するようにWebCenter Portal 11gおよびPortal Frameworkアプリケーションを構成することもできます。
Oracle Access ManagerやOracle SSOのようなエンタープライズ・クラスのシングル・サインオン・インフラストラクチャが用意されていない本番以外の開発環境で、WebCenter PortalまたはPortal Frameworkアプリケーション、および関連するWebツール(ディスカッション、ワークリストなど)内でのみシングル・サインオン機能を提供する必要がある場合は、SAMLベースのSSOソリューションを構成できます。他のエンタープライズ・アプリケーションにもシングル・サインオンを提供する必要がある場合は、このソリューションはお薦めできません。
Active Directoryのユーザー・アカウントによってMicrosoftドメイン・コントローラを使用して認証を行うMicrosoftデスクトップ・ログインを使用している場合は、Microsoftのクライアントに対するSSOの構成も検討できます。
Oracle Access Manager (OAM)は、柔軟で拡張可能な認証と認可のほか、監査サービスを提供します。この項では、WebLogicサーバー側およびSSOに参加するパートナ・アプリケーションとしてのWebCenter PortalまたはPortal Frameworkアプリケーションの構成方法を含め、OAMシングル・サインオン認証のためにWebCenter PortalおよびPortal Frameworkアプリケーションを構成する方法を説明します。第34.4項「OAMに対するPortal Frameworkアプリケーションおよびポートレット・プロデューサ・アプリケーションの構成」で説明されているように、Portal Frameworkアプリケーションの場合は、追加の構成がいくつか必要になることに注意してください。
次の項で、OAM 11gおよび10gのインストールおよび構成手順を示します。
図33-1は、WebCenter PortalまたはPortal Frameworkアプリケーション用に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シングル・サインオン・プロセスのフロー
図33-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にリダイレクトされ、さらにWebCenter PortalまたはPortal Frameworkアプリケーションを実行中のWLSサーバーにリダイレクトされて、そこから目的のコンテンツやアプリケーションがユーザーに提供されます。
WebGate→mod_wl→WebCenter PortalまたはPortal Frameworkアプリケーション(ディスカッションなど)→コンテンツが認証されたユーザーに提供されます
認可ポリシーでアクセスが拒否されている場合は、管理者が決定した別のURLにユーザーはリダイレクトされます。
この項のフロー・チャート(図33-3)と表(表33-1)は、OAMを使用してWebCenter PortalまたはPortal Frameworkアプリケーションのシングル・サインオンを構成する際の前提条件と必要なタスクの概要を示しています。
表33-1は、OAMを使用してWebCenter Portalのシングル・サインオンを構成するためのタスクとサブタスクを示しています。
表33-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用のWebCenter Portalの構成 |
||
|
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およびPortal Frameworkアプリケーションに推奨されるシングル・サインオン・ソリューションを説明します。
|
注意: OAMのインストールは、Oracle WebCenter Portalのインストール後(『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』を参照)および環境に必要な他のすべてのコンポーネントのインストール後に実行してください。また、必要な接続も、すべて事前に構成およびテストしてください。 |
この項には次のサブセクションが含まれます:
この項ではOAM 11gのインストールおよび構成方法について説明し、次の内容を含みます。
Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOracle Identity Management (11.1.1.7.0)のインストールと構成に関する項の説明に従って、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 Identity Management (11.1.1.7.0)のインストールと構成に関する項の説明に従って、WebLogic管理ドメインでOracle Access Managerを構成します。
Oracle HTTP Server (OHS)がインストールされていない場合、第33.2.5項「Oracle HTTP Serverのインストールと構成」の説明に従ってOHS (11.1.1.4.0)をインストールします。
既存のインストールがある場合は、『Oracle Fusion Middlewareパッチ適用ガイド』の最新のOracle Fusion Middlewareパッチ・セットの適用に関する項の説明に従ってパッチを適用して、OHS (11.1.1.4.0)にする必要があります。
OHSのインストールまたはパッチ適用が終了したら、第33.2.3.1.3項「Web層でのWebGateのインストール」の説明に従ってWebGateをインストールします。
この項では、OHS WebGateのインストールおよび構成方法について説明します。
|
注意: OHS WebGateのインストール中は必ずOracle HTTP Serverを停止し、第33.2.3.1.4項「WebGateエージェントの登録」の説明に従ってWebGateエージェントを登録した後でのみ再起動してください。 |
Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイドのOAM用のOracle HTTP Server 11g WebGateのインストールと構成に関する項の説明に従って、WebGateをインストールします。OHSのインストール時に指定したものと同じミドルウェア・ホームを使用します。
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)を使用する保護されたポリシーを自動的に作成します。シングル・サインオンのログイン・ページをカスタマイズしたい場合、または他の認証スキームでリソースを保護したい場合は、OAMコンソールを使用してそれを変更してください(詳細は、Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドの「認証スキームの管理」の章を参照)。
|
注意: 環境でWebCenter Portalとともに他のアプリケーションを使用しており、これらのアプリケーションにシングル・サインオンが必要な場合は、これらのアプリケーションで使用される認証スキームが同じであるか、少なくとも同じレベルで、同じアイデンティティ・ストアをポイントしていることが必要です。 |
WebGateエージェントの登録の詳細は、Oracle Fusion Middleware Oracle Access Manager WebGateのインストールのOracle Access Manager用の新しいOracle HTTP Server 11g WebGateエージェントのスタート・ガイドに関する項も参照してください。
次の手順に従って、インバンド・モードでoamregツールを使用して、OAMがインストールされているマシン上でWebGateエージェントを登録します。
ディレクトリを<RREG_Home>/inputに変更します(ここで<RREG_Home>はRREG.tar.gz/rregのコンテンツを抽出したディレクトリです)。
このOracle WebCenter Portalのインストールから$WEBCENTER_HOME/webcenter/scripts/webcenter.oam.confをコピーします。
WEBCENTER_HOMEのデフォルトの場所は$ORACLE_HOME/Oracle_WC1です。
SOAとContent Serverのインストールから、$SOA_HOME/soa/prov/soa.oam.confおよび$WC_CONTENT_ORACLE_HOME/common/security/oam.confをそれぞれコピーします。
SOA_HOMEのデフォルトの場所は$ORACLE_HOME/Oracle_SOA1であり、WC_CONTENT_ORACLE_HOMEのデフォルトの場所は$ORACLE_HOME/Oracle_ECM1です。soa.oam.confに含まれるSOA関連のロケーション・マッピングは、WebCenter Portalで提供されるワークフローをSOAサーバーにデプロイして使用する場合にのみ有効になりますが、SOAが使用されている場合は、webcenter.oam.conf内で保護されているSOA関連のURLも有効になります。
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のリソースを使用してポリシーを更新します。これでポリシーに、Oracle 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層と関連するコンポーネントをインストールおよび構成したら、第33.2.4項「OAM用のWebLogicドメインの構成」の説明に従ってポリシー・マネージャを構成し、第33.2.6項「追加のシングル・サインオン構成」の説明に従って適用される追加のサービスとコンポーネントの構成を実行します。
この項では、OAM 10gのインストールおよび構成方法について説明し、次の内容を含みます。
まだOracle Access Manager (OAM) 10gをインストールしていない場合は、Oracle Access Managerインストレーション・ガイドの説明に従ってOAM 10gをインストールします。
Oracle HTTP Server (OHS)がインストールされていない場合、第33.2.5項「Oracle HTTP Serverのインストールと構成」の説明に従ってOHS (11.1.1.4.0)をインストールします。
既存のインストールがある場合は、『Oracle Fusion Middlewareパッチ適用ガイド』の最新のOracle Fusion Middlewareパッチ・セットの適用に関する項の説明に従ってパッチを適用して、OHS (11.1.1.4.0)にする必要があります。
OHSのインストールまたはパッチ適用を行ったら、第33.2.3.2.3項「WebCenter Portalポリシー・ドメインの構成」の説明に従ってWebGateをインストールします。
この手順では、Oracle 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 WCP_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
第33.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をインストールおよび構成したら、第33.2.4項「OAM用のWebLogicドメインの構成」の説明に従ってWeblogicドメインを構成し、第33.2.6項「追加のシングル・サインオン構成」の説明に従って適用される追加のサービスとコンポーネントの構成を実行します。
環境が複数のドメインにまたがっている場合(例: WebCenter Portalのドメイン、別個の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管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
OIDオーセンティケータを構成するレルム・エントリをクリックします。
レルムの「設定」ペインが表示されます。
「プロバイダ」タブを開きます。
「プロバイダ設定」が表示されます。
「新規」をクリックして、プロバイダを作成します。
「新しい認証プロバイダの作成」ペインが表示されます。
新しいプロバイダの名前(例: OID Authenticator)を入力し、そのタイプとしてOracleInternetDirectoryAuthenticatorを選択して、「OK」をクリックします。
「プロバイダ」タブで、新しく追加したプロバイダをクリックします。
オーセンティケータの「共通設定」ペインが表示されます。
制御フラグをSUFFICIENTに設定し、「保存」をクリックします。
「プロバイダ固有」タブを開きます。
オーセンティケータのプロバイダ固有の設定ペインが表示されます。
次の表に示されているように、各フィールドに値を入力します。これら以外のフィールドは、デフォルト値のままにします。
| フィールド | 値 | コメント |
|---|---|---|
|
ホスト: |
LDAPサーバーのホストID |
|
|
ポート: |
LDAPサーバーのポート番号 |
|
|
プリンシパル: |
LDAP管理者プリンシパル(例: cn=orcladmin) |
|
|
資格証明: |
|
管理者プリンシパルのパスワード |
|
資格証明の確認: |
|
|
|
ユーザー・ベースDN: |
ユーザー検索ベース - この値はOAM Access Managerのセットアップの値と同じであることが必要 |
|
|
すべてのユーザーのフィルタ: |
"(&(uid=*)(objectclass=person))" |
|
|
ユーザー名属性: |
"uid" |
|
|
名前指定によるユーザー・フィルタ: |
"(&(uid=%u)(objectclass=person))" |
指定したユーザー名属性は、「すべてのユーザーのフィルタ」、「ユーザー名属性」および「名前指定によるユーザー・フィルタ」の3つのフィルタに一致する必要があります。 |
|
グループ・ベースDN: |
グループ検索ベース - ユーザー・ベースDNと同じ |
|
|
取得したユーザー名をプリンシパルとして使用する |
選択 |
通常はユーザー・ログインIDでは大/小文字は区別されません。このフラグは、設定されたサブジェクトに、OIDに格納されたユーザー名が含まれるようにするために必要とされます。 |
|
注意: 「ユーザー名属性」、「すべてのユーザーのフィルタ」および「名前指定によるユーザー・フィルタ」のすべてのフィールドが、同じOID属性(この場合は |
「保存」をクリックします。
OAMアイデンティティ・アサータは、プロバイダの制御フラグをREQUIREDに設定して構成する必要があります。
OAMアイデンティティ・アサータを構成するには:
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
OAMアイデンティティ・アサータを構成するレルム・エントリをクリックします。
レルムの「設定」ペインが表示されます。
「プロバイダ」タブを開きます。
「プロバイダ設定」が表示されます。
「新規」をクリックして、プロバイダを作成します。
「新しい認証プロバイダの作成」ペインが表示されます。
新しいプロバイダの名前(例: OAM ID Asserter)を入力し、そのタイプとしてOAMIdentityAsserterを選択して、「OK」をクリックします。
「プロバイダ」タブで、新しく追加したプロバイダをクリックします。
オーセンティケータの「共通設定」ペインが表示されます。
制御フラグをREQUIREDに設定し、OAM_REMOTE_USERとObSSOCookieが「アクティブなタイプ」に設定されていることをチェックします。
「保存」をクリックして、設定を保存します。
OAMアイデンティティ・アサータを構成したら、デフォルト・オーセンティケータの制御フラグがSUFFICIENTに設定されていることを確認して、次のようにプロバイダを並べ替えます。
プロバイダの設定ペインに移動します。
デフォルト・オーセンティケータを開き、制御フラグがSUFFICIENTに設定されていることを確認します。
先ほど作成した2つのプロバイダ以外の全プロバイダについて、同じことを行います。
設定ペインで、プロバイダの順序を次のようにリセットします:
OAMIdentityAsserter (REQUIRED)
OracleInternetDirectoryAuthenticator (SUFFICIENT)
DefaultAuthenticator (SUFFICIENT)
DefaultIdentityAsserter
第33.2.6.1項「SSO用のWebCenter Portalの構成」の説明に従って、シングル・サインオン・モード用にWebCenter Portalを構成します。 また、第33.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 Tierインストレーション・ガイド』の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 WebGates for Oracle Access Managerのインストール』の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>
<Location /wcsdocs>
SetHandler weblogic-handler
WeblogicHost webcenter.example.com
WeblogicPort 8888
</Location>
<Location /_vti_bin>
SetHandler weblogic-handler
WeblogicHost webcenter.example.com
WeblogicPort 8888
</Location>
</IfModule>
# <Location /weblogic>
# SetHandler weblogic-handler
# PathTrim /weblogic
# ErrorPage http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
# </Location>
|
注意: 前述の |
次の項で説明する構成は、サイトのセキュリティを強化するために必要であるか、または役に立ちます。これらの構成が完了したら、第33.2.7項「OAMインストールのテスト」の説明に従ってOAMインストールのテストを行ってください。
第33.2.6.5項「OAM 10g用のWebLogic Server管理コンソールとEnterprise Managerの構成」
第33.2.6.6項「OAM 11g用のWebLogic Server管理コンソールとEnterprise Managerの構成」
WebCenter Portalアプリケーションを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サーバーを再起動します。
この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。SSO用のディスカッション・サーバーを構成する前に、第31.1項「外部LDAPサーバーへのアイデンティティ・ストアの再関連付け」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。デフォルトの管理者アカウントを外部LDAPに移動しない場合は、第31.4.1項「外部LDAPを使用するためのディスカッション・サーバーの移行」の手順にも従ってください。
|
注意: SSOの構成後は、ディスカッション・サーバーへの直接のログインはサポートされません。ログインはOracle HTTP Server URLを通して行う必要があります。 |
SSO用のディスカッション・サーバーを設定する手順は次のとおりです。
ディスカッション・サーバー管理コンソールにログインします。
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プロパティは、電子メールのフォーラムへのリンクを構築する際に使用されます。
|
注意: WebCenter Portalでディスカッションおよびフォーラム用に登録したWebCenter接続は、OHS URLをポイントしている必要があります。 |
この項では、Web層のホストおよびポートの値を使用するようにWebCenter Portal用のディスカッション・サーバー接続を更新する方法を説明します。次の手順では、ディスカッション・コンポーネントがWebCenter Portalドメインにすでにインストールおよび構成されていることを前提としています。
Fusion Middleware ControlまたはWLSTを使用して、ディスカッション・サーバーのURLホストおよびポート設定をWC_Spaces管理対象サーバーの設定からWeb層のホストおよびポート設定に変更します。これらの設定の変更方法については、第12.5項「ディスカッション・サーバー接続の詳細の変更」を参照してください。
WC_Spaces管理対象サーバーを再起動します。
WebCenter Portalにログインすると、ディスカッション・サーバーにも自動的にサインオンします。
すでにワークリスト接続をセットアップしてある場合は、SOAサーバーのホストとポートのかわりにWeb層のホストとポートを使用するようにURLを変更します。これは第20.4項「ワークリスト接続の設定」の説明に従って、Fusion Middleware ControlまたはWLSTコマンドを使用して行うことができます。
URLを変更してOAM SSOに必要な設定を完了したら、WebCenter Portal管理サーバー上で次のコマンドを実行してワークリストの変更を有効にします。
setBPELConnection('webcenter','WebCenter-Worklist', 'http://webtier.example.com:7777')
デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護されたままの状態では、それらは外部リーダーでうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できる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)になります。
「ポリシー・マネージャ」をクリックします。
「ポリシー・マネージャ」ペインが表示されます(図33-4を参照)。
WebCenter Portalリソースを保護するために作成したポリシー・ドメインを見つけます。
「リソース」タブを開き、「追加」をクリックします。
「リソース」ページが表示されます(図33-5を参照)。
保護する必要のあるリソースを追加します。各リソースに対して、次の手順を実行します。
「リソース・タイプ」として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 /console/* /console/.../*)またはEnterprise ManagerのリソースURL(/em /em/* /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接続の構成の詳細は、第18.4項「Oracle SES接続の設定」を参照してください。
SSOのセットアップが完了し、Content Serverの接続をセットアップしたら、Fusion Middleware Controlを使用して、または次のWLSTの例のように、JCRContentServerConnectionにWebコンテキスト・ルートを指定します。
setJCRContentServerConnection(appName, name, webContextRoot='/cs')
Webコンテキスト・ルートを設定することで、SSOがセットアップされていることをドキュメント・ライブラリのコードに伝えます。この設定は、SSOを完全にセットアップするまでは設定しないでください。
ユーザーが適切に認証されるように、Web層OHSポートを通してのみWebCenter PortalまたはPortal Frameworkアプリケーションと関連するコンポーネントへのアクセスを許可するには、次の手順に従います。
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
ドメイン構造ペインで、構成するドメインを選択します(例: webcenter)。
「セキュリティ」タブを開き、「フィルタ」サブタブを開きます。
セキュリティ・フィルタの設定ペインが表示されます。
「接続ロガーの有効化」を選択して、受け入れられたメッセージのログを有効にします。
接続ロガーは、成功した接続と接続データをサーバーにログします。この情報を使用して、サーバー接続に関する問題をデバッグできます。
「接続フィルタ」フィールドに、ドメインで使用する接続フィルタ・クラスを指定します。
デフォルトの接続フィルタを構成するには、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
これによって次のエラーが生成されます。
「サーバーがこのリクエストを処理できません:[ソケット:000445]接続が拒否され、フィルタがソケットをブロックしました、weblogic.security.net.FilterException: [セキュリティ:090220]rule 3」
ただし、OHSポートを通してWebCenter Portalにアクセスすることは今でも可能です。
http://host:OHS_port/webcenter
OHSを通してルーティングされるようにポートレット・プロデューサ・アプリケーションをセットアップした場合は、登録用のプロデューサURLを指定する際に必ずOHSホストおよびポートを使用してください。これは、wsrp-toolsのようなデフォルトのプロデューサ、サービス・プロデューサ、ページレット・プロデューサおよび明示的に構成した他のプロデューサに適用されます。
OAM 10gまたは11gをインストールおよび構成したら、構成された次のすべての(環境に適用される)アプリケーションにアクセスできることと、グローバル・ログインおよびログアウトによって再度サインインを要求されることなく構成されたすべてのアプリケーションにアクセスできることをチェックします。また、利用できる状況でグローバル・ログアウトもテストして、関連する他のすべてのアプリケーションからログアウトすることを確認してください。
WebCenter Portal: 保護されたすべてのWebCenter Portal 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画面が表示できることを確認します。すでにWebCenter Portalにログインしている際には、ログインせずにコンテンツ・プレゼンタ・テンプレートのSite Studioコンテンツにもアクセスできます。
SOA: ワークフロー・タスク・フローのリンクにアクセスして、ログインをチャレンジされないことを確認します。
ディスカッション・フォーラム: ディスカッション・アプリケーション(http://host:port/owc_discussions)にアクセスして、ログインします。ログインがSSOログイン・チャレンジであることを確認します。同様に、ディスカッション・サーバー(http://host:port/owc_discussions/admin)に管理者ログインする場合も、SSOログイン・チャレンジを使用する必要があります。
デフォルトのインストールでは、WebCenter PortalおよびPortal Frameworkアプリケーションは、それらのために作成された管理対象サーバーのHTTPポートを使用します。Oracle Single Sign-Onを使用してWebCenter PortalおよびPortal Frameworkアプリケーションを構成するためには、アプリケーションはOracle Single Sign-On (OSSO)と統合するために、Oracle HTTP Serverおよび関連付けられたモジュールmod_ossoを必要とします。第34.5項「OSSOに対するPortal Frameworkアプリケーションの構成」で説明されているように、Portal Frameworkアプリケーションの場合は、追加の構成がいくつか必要になることに注意してください。
|
注意: BPELコンソールはSSOの統合をサポートしません。WebCenter PortalまたはPortal FrameworkアプリケーションがSSO用に構成されている場合も、BPELへのログインはBPELコンソール上で標準ログイン・ページを通して行う必要があります。 |
この項には次のサブセクションが含まれます
この項のフロー・チャート(図33-6)と表(表33-2)は、OSSOを使用してWebCenter PortalおよびPortal Frameworkアプリケーションのシングル・サインオンを構成する際の前提条件と必要なタスクの概要を示しています。
表33-2は、OSSOを使用してWebCenter Portalのシングル・サインオンを構成するためのタスクとサブタスクを示しています。
表33-2 OSSOを使用したWebCenter Portalのシングル・サインオンの構成
| 担当者 | タスク | サブタスク | ノート |
|---|---|---|---|
|
管理者 |
1. Oracle HTTP Serverと関連モジュールの構成 |
1.a Web層のインストール |
|
|
1.b Web層OHS内のmod_wlモジュールの構成 |
|||
|
2. OSSOIdentityAsserterの構成 |
|||
|
3. Oracle SSOへのOHSの登録 |
|||
|
4. 必要に応じた追加構成の実行 |
4.a SSO用のWebCenter Portalの構成 |
||
|
4.b Web層OHSポートを通したWebCenterとコンポーネントおよびサービスへのアクセスの制限 |
|||
|
4.c SSO用のディスカッション・サーバーの構成 |
デフォルトのインストールでは、WebCenter PortalおよびPortal Frameworkアプリケーションは、それらのために作成された管理対象サーバーのHTTPポートを使用します。Oracle Single Sign-Onを使用してWebCenter PortalまたはPortal Frameworkアプリケーションを構成するためには、アプリケーションはOracle SSOと統合するために、Oracle HTTP Serverおよび関連付けられたモジュールmod_ossoを必要とします。次の図(図33-7)は、この統合の全体的なアーキテクチャを示しています。
この項では、Oracle HTTP Serverと関連付けられたモジュールのロードおよび構成方法を説明します。
Oracle HTTP Serverおよび関連付けられたモジュールをロードおよび構成する手順は次のとおりです。
Oracle HTTP Server(OHS)および関連付けられたモジュール(mod_ossoおよびmod_wl)を含むOracle Web層ソフトウェアをインストールします。
WebCenter PortalまたはPortal Frameworkアプリケーション用の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またはPortal Frameworkアプリケーション用のOracle WebLogicドメインにOSSO Identity Assertion Provider (IAP)プロバイダを追加します。次の手順に従って、WebLogic Server管理コンソールを使用してOSSO IAPをドメインに追加します。環境が複数のドメインにまたがっている場合(例: WebCenter Portalのドメイン、別個のSOAのドメインおよび別個のContent Serverのドメイン)、それぞれのドメインについてこの項の手順を繰り返してください。
OSSOIdentityAsserterを構成するには:
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
プロバイダを追加するレルム・エントリをクリックします。
レルムの「設定」ペインが表示されます。
「プロバイダ」タブをクリックします。
「プロバイダ設定」が表示されます。
「新規」をクリックして、プロバイダを作成します。
「新しい認証プロバイダの作成」ペインが表示されます。
新規のプロバイダの名前を入力し、タイプとして「OSSOIdentityAsserter」を選択して「OK」をクリックします。
「プロバイダ」タブで、新しく追加したプロバイダをクリックします。
制御フラグをOPTIONALに設定します。
関連付けられたOracle Internet Directoryサーバーからユーザー・プロファイルを取得できるように、OracleInternetDirectoryAuthenticator(または外部LDAPを使用するようにアイデンティティ・ストアを構成した際に選択したプライマリ・オーセンティケータ)がドメインのプライマリ・オーセンティケータとして設定されていることを確認します。外部LDAPを使用するようにアイデンティティ・ストアを構成する方法については、第31章「アイデンティティ・ストアの構成」を参照してください。
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 /example.com.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層を再起動します。
次の項で説明する構成は、サイトのセキュリティを強化するために必要であるか、または役に立ちます。Portal Frameworkアプリケーションの場合は、第34.5項「OSSOに対するPortal Frameworkアプリケーションの構成」で説明されている追加の構成も必要になります。
第33.2.6.1項「SSO用のWebCenter Portalの構成」の説明に従ってEXTRA_JAVA_PROPERTIESに設定を追加してリブートすることで、WebCenter Portal用のOracle Single Sign-on (OSSO)の構成を行ってください。
ユーザーが適切に認証されるように、Web層OHSポートを通してのみWebCenter PortalまたはPortal Frameworkアプリケーション、および関連するコンポーネントとサービスへのアクセスを許可するには、第33.2.6.9項「接続フィルタを使用したアクセスの制限」の手順に従います。
この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。SSO用のディスカッション・サーバーを構成する前に、第31.4.1項「外部LDAPを使用するためのディスカッション・サーバーの移行」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。
SSO用のディスカッション・サーバーを設定する手順は次のとおりです。
ディスカッション・サーバー管理コンソールにログインします。
http://host:port/owc_discussions/admin
hostおよびportは、WC_Collaboration管理対象サーバーのホストIDとポート番号です。
「システム・プロパティ」ページを開き、owc_discussions.sso.modeプロパティを編集(存在している場合)または追加します(値をtrueに設定します)。
Web層のベースURLをポイントするようにjiveURLプロパティを更新します。
第33.3.5項「Oracle SSOへのOHSの登録」の説明に従ってOracle SSOにOHSを登録したら、WebCenter Portal管理サーバーを使用して次のコマンドを実行し、ワークリストの変更を有効にします。
setBPELConnection('webcenter','WebCenter-Worklist', 'http://webtier.example.com:7777')
Content ServerリポジトリにはWebCenter Portalから直接アクセスできるので、これもシングル・サインオン構成に含めることが可能です。Content Serverの接続をセットアップしたら、Fusion Middleware Controlを使用して、または次の例のようにWLSTを使用して、JCRContentServerConnectionにWebコンテキスト・ルートを指定します。
setJCRContentServerConnection(appName, name, webContextRoot='/cs')
Content Serverの構成方法の詳細は、Oracle Fusion Middleware Oracle Content Serverシステム管理者ガイドのシングル・サインオン用のWebCenter Contentの構成に関する項を参照してください。
デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護されたままの状態では、それらは外部リーダーでうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できる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のクロールおよび認証エンド・ポイントを更新できます。詳細は、第18章「WebCenter PortalでのOracle Secure Enterprise Searchの管理」を参照してください。
Security Assertion Markup Language (SAML)によって、WebLogic ServerドメインおよびWebブラウザまたは他のHTTPクライアントで実行されているWebアプリケーションやWebサービス間でクロスプラットフォームの認証が可能になります。WebLogic Serverは、WebCenter PortalおよびPortal Frameworkアプリケーションに対して、SAMLに基づくシングル・サインオン(SSO)をサポートします(ページレット・プロデューサ・アプリケーションはサポートされません)。シングル・サインオン(SSO)構成に参加する1つのサイトでユーザーが認証されると、SSO構成の他のサイトでも自動的に認証され、別途ログインする必要はありません。ページレット・プロデューサ・アプリケーションはSAML SSOに参加しないので、ページレット・プロデューサ・アプリケーションにアクセスするユーザーは明示的にログインする必要があることに注意してください。また、第34.6項「SAML SSOに対するPortal Frameworkアプリケーションの構成」で説明されているように、Portal Frameworkアプリケーションの場合は、追加の構成がいくつか必要になることにも注意してください。
|
注意: SAMLベースのシングル・サインオンは、初回サインオン後の後続のアプリケーションへのユーザーのログオンはサポートしますが、グローバル・ログアウトはサポートしません。このため、ユーザーは、開いた各アプリケーションを個々にログアウトする必要があります。 また、WebCenter Portalをソース・アプリケーション、ディスカッションを宛先アプリケーションとして使用して、SAMLベースのシングル・サインオンをセットアップすると、管理者はWebCenter Portal管理(「構成」→「サービス」)とポータル設定(「サービス」ページ)からディスカッション管理ページにアクセスできることにも注意してください。ただし、ディスカッション管理ページはSSOに参加しないので、管理ページに直接アクセスすると、ディスカッション・サーバーへの再ログインが必要になります。 さらに、SAMLベースのシングル・サインオンは、 |
このSSOメカニズムは、Oracle SSOまたはOracle Access Managerシングル・サインオン・インフラストラクチャがまだ存在しておらず、WebCenter Portalとそのコンポーネントまたはサービス間のみのシングル・サインオンが必要とされる部門別のインストールに使用できます。大規模エンタープライズの高可用性展開では、Oracle Access Manager SSOをお薦めします。
この項では、同じドメイン内の異なる管理対象サーバー上で実行されるWebCenter PortalまたはPortal Frameworkアプリケーションおよびワークリストに対してSAML 1.1ベースのシングル・サインオンをセットアップする方法を説明します。
この項には次のサブセクションが含まれます:
図33-9は、WebCenter Portalとディスカッションを含む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アサーションの形式でセキュリティ情報をアサートする権限を持つエンティティ)です。
図33-8は、WebCenter PortalとSOAドメインの両方を含む、POSTが構成されたSAML SSO構成のコンポーネントとフローを示しています。このフローは、ワークリスト・アプリケーションやディスカッションのようなシングル・サインオンに参加する他の宛先アプリケーションの場合と似ています。
図33-8 詳細なSAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)
図33-9は、WebCenter Portalとディスカッション・アプリケーションの間のSAML SSOフローを含む、POSTが構成されたSAML SSO構成の簡略化されたバージョンのコンポーネントとフローを示しています。
図33-9 SAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)
フローの手順は次のとおりです。
ユーザーのブラウザが、ユーザーの資格証明を入力して、WebCenter Portalドメイン(wc_domain)のWebLogic管理対象サーバー(WC_Spaces)上にホストされているWebCenter Portal(ソース・サイト)にアクセスします。
WebCenter Portalが、認証サービス・プロバイダにユーザーの資格証明を渡します。
認証に成功すると、認証されたセッションが確立されて、WebCenter Portalのようこそページが表示されます。
ユーザーがようこそページで、同じドメインの異なるWebLogic Server(WC_Collaboration)上にホストされているディスカッション宛先サイトのセキュアなWebページにアクセスするためのリンクをクリックします。これによって、構成されているサイト間転送サービス(ITS)サーブレットへのコールがトリガーされます。この場合は、ITSサーブレットが、WebCenter Portalと同じJSESSIONID Cookieを共有するソース・サイト内(つまり、WC_Spaces管理対象サーバー上のWebCenter Portalアプリケーション上)にホストされます。
ITSサーブレットは、WebCenter Portalドメイン(wc_domain)で構成されているSAML資格証明マッパーをコールして、コール元アサーションをリクエストします。SAML資格証明マッパーはアサーションを返します。また、宛先サイト・アプリケーションWebページ(ディスカッション用のセキュアなWebページ)のURLと適切なPOSTフォームのパス(ソース・サイトがPOSTプロファイルを使用するように構成されている場合)も返します。
SAML ITSサーブレットが、生成されたアサーションを含むSAMLレスポンスを生成し、それに署名して、BASE64にエンコードし、HTMLフォームに埋め込んで、そのフォームをユーザーのブラウザに返します。
ユーザーのブラウザがそのフォームを宛先サイトのアサーション・コンシューマ・サービス(ACS)にPOSTします。この場合は、ACSサーブレットが宛先サイト(ディスカッション)にホストされ、そのログインCookieを共有します。
アサーションが検証されます。
アサーションに成功すると、ユーザーがターゲット(ディスカッションのセキュアなWebページ)にリダイレクトされます。
ユーザーは再認証の必要なしで宛先サイト(ディスカッション)にログインします。
この項では、一連の自動化されたスクリプトを使用して、SAMLベースのシングル・サインオンのためにWebCenter Portalと関連するサービスおよびコンポーネントを構成する方法を説明します。
この項には次のサブセクションが含まれます:
この項では、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の編集の詳細は、第33.2.5項「Oracle HTTP Serverのインストールと構成」を参照してください。
さらに、WebCenter Portalにカスタム・ログイン・ページを使用する場合、Site Studio Designerを動作させるためには、Content Server用に生成されるHTMLページのheadセクションに次のHTMLコメントを追加する必要があります。
<!--IdcClientLoginForm=1-->
このHTMLコメントは、WebCenter Portalのデフォルト・ログイン・ページに表示されますが、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用のディスカッション・サーバーを構成する前に、第31.1項「外部LDAPサーバーへのアイデンティティ・ストアの再関連付け」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。 デフォルトの管理者アカウントを外部LDAPに移動しない場合は、第31.4.1項「外部LDAPを使用するためのディスカッション・サーバーの移行」の手順にも従ってください。 |
SAML SSOバージョンのOracle WebCenter Portalのディスカッション・サーバーをデプロイおよび構成する手順は次のとおりです。
WebLogic Server管理コンソールに管理者としてログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「デプロイメント」をクリックします。
デプロイメントのサマリー・ペインが表示されます。
デプロイメントのサマリー・ページで、owc_discussions stop and deleteを選択して「インストール」をクリックします。
アプリケーション・インストール・アシスタントの「パス」フィールドを使用して、SSO対応のowc_discussions .EARファイル(owc_discussions_samlsso.ear、通常はWCP_ORACLE_HOME /discussionserverにあります)を見つけます。
owc_discussions_samlsso.earファイルを選択して「次へ」をクリックします。
「このデプロイメントをアプリケーションとしてインストールする」を選択して「次へ」をクリックします。
「名前」をowc_discussionsに設定します。
.EARファイルをデプロイします。
ディスカッション・サーバー管理コンソールに管理者としてログインします(ディスカッション・サーバー管理コンソールへのログインの詳細は、第33.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キーストアの構成の詳細は、第35.1.2項「カスタムIDキーストアおよびJava信頼キーストアの構成」を参照してください。
keytoolを使用して、SAMLアサーションの暗号化に使用するために選択した証明書をエクスポートします。必ずWebCenter Portalドメインの管理サーバーとWC_Spacesに対して構成されたキーストア上でexportコマンドを実行するようにしてください。
keytool -export -keystore <keystore_name> -storepass <keystore_password> -alias <certificate_alias> -keypass <certificate_password> -file <certificate.der>
ここで:
keystore_nameは、WebCenter Portalドメインの管理サーバーとWC_Spacesに対して構成されたキーストアの名前
keystore_passwordは、WebCenter Portalドメインの管理サーバーとWC_Spacesに対して構成されたキーストアのパスワード
certificate_aliasは別名(例: demoidentity)
certificate_passwordは証明書のパスワード
certificate.derは証明書ファイルの名前
keytool -exportコマンドはWebCenter Portalマシンから実行する必要があることと、WebCenter Portalサーバーに構成されたキーストアに常駐するSAML SSOのセットアップで使用されている証明書をエクスポートする必要があることに注意してください。
(SOA、Content Serverおよびコラボレーションなどの)宛先ドメインにファイルをコピーまたは転送し、第33.4.2.2.1項「シングル・サインオンのスクリプト」で説明されているSAML SSOスクリプトを実行する準備が整ったら、wcsamlsso.propertiesファイルのcertPath値を構成します。
トランスポートレベルのセキュリティを提供するためにWebCenter PortalのインストールでSSLを必要とする場合は、第35章「SSLの構成」で説明されているようにシングル・サインオンを構成する前にSSLを構成する必要があります。 SSLのセットアップはSSOの有効化とは無関係であることに注意してください。
WebCenter Portalと環境に必要なサービスおよびコンポーネントをインストールしたら、この項で説明されているスクリプトを使用してSAMLベースのシングル・サインオンを構成します。
このスクリプトでは、次を構成することで、WebLogic環境にSAMLベースのシングル・サインオンをセットアップします。
SAML資格証明マッピング・プロバイダ
必要なリライイング・パーティ
ソース・サイトのフェデレーション・サービス
SAMLアイデンティティ・アサータ
必要なアサーティング・パーティ
宛先サイトのフェデレーション・サービス
この項には次のサブセクションが含まれます:
WebCenter Portalおよび関連するアプリケーション用にSAML 1.1 SSOを構成するためのシングル・サインオン・スクリプトは、WCP_ORACLE_HOME /webcenter/scripts/samlssoフォルダに格納されています。SAMLの構成に関係するのは、次のファイルです。
wcsamlsso.properties
このプロパティ・ファイル(WCP_ORACLE_HOME/common/bin/wcsamlsso.properties)は、SAML SSOのセットアップに必要な構成情報をカプセル化します。プロパティ・ファイルには次のセクションがあります。
spaces_config
このセクションでは、資格証明マッパーおよびソース・サイト・フェデレーション・サービスの構成に必要なWebCenter Portalドメインのログイン情報、WebLogic管理URL、WebCenter PortalサーバーおよびURLなどをキャプチャします。このセクションのすべてのプロパティを指定する必要があります。
configFile - WebCenter Portalドメイン用のweblogicユーザー・アカウントとパスワードを含む構成ファイル
keyFile - WebCenter Portalドメイン用のweblogicユーザー・アカウントとパスワードを復号化するためのキー・ファイル
adminURL - WLSTに接続するためのWebLogic管理URL
usesSSL - SSLを使用するようにWebCenter Portalが構成されているかどうかを示します。
url - WebCenter Portal URL。usesSSLがtrueの場合は、httpをhttpsに変更してください。WebCenter PortalのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。
serverName - WebCenter Portalがデプロイされているサーバー(通常は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
WebCenter Portal用に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がインストールされており、WebCenter Portalアプリケーション用にドキュメント接続が構成されている場合は、このセクションを指定してください。
url - Content Server URL。spaces_config内のusesSSLがtrueである場合は、httpをhttpsに変更します。Content ServerのフロントエンドがWeb層の場合は、Web層のホストとポートをここに指定します。環境にWebCenter PortalとContent Serverの両方が構成されている場合は、同じWeb層を使用して両方にアクセスする必要があります。
wcsamlsso.py
残りの構成スクリプトによって呼び出されるユーティリティ関数を含むスクリプト・ファイル(WCP_ORACLE_HOME/common/wlst/wcsamlsso.py)
configureSpaces.py
SAML 1.1資格証明マッパー、SAML 1.1アイデンティティ・アサータおよびソースならびに宛先サイト・フェデレーション・サービスをWebCenter Portalドメインに構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureSpaces.py)
configureCollab.py
SAML 1.1アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスをコラボレーション・ドメインに構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureCollab.py)
configureUtilities.py
SAML 1.1アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスをユーティリティ・ドメインに構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureUtilities.py)
configureSOA.py
SAML 1.1アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスをSOAドメインに構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureSOA.py)
configureUCM.py
SAML 1.1アイデンティティ・アサータおよび宛先サイト・フェデレーション・サービスをContent Serverドメインに構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureUCM.py)
configureREST.py
RESTアプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureREST.py)
configureRSS.py
RSSアプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureRSS.py)
configureForum.py
ディスカッションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureForum.py)
configureActivityGraphEngine.py
アクティビティ・グラフ・エンジン・アプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureActivityGraphEngine.py)
configureWorklistIntegration.py
ワークリスト統合アプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistIntegration.py)
configureWorklistDetail.py
ワークリスト・コミュニティ詳細アプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistDetail.py)
configureWorklistSDP.py
ワークリストSDPアプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistSDP.py)
configureCS.py
Content Serverアプリケーションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureCS.py)
SAMLベースのシングル・サインオンを構成するスクリプトを使用する手順は次のとおりです。
|
注意: スクリプトの実行中に構成ミスによるエラーが発生した場合、SAML SSO構成は未完了の状態で終了する可能性があります。提供された構成スクリプトを再実行できない場合は、第33.4.2.6項「SAML SSO構成の削除」の説明に従って、構成を再試行する前にSAML SSOアーティファクトをクリーンアップする必要があります。 |
この構成で使用されるすべてのドメインの管理サーバーが稼働中であることを確認してください。
プロパティ・ファイルが選択されるように、WCP_ORACLE_HOME/common/binからstoreUserConfig WLSTコマンドを使用して、様々なドメインの接続情報を含む構成ファイルとキー・ファイルを生成します。使用方法と構文の詳細は、コマンド行のヘルプ(help('storeUserConfig'))を使用してください。
WLSTを使用し、管理ユーザー名とパスワードを使用してWebCenter Portalドメインに接続し、次のコマンドを実行します。
storeUserConfig('spacesconfig.secure', 'spaceskey.secure')
これによってユーザー構成ファイルと関連するキー・ファイルが作成されます。ユーザー構成ファイルには、暗号化されたユーザー名とパスワードが含まれます。キー・ファイルには、ユーザー名とパスワードの暗号化と復号化に使用される秘密鍵が含まれます。前述のコマンドは、構成ファイルとキー・ファイルを、WLSTが呼び出されたディレクトリに格納します。または、オプションでよりセキュアなパスを指定することもできます。
管理ユーザー名とパスワードを使用してコラボレーション・ドメインに接続した後で、手順2aを繰り返します。ユーティリティ・サーバーがWebCenter Portalと同じドメイン(wc_domain)内にある場合でも、WebCenter Portalドメインに接続し、このコマンドを実行する必要があります。
storeUserConfig('collabconfig.secure', 'collabkeykey.secure')
管理ユーザー名とパスワードを使用してユーティリティ・ドメインに接続した後で、手順2aを繰り返します。ユーティリティ・サーバーがWebCenter Portalと同じドメイン(wc_domain)内にある場合でも、WebCenter Portalドメインに接続し、このコマンドを実行する必要があります。
storeUserConfig('utilitiesconfig.secure', 'utilitieskey.secure')
管理ユーザー名とパスワードを使用してSOAドメインに接続した後で、手順2aを繰り返します。WebCenter Portalと同じドメインに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 WebCenter Portal domain directory>')
これによって、暗号化された証明書パスワードが表示されます。暗号化コマンドは、指定されたWebLogic Serverドメイン・ルート・ディレクトリに暗号化を使用します。暗号化された出力は、次の手順に出てくるwcsamlsso.propertiesでcertPassword値として設定する必要があります。このパスワードはWebCenter Portalドメインの資格証明マッパーとソース・サイト・フェデレーション・サービスに設定され、確実にWebCenter Portalドメインから暗号化ユーティリティが実行されるようになります。
WCP_ORACLE_HOME/common/bin/wcsamlsso.propertiesを編集して、セットアップに適用されるセクションを指定します。プロパティ・ファイルのセクションの詳細な説明は、第33.4.2.2.1項「シングル・サインオンのスクリプト」を参照してください。
WCP_ORACLE_HOME/common/binからWLSTを起動して、次に示された順番でスクリプトを実行します。
|
注意: スクリプトには明示的な接続コマンドが含まれているので、スクリプトはWLSTオフライン・モードで実行してください。 |
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureSpaces.py')
WebCenter Portalドメインの管理サーバーを含むすべてのサーバーを再起動します。
ディスカッション・サーバーをセットアップしてある場合は、configureCollab.pyスクリプトを実行します。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureCollab.py')
ディスカッションがWebCenter Portalと同じドメインに属している場合は、WC_Collaboration管理対象サーバーのみを再起動します。そうでない場合は、コラボレーション・ドメインの管理サーバーを含むすべてのサーバーを再起動します。
ユーティリティ・サーバーをセットアップしてある場合は、configureUtilities.pyスクリプトを実行します。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureUtilities.py')
ユーティリティ・サーバーがWebCenter Portalと同じドメインに属している場合は、WC_Utilitiesサーバーのみを再起動します。そうでない場合は、ユーティリティ・ドメインの管理サーバーを含むすべてのサーバーを再起動します。
WebCenter Portalのワークリストを構成してある場合は、configureSOA.pyスクリプトを実行します。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureSOA.py')
SOAドメインの管理サーバーを含むすべてのサーバーを再起動します。
WebCenter Portalにドキュメントを構成してある場合は、次のようにconfigureUCM.pyスクリプトを実行します。
execfile('WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureUCM.py')
Content Serverドメインの管理サーバーを含むすべてのサーバーを再起動します。
環境の必要に応じて次の個々のコマンドを実行します。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureREST.py') - 再起動は必要ありません。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureRSS.py') - 再起動は必要ありません。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureForum.py') - セットアップにディスカッションがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureActivityGraphEngine.py') - セットアップにユーティリティがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureWorklistIntegration.py') - セットアップにワークリストがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureWorklistDetail.py') - セットアップにワークリストがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureWorklistSDP.py') - セットアップにワークリストがインストールされている場合はこれを行ってください。再起動は必要ありません。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureCS.py') - セットアップにContent Serverがインストールされている場合はこれを行ってください。再起動は必要ありません。
第33.4.2.4項「構成のチェック」の手順を使用して、インストールをチェックします。
|
重要: プロパティ・ファイルには機密情報が含まれているので、SAML SSOセットアップの構成および検証後に |
|
注意: スクリプトの実行中にエラーが発生した場合は、スクリプトを再実行する前に、第33.4.2.6項「SAML SSO構成の削除」の説明に従って、スクリプトによってセットアップされたアサーティングおよびリライイング・パーティを削除する必要があります。 古いSAML SSO構成を削除したら、スクリプトを再実行してください。 |
デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護されたままの状態では、それらは外部リーダーでうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できるWebLogic ServerのBASIC認証によってRSSサーブレットの認証が処理されるように、WebCenter Portal RSSリソースを非保護にすることをお薦めします。
次の手順に従って、RSSフィードを非保護にします。
WebCenter PortalドメインのWLS管理コンソールにログオンします。
セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択します。
RSSのリライイング・パーティを無効化または削除します。
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択します。
RSSのアサーティング・パーティを無効化または削除します。
次の手順に従って、シングル・サインオン構成が正しく動作することをチェックします。
シングル・サインオン構成をテストする手順は次のとおりです。
新しいブラウザを使用して、WebCenter Portalにログインし、「スペース設定」→「サービス」→「ディスカッション」の「フォーラム管理」をクリックしても、資格証明についてチャレンジされないことをチェックします(このサービスがスペース用にプロビジョニングされていると仮定します)。
ディスカッションまたはワークリスト・タスク・フローからRSSリンクにアクセスして、ログインのためにチャレンジされないことをチェックします。
Content Serverの場合は、プロファイル・ユーザー・インタフェースに移動し、ログインをチャレンジされずに、iFrames内に埋め込まれているContent Server画面が表示されることを確認します。すでにWebCenter Portalにログインしている際には、ログインをチャレンジされずにコンテンツ・プレゼンタ・テンプレートの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および他のアプリケーション・サーバーのロギングを有効化する方法の詳細は、第28.2.1項「WebCenter Portalログの表示および構成」を参照してください。スクリプトを再実行する前に、第33.4.2.6「SAML SSO構成の削除」の説明に従って、SAML SSO構成を削除します。
この項では、テストなどのためにSAML SSO構成を一時的に無効にする方法を説明します。
SAML SSO構成を無効にする手順は次のとおりです。
WebCenter Portalドメインの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構成を削除するには:
WebCenter PortalドメインのWLS管理コンソールにログオンします。
セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択し、そこに示されたリライイング・パーティをすべて削除します。
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて削除します。
「プロバイダ」→「認証」→「wcsamlia」→「管理」→「証明書」に移動し、そこで証明書をすべて削除します。
「プロバイダ」→「資格証明マッピング」→「wcsamlcm」に移動して、SAML資格証明マッパーを削除します。
「プロバイダ」→「認証」→「wcsamlia」に移動し、SAMLアイデンティティ・アサータを削除します。
WebCenter Portal 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認証とWebCenter Portal用のWebLogicネゴシエート・アイデンティティ・アサーション・プロバイダを使用して、Microsoftクライアントでのシングル・サインオン(SSO)をセットアップする方法について説明します。このSSOアプローチによって、Kerberosを使用してWindowsドメイン内で認証されたMicrosoftクライアント(ブラウザなど)は、パスワードを再入力する必要なしで、同じ資格証明に基づいて、WebLogicドメイン内のWebアプリケーション(WebCenter Portalなど)に対して透過的に認証されることが可能になります。WebCenter PortalでのMicrosoft Officeクライアントの使用の詳細は、第26章「Microsoft Office統合の管理」を参照してください。
クロスプラットフォーム認証は、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を構成するには、図33-12に示されている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)を選択し、Kerberosトークンを使用するようにそれを構成します(Oracle Fusion Middleware Oracle Access Manager統合ガイドのKerberosトークンを返すためのブラウザの構成に関する項を参照)。
Kerberos認証を使用するようにWebLogic Serverドメイン(この場合はwc_domain)をセットアップします。
MicrosoftドメインのActive Directoryサーバーと手順2で作成したキータブ・ファイルをポイントするJAASログイン・ファイルを作成します(Oracle Fusion Middleware Oracle WebLogic Serverの保護のJAASログイン・ファイルの作成に関する項を参照)。
WebLogic Serverセキュリティ・レルムでネゴシエート・アイデンティティ・アサーション・プロバイダを構成します(第33.5.3.1項「ネゴシエート・アイデンティティ・アサーション・プロバイダの構成」を参照)。
Active Directoryオーセンティケータを使用するようにWebLogic Serverドメインを構成して、WebLogicドメインがアイデンティティ・ストアと同じActive Directoryドメインを使用するようにします。または、別のアイデンティティ・ストアを使用して、このストアのユーザーをドメインのActive Directoryユーザーと照合することもできますが、2つの異なるアイデンティティ・ストアを使用すると同期が失われる危険性があるため、Active Directoryオーセンティケータを使用することをお薦めします(第33.5.3.2項「Active Directory認証プロバイダの構成」を参照)。
|
注意: アイデンティティ・ストアのみをActive Directory用に構成してください。ポリシーおよび資格証明ストアはActive Directoryに対して認証されません。 |
次のシステム・プロパティを各WebCenter PortalマシンのsetDomainEnv.shのJAVA_OPTIONSに追加します。それぞれの値は、特定のホストの値に変更してください(1行に指定)。
-Dnon_sso_protocol=http (the protocol to access WebCenter Portal directly through the WC_Spaces server without going through OHS) -Dnon_sso_host=example.com (the host for the WLS WC_Spaces server) -Dnon_sso_port=8888 (the port for the WLS WC_Spaces server) -Dsso_base_url=http://example.com:7777 (the URL for accessing the WC_Spaces server through OHS)
non_sso値は、プロトコル、ホストおよびポートについてのマシン上の値です。sso値は、OHSを通してルーティングされた際にユーザーに表示される値です。
WebCenter Portalに対しては、第33.6項「仮想ホストを使用したSSOの構成」の説明に従って、WebCenter Portal用のOracle WebLogic Serverにリクエストを転送するようにWeb層OHSを構成します。
手順5で指定した起動引数を使用して、WebLogic Server (管理サーバーおよび管理対象サーバー)を再起動します。SOAドメインに対して手順4、5および6を繰り返し、SOAアプリケーションでのシングル・サインオンを有効化します。
OHSを再起動して変更を有効にします。
ディスカッション・サーバーを構成します(第33.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管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
セキュリティ・レルムをクリックします。
セキュリティ・レルムの「設定」ページが表示されます。
「プロバイダ」タブを開き、「認証」サブタブを選択します。
「認証設定」ペインが表示されます。
「新規」をクリックします。
「新しい認証プロバイダの作成」ペインが表示されます。
アイデンティティ・アサータの「名前」を入力し、「タイプ」としてNegotiateIdentityAsserterを選択します。
「OK」をクリックします。
次の手順に従って、WebLogic管理コンソールを使用してActive Directory認証プロバイダを構成します。
Active Directory認証プロバイダを構成するには:
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、第1.13.2項「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
セキュリティ・レルムをクリックします。
セキュリティ・レルムの「設定」ページが表示されます。
「プロバイダ」タブを開き、「認証」サブタブを選択します。
「認証設定」ペインが表示されます。
「新規」をクリックします。
「新しい認証プロバイダの作成」ペインが表示されます。
認証プロバイダの「名前」を入力し、「タイプ」としてActiveDirectoryAuthenticatorを選択します。
「OK」をクリックします。
プロバイダのリストで、今作成した認証プロバイダをクリックします。
プロバイダの設定ページが表示されます。
「構成」タブを開き、「共通」サブタブを開きます。
制御フラグをSUFFICIENTに設定し、「保存」をクリックします。
|
注意: 他のすべてのオーセンティケータの制御フラグの設定も、 |
「プロバイダ固有」サブタブを開きます。
プロバイダ固有の設定ペインが表示されます。
次の表に示されているように、各フィールドに値を入力します。これら以外のフィールドは、デフォルト値のままにします。
表33-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クライアントをシングル・サインオン用に構成したら、ユーザーがWebCenter Portalにアクセスしたときにシームレスなシングル・サインオン・エクスペリエンスを提供するための最終ステップを実行する必要があります。これは次の2通りの方法で実行できます。
管理者としてWebCenter Portalにログインし、Public-UserロールからViewアクセスを削除することで、パブリック・アクセスをオフにします。パブリック・アクセスをオフにすると、URL http://host:port/webcenterにアクセスしたユーザーには、ログイン・セクションを持つデフォルト・パブリック・ページではなく、認証されたビューが直接表示されます。これは、ユーザーがInternet Explorerのみを使用してWebCenter Portalにアクセスし、WNAがセットアップされたドメインに限定されている場合にお薦めします。
WebCenter Portalへのパブリック・アクセスを維持する必要がある場合は、WC_Spacesサーバーの起動時にoracle.webcenter.spaces.osso=trueフラグを使用することをお薦めします。このフラグはSSOが使用されていることをWebCenter Portalに告げるため、デフォルトのランディング・ページにログイン・フォームは表示されなくなります。かわりに、ユーザーが自動的にログインしてSSO認証を起動するためのログイン・リンクが表示されます。WNA用に構成されたWindowsネットワーク内でFirefoxを使用してWebCenter Portalにアクセスする場合、またはWindowsネットワーク・ドメインの外側からいずれかのブラウザを使用してWebCenter Portalにアクセスする場合は、ユーザーがこのログイン・リンクをクリックするとログイン・ページが表示されます。
この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。SSO用のディスカッション・サーバーを構成する前に、第31.4.1項「外部LDAPを使用するためのディスカッション・サーバーの移行」の説明に従って、WebCenter Portalと同じアイデンティティ・ストア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が構成されている場合に仮想ホストを構成する手順を説明します。これらの手順を行う前に、第33.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)にシングル・サインオン・エクスペリエンスを提供します。ただし、一部のアプリケーションはこれをサポートしないため、WebCenter Portal仮想ホスト(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と特定仮想ホスト、ディレクトリまたはファイルの関連付けに関する項を参照してください。
これらの手順を完了する前に、第33.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)にはシングル・サインオン・エクスペリエンスを提供しますが、一部のアプリケーションはこれをサポートしないため、WebCenter Portal仮想ホスト(webtier-spaces.example.com)にはシングル・サインオン・エクスペリエンスを提供しないという考え方です。
OHSを再起動します。さらに、webtier-spaces.example.comのエントリによるDNSの更新も行ってください。
|
注意: シングル・サインオンをバイパスする |
仮想ホストにOAM 11gを構成するには、BASIC認証のみをサポートするアプリケーションやシングル・サインオンを必要としないアプリケーションについてシングル・サインオンをバイパスする必要があります。
これらの手順を完了する前に、第33.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)にはシングル・サインオン・エクスペリエンスを提供しますが、一部のアプリケーションはこれをサポートしないため、WebCenter Portal仮想ホスト(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を通してスペースにリダイレクトされて、まだログインしていない場合はログインするように要求されます。
