| Oracle® Fusion Middleware Oracle WebCenter Portalの管理 12c (12.2.1.2.0) E82738-01 |
|
 前 |
 次 |
この章の内容は次のとおりです。
権限
この章のタスクを実行するには、Oracle WebLogic Server管理コンソールでWebLogic ServerのAdminロールが付与されている必要があります。MonitorまたはOperatorロールを持つユーザーは、セキュリティ情報を表示できますが変更することはできません。
「管理操作、ロールおよびツールの理解」も参照してください。
シングル・サインオンでは、ユーザーがコンポーネントにアクセスするたびにログインする必要があるのではなく、1回のログインで済むようにトポロジのコンポーネント全体の認証が提供されます。シングル・サインオンを実装しない場合、ユーザーはWebCenter PortalからディスカッションやContent Serverなどのコンポーネントにアクセスするたびに資格証明を提供する必要があります。
いくつかのソリューションを使用して、WebCenter Portal向けにシングル・サインオンを実装できます。この項では、その利点と推奨アプリケーションを説明します。
オラクル社のエンタープライズ・クラスのアイデンティティ管理とセキュリティ対策のための製品スイートの一部であるOracle Access Manager (OAM)は、WebCenter Portal用のいくつかのシングル・サインオン・オプションを含む広範なアイデンティティ管理およびセキュリティ機能を提供します。OAM (特にOAM 11g)は、Oracle WebCenter Portal 12cのインストールに推奨されるシングル・サインオン・ソリューションです。
Oracle Access ManagerやOracle SSOのようなエンタープライズ・クラスのシングル・サインオン・インフラストラクチャが用意されていない開発環境(非本番環境)で、WebCenter Portalおよび関連するWebツール(ディスカッションなど)内でのみシングル・サインオン機能を提供する必要がある場合は、SAMLベースのSSOソリューションを構成できます。他のエンタープライズ・アプリケーションにもシングル・サインオンを提供する必要がある場合は、このソリューションはお薦めできません。
Active Directoryのユーザー・アカウントによってMicrosoftドメイン・コントローラを使用して認証を行うMicrosoftデスクトップ・ログインを使用している場合は、Microsoftのクライアントに対するSSOの構成も検討できます。
Oracle Access Manager (OAM)は、柔軟で拡張可能な認証と認可のほか、監査サービスを提供します。この項では、WebLogicサーバー側およびSSOに参加するパートナ・アプリケーションとしてのWebCenter Portalアプリケーションの構成方法を含め、OAMシングル・サインオン認証のためにWebCenter Portalを構成する方法を説明します。
次のトピックでは、OAM 11gのインストールと構成の手順を示します。
図28-1は、Oracle Access Managerを使用してWebCenter Portalアプリケーションのシングル・サインオンを設定するために必要なコンポーネントとトポロジを示しています。
OAMは次のコンポーネントから構成されます。
アクセス・サーバー: アクセス・ゲートに対して認証、認可および監査サービスを提供するスタンドアロン・サーバー。OAMには1台のアクセス・サーバーがセットアップされます。これはOAMのインストール自体の一環として行われます。
WebGate: Webリソース(HTTP)リクエストをインターセプトして認証と認可のためにアクセス・サーバーに転送する、すぐに利用可能なプラグイン。
アイデンティティ・アサーション・プロバイダ(IAP): 境界認証によって設定されるヘッダー情報に基づいてユーザーのアイデンティティをアサートするセキュリティ・プロバイダの種類。OAMの統合により、OAM IAPとして構成できるOAM IDアサータが提供されます。OAM IDアサータは、認証またはアイデンティティ・アサーションに使用できます。OAM SSOの統合では、プロバイダの「共通」設定の「アクティブなタイプ」でobSSOCookieを選択して、アイデンティティ・アサーション・プロバイダ(IAP)としてOAM IDアサータを構成することが必要です。
OAMシングル・サインオン・プロセスのフロー
図28-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アプリケーションを実行中のWLSサーバーにリダイレクトされて、そこから目的のコンテンツやアプリケーションがユーザーに提供されます。
WebGate→mod_wl→WebCenter Portalアプリケーション(ディスカッションなど)→コンテンツが認証されたユーザーに提供されます
認可ポリシーでアクセスが拒否されている場合は、管理者が決定した別のURLにユーザーはリダイレクトされます。
図28-3と表28-1は、OAMを使用してWebCenter Portalのシングル・サインオンを構成するために必要な前提条件とタスクの概要を示しています。
表28-1は、OAMを使用してWebCenter Portalのシングル・サインオンを構成するためのタスクとサブタスクを示しています。
表28-1 OAMを使用したWebCenter Portalのシングル・サインオンの構成
| 担当者 | タスク |
|---|---|
管理者 |
|
| 管理者 |
2.a Oracle Internet Directoryオーセンティケータの構成 |
| 管理者 | |
| 管理者 |
4.d 外部リーダーを使用したRSSフィード用のOAMの構成 |
| 管理者 |
この項では、OAM 11gのインストールおよび構成方法について説明し、次の内容を含みます。
注意:
OAMは、Oracle WebCenter Portalと目的の環境に必要なその他のコンポーネントをインストールした後でインストールする必要があります。また、必要な接続も、すべて事前に構成およびテストしてください。
『Oracle Identity Managementインストレーション・ガイド』のOracle Identity Managementのインストールと構成に関する項の説明に従って、Oracle Access Manager (OAM)をインストールします。理想的なシナリオは、OAMとシングル・サインオンに参加するすべてのアプリケーションが同じアイデンティティ・ストアを共有することです。デフォルトでは、OAMは組込みのLDAPアイデンティティ・ストアを使用します。
OIDなどの外部アイデンティティ・ストアを使用するようにOAMを構成するには、『Oracle Access Management管理者ガイド』の新しいユーザー・アイデンティティ・ストアの登録に関する項を参照してください。この項には、デフォルトまたはシステム・ストアとして構成された外部アイデンティティ・ストアを設定し、このストアをポイントするように1つ以上の認証モジュールを構成するためのポインタが示されています。デフォルトでは、OAMに構成されたWebCenterポリシーは、OAMに指定されたデフォルト認証スキーム(通常はフォームベースの認証スキームLDAPScheme)を使用します。
デフォルト・スキームを使用する場合は、スキームが使用する認証モジュールは、WebCenterのインストールと同じアイデンティティ・ストアをポイントする必要があります。オプションとして、デフォルト以外の認証スキームを構成することができます。この場合も、WebCenterが使用するアイデンティティ・ストアをこれが確実にポイントするようにしてください。それから、『Oracle Identity Managementインストレーション・ガイド』のOracle Identity Managementのインストールと構成に関する項の説明に従って、WebLogic管理ドメインでOracle Access Managerを構成します。
Oracle HTTP Server (OHS)がインストールされていない場合、「Oracle HTTP Serverのインストールと構成」の説明に従ってOHSをインストールします。
インストールが終了したら、「Web層でのWebGateのインストール」の説明に従ってWebGateをインストールします。
この項では、OHS WebGateのインストールおよび構成方法について説明します。
注意:
OHS WebGateのインストール中は必ずOracle HTTP Serverを停止し、「WebGateエージェントの登録」の説明に従ってWebGateエージェントを登録した後でのみ再起動してください。
Web層にWebGateをインストールしたら、WebGateエージェントの登録も行う必要があります。次の手順では、OAMのインストールで構成されたデフォルト認証スキーム(通常はフォームベースの認証スキームLDAPScheme)を使用する保護されたポリシーを自動的に作成します。シングル・サインオンのログイン・ページをカスタマイズする場合、または他の認証スキームでリソースを保護する場合は、OAMコンソールを使用してそれを変更してください(詳細は、『Oracle Access Management管理者ガイド』の認証スキームの管理に関する項を参照)。
注意:
環境でWebCenter Portalとともに他のアプリケーションを使用しており、これらのアプリケーションにシングル・サインオンが必要な場合は、これらのアプリケーションで使用される認証スキームが同じであるか、少なくとも同じレベルで、同じアイデンティティ・ストアをポイントしていることが必要です。
WebGateエージェントの登録の詳細は、『WebGate for 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層と関連するコンポーネントをインストールおよび構成したら、「OAM用のWebLogicドメインの構成」の説明に従ってポリシー・マネージャを構成し、「追加のシングル・サインオン構成」の説明に従って適用される追加のサービスとコンポーネントの構成を実行します。
環境が複数のドメインにまたがっている場合(例: WebCenter Portalのドメイン、別個のSOAのドメインおよび別個のContent Serverのドメイン)、それぞれのドメインについてこの項の手順を繰り返してください。
この項では、次の内容について説明します。
Oracle Internet DirectoryがOAMアイデンティティ・ストアをバッキングしている場合、Oracle Internet Directoryオーセンティケータ(OracleInternetDirectoryAuthenticator)はOAMのアイデンティティ・ストアとして使用されているLDAPサーバー用に構成し、プロバイダはSUFFICIENTに設定する必要があります。
Oracle Internet Directoryオーセンティケータを構成するには:
OAMアイデンティティ・アサータは、プロバイダの制御フラグをREQUIREDに設定して構成する必要があります。
OAMアイデンティティ・アサータを構成するには:
OAMアイデンティティ・アサータを構成したら、デフォルト・オーセンティケータの制御フラグがSUFFICIENTに設定されていることを確認して、次のようにプロバイダを並べ替えます。
この手順は、OAMをインストールおよび構成した後、WebLogicドメインを構成する前に実行する必要があります。
Oracle HTTP Server(OHS)をインストールおよび構成する手順は次のとおりです。
次の項で説明する構成は、サイトのセキュリティを強化するために必要であるか、または役に立ちます。これらの構成が完了したら、「OAMインストールのテスト」の説明に従ってOAMインストールのテストを行ってください。
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_Portalサーバーを再起動します。
この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。SSO用のディスカッション・サーバーを構成する前に、「外部LDAPサーバーへのアイデンティティ・ストアの再関連付け」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。デフォルトの管理者アカウントを外部LDAPに移動しないことを選択した場合は、「外部LDAPを使用するためのディスカッション・サーバーの移行」の指示にも従ってください。
注意:
SSOの構成後は、ディスカッション・サーバーへの直接のログインはサポートされません。ログインはOracle HTTP Server URLを通して行う必要があります。
SSO用のディスカッション・サーバーを設定する手順は次のとおりです。
すでにSOAサーバー接続をセットアップしてある場合は、SOAサーバーのホストとポートのかわりにWeb層のホストとポートを使用するようにURLを変更します。このことは、「WebCenter PortalワークフローをホスティングするBPELサーバーの指定」の説明に従い、Fusion Middleware Controlを使用して実行できます。
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フィードを非保護にする手順は次のとおりです。
この項では、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エージェントの登録時に作成したホスト識別子を選択します。
「リソース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接続の構成の詳細は、「Oracle SES接続の設定」を参照してください。
SSOのセットアップが完了し、Content Serverの接続をセットアップしたら、Fusion Middleware Controlを使用して、または次のWLSTの例のように、JCRContentServerConnectionにWebコンテキスト・ルートを指定します。
setJCRContentServerConnection(appName, name, webContextRoot='/cs')
Webコンテキスト・ルートを設定することで、SSOがセットアップされていることをドキュメント・ライブラリのコードに伝えます。この設定は、SSOを完全にセットアップするまでは設定しないでください。
ユーザーが適切に認証されるように、Web層OHSポートを通してのみWebCenter Portalおよび関連するコンポーネントへのアクセスを許可するには、次の手順に従います。
OAM 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アクセス出力から取得します)。ログイン・チャレンジは表示されず、パブリック・コンテンツを表示できるはずです。ログイン後にこれにアクセスすると、アクセス権を持つすべてのコンテンツが表示されるはずです。
Content Server: プロファイルUIに移動し、ログインをチャレンジされずに、iFrame内に埋め込まれているContent Server画面が表示できることを確認します。すでにWebCenter Portalにログインしている際には、ログインせずにコンテンツ・プレゼンタ・テンプレートのSite Studioコンテンツにもアクセスできます。
SOA: ワークフロー・タスク・フローのリンクにアクセスして、ログインをチャレンジされないことを確認します。
ディスカッション・フォーラム: ディスカッション・アプリケーション(http://host:port/owc_discussions)にアクセスして、ログインします。ログインがSSOログイン・チャレンジであることを確認します。同様に、ディスカッション・サーバー(http://host:port/owc_discussions/admin)に管理者ログインする場合も、SSOログイン・チャレンジを使用する必要があります。
Security Assertion Markup Language (SAML)によって、WebLogic ServerドメインおよびWebブラウザまたは他のHTTPクライアントで実行されているWebベースのアプリケーションやWebサービス間でクロスプラットフォームの認証が可能になります。WebLogic Serverは、WebCenter Portalに対して、SAMLに基づくシングル・サインオン(SSO)をサポートします(ページレット・プロデューサ・アプリケーションはサポートされません)。
シングル・サインオン構成に参加する1つのサイトでユーザーが認証されると、SSO構成の他のサイトでも自動的に認証され、別途ログインする必要はありません。ページレット・プロデューサ・アプリケーションはSAML SSOに参加しないので、ページレット・プロデューサ・アプリケーションにアクセスするユーザーは明示的にログインする必要があることに注意してください。
注意:
SAMLベースのシングル・サインオンは、初回サインオン後の後続のアプリケーションへのユーザーのログオンはサポートしますが、グローバル・ログアウトはサポートしません。このため、ユーザーは、開いた各アプリケーションを個々にログアウトする必要があります。
また、WebCenter Portalをソース・アプリケーション、ディスカッションを宛先アプリケーションとして使用して、SAMLベースのシングル・サインオンをセットアップすると、管理者はWebCenter Portal管理(「構成」→「サービス」)とポータル設定(「サービス」ページ)からディスカッション管理ページにアクセスできることにも注意してください。ただし、ディスカッション管理ページはSSOに参加しないので、管理ページに直接アクセスすると、ディスカッション・サーバーへの再ログインが必要になります。
さらに、SAMLベースのシングル・サインオンは、sdpmessaging userprefs-uiアプリケーションでは使用できません。アプリケーション管理者がWebCenter Portalの「プリファレンス」→「メッセージング」ダイアログで「構成の管理」をクリックすると、再ログインが必要になります。
このSSOメカニズムは、Oracle SSOまたはOracle Access Managerシングル・サインオン・インフラストラクチャがまだ存在しておらず、WebCenter Portalとそのコンポーネントまたはサービス間のみのシングル・サインオンが必要とされる部門別のインストールに使用できます。大規模エンタープライズの高可用性展開では、Oracle Access Manager SSOをお薦めします。
この項では、同じドメイン内の異なる管理対象サーバー上で実行されるWebCenter PortalおよびSOAに対してSAML 1.1ベースのシングル・サインオンをセットアップする方法を説明します。
この項には次のトピックが含まれます:
図28-5は、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アサーションの形式でセキュリティ情報をアサートする権限を持つエンティティ)です。
図28-4は、WebCenter PortalとSOAドメインの両方を含む、POSTが構成されたSAML SSO構成のコンポーネントとフローを示しています。このフローは、ディスカッションのようなシングル・サインオンに参加する他の宛先アプリケーションの場合と似ています。
図28-4 詳細なSAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)
図28-5は、WebCenter Portalとディスカッション・アプリケーションの間のSAML SSOフローを含む、POSTが構成されたSAML SSO構成の簡略化されたバージョンのコンポーネントとフローを示しています。
図28-5 SAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)
フローの手順は次のとおりです。
ユーザーのブラウザが、ユーザーの資格証明を入力して、WebCenter Portalドメイン(wc_domain)のWebLogic管理対象サーバー(WC_Portal)上にホストされているWebCenter Portal (ソース・サイト)にアクセスします。
WebCenter Portalが、認証サービス・プロバイダにユーザーの資格証明を渡します。
認証に成功すると、認証されたセッションが確立されて、WebCenter Portalのようこそページが表示されます。
ユーザーがようこそページで、同じドメインの異なるWebLogic Server (WC_Collaboration)上にホストされているディスカッション宛先サイトのセキュアなWebページにアクセスするためのリンクをクリックします。これによって、構成されているサイト間転送サービス(ITS)サーブレットへのコールがトリガーされます。この場合は、ITSサーブレットが、WebCenter Portalと同じJSESSIONID Cookieを共有するソース・サイト内(つまり、WC_Portal管理対象サーバー上のWebCenter Portalアプリケーション上)にホストされます。
ITSサーブレットは、WebCenter Portalドメイン(wc_domain)で構成されているSAML資格証明マッパーをコールして、コール元アサーションをリクエストします。SAML資格証明マッパーはアサーションを返します。また、宛先サイト・アプリケーションWebページ(ディスカッション用のセキュアなWebページ)のURLと適切なPOSTフォームのパス(ソース・サイトがPOSTプロファイルを使用するように構成されている場合)も返します。
SAML ITSサーブレットが、生成されたアサーションを含むSAMLレスポンスを生成し、それに署名して、BASE64にエンコードし、HTMLフォームに埋め込んで、そのフォームをユーザーのブラウザに返します。
ユーザーのブラウザがそのフォームを宛先サイトのアサーション・コンシューマ・サービス(ACS)にPOSTします。この場合は、ACSサーブレットが宛先サイト(ディスカッション)にホストされ、そのログインCookieを共有します。
アサーションが検証されます。
アサーションに成功すると、ユーザーがターゲット(ディスカッションのセキュアなWebページ)にリダイレクトされます。
ユーザーは再認証の必要なしで宛先サイト(ディスカッション)にログインします。
この項では、一連の自動化されたスクリプトを使用して、SAML1.1ベースのシングル・サインオンに対応するようにWebCenter Portalおよび関連するサービスとコンポーネントを構成する方法について説明します。
この項には次のトピックが含まれます:
この項では、SAMLベースのシングル・サインオンを構成する前に実行する必要がある一連の手順を説明します。これらの手順では、WebCenter Portalと関連付けられたコンポーネントがインストール済で、関連する接続が構成およびテスト済であることを前提としています。
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の編集の詳細は、「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用のディスカッション・サーバーを構成する前に、「外部LDAPサーバーへのアイデンティティ・ストアの再関連付け」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。デフォルトの管理者アカウントを外部LDAPに移動しないことを選択した場合は、「外部LDAPを使用するためのディスカッション・サーバーの移行」の指示にも従ってください。
SAML SSOバージョンのOracle WebCenter Portalのディスカッション・サーバーをデプロイおよび構成する手順は次のとおりです。
SAMLのソース・サイトと宛先サイト間の通信を保護するために、通信を暗号化する必要があります。さらに、証明書を使用して、SAMLの対話時に他のパーティのアイデンティティを検証することが必要です。
次の例に示すように、getOpssService、listKeyStoreAliasesおよびexportKeyStoreCertificateのWLSTコマンドを使用して、SAMLアサーションの暗号化に使用するために選択した証明書を取得およびエクスポートします。必ずWebCenter Portalドメインの管理サーバーとWC_Portalに対して構成されたキーストア上でexportKeyStoreCertificateコマンドを実行するようにしてください。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスを使用したキーと証明書の管理に関する項を参照してください。これらのコマンドの構文の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスのコマンド・リファレンスに関する項を参照してください。
次の例では、デフォルトでWebLogic Serverに構成されているdemoidentityキーストアで使用可能なDemoIdentity証明書をエクスポートする方法を説明します。現在の環境で構成されているキーストアの証明書をリストしてエクスポートし、SAML構成で使用するためのガイドラインとして使用してください。
connect()
svc = getOpssService(name='KeyStoreService')
svc.listKeyStoreAliases(appStripe="system", name="demoidentity", password='DemoIdentityKeyStorePassPhrase', type="*")
svc.exportKeyStoreCertificate(appStripe='system', name='demoidentity', password='DemoIdentityKeyStorePassPhrase', alias='DemoIdentity',
type='Certificate', filepath='/tmp/demoidentity.der'
注意:
前述のfilepathに使用されるパスは、wcsamlsso.propertiesのcertPathの値に一致する必要があります。また、証明書はPEM/DER形式でのみエクスポートする必要があることに注意してください。トランスポートレベルのセキュリティを提供するためにWebCenter PortalのインストールでSSLを必要とする場合は、「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
configureSpaces.py
configureCollab.py
configureUtilities.py
configureSOA.py
configureUCM.py
configureREST.py
configureForum.py
configureWorklistIntegration.py
configureCS.py
configureBPM.py
wcsamlsso.properties
このプロパティ・ファイル(WCP_ORACLE_HOME/webcenter/scripts/samlsso/wcsamlsso.properties)は、SAML SSOのセットアップに必要な構成情報をカプセル化します。構成スクリプトを実行する前に、プロパティ・ファイルをWCP_ORACLE_HOME/common/binフォルダにコピーし、ディレクトリをそのフォルダに変更して、次で説明するようにwcsamlsso.propertiesを編集します。
プロパティ・ファイルには次のセクションがあります。
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がインストールされ、ポータル・ワークフローが有効化されている場合は、このセクションを指定してください。詳細は、「WebCenter PortalワークフローをホスティングするBPELサーバーの指定」を参照してください。
worklist_integration - ワークリスト統合アプリケーションURL。soa_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層を使用して両方にアクセスする必要があります。
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)
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)。
configureBPM.py
Oracle BPMワークリストのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureBPM.py)。
SAMLベースのシングル・サインオンを構成するスクリプトを使用する手順は次のとおりです。
注意:
スクリプトの実行中に構成ミスによるエラーが発生した場合、SAML SSO構成は未完了の状態で終了する可能性があります。提供された構成スクリプトを再実行できない場合は、「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を編集して、セットアップに適用されるセクションを指定します。プロパティ・ファイルのセクションの詳細な説明は、「シングル・サインオンのスクリプト」を参照してください。
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のSOAサーバー接続を構成してある場合は、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/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がインストールされている場合はこれを行ってください。再起動は不要です。
execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureBPM.py') - セットアップにOracle BPMワークリストがインストールされている場合はこれを行ってください。再起動は不要です。
「構成のチェック」の手順を使用して、インストールをチェックします。
注意:
プロパティ・ファイルには機密情報が含まれているので、SAML SSOセットアップの構成および検証後に<WCP_ORACLE_HOME>/common/binからこれを削除してください。また、前述の手順2で生成した構成ファイルとキー・ファイルも削除してください。
注意:
スクリプトの実行中にエラーが発生した場合は、スクリプトを再実行する前に、「SAML SSO構成の削除」の説明に従って、スクリプトによってセットアップされたアサーティングおよびリライイング・パーティを削除する必要があります。
古いSAML SSO構成を削除したら、スクリプトを再実行してください。
デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護されたままの状態では、それらは外部リーダーでうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できるWebLogic ServerのBASIC認証によってRSSサーブレットの認証が処理されるように、WebCenter Portal RSSリソースを非保護にすることをお薦めします。
次の手順に従って、RSSフィードを非保護にします。
次の手順に従って、シングル・サインオン構成が正しく動作することをチェックします。
シングル・サインオン構成をテストする手順は次のとおりです。
http://host:port/rest/api/resourceIndexにアクセスし、BASIC認証チャレンジが表示されることを確認します。同じSSOを使用する別の関連アプリケーションにすでにログインしている場合は、ログインへのチャレンジなしでコンテンツを表示できるはずです。SAML SSOのテスト中にエラー404または403が発生した場合は、SAML構成を確認して、AdminServerでのSAMLのデバッグ・ロギングも有効化します。また、WC_Portalサーバーおよび宛先サイトをホストしているサーバーのロギングも有効化します。ログは$domain.home/servers/<server>/logs/<server>.logで使用可能です。WC_Portalおよび他のアプリケーション・サーバーのロギングの有効化方法の詳細は、「WebCenter Portalログの表示および構成」を参照してください。スクリプトを再実行する前に、「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クライアントの使用の詳細は、第25章「Microsoft Office統合の管理」を参照してください。
プラットフォームを越えた認証は、元々Windowsシステム間で行われているKerberosプロトコルを使用した認証サービスをエミュレートすることで実現されます。クロスプラットフォーム認証を有効にするためには、非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フレームワーク1.1および適切に構成されたWebサービス・クライアント。
注意:
クライアントはWindows 2000のドメインにログオンしていて、そのドメイン内のActive Directoryサーバーから取得したKerberosの資格証明を保持している必要があります。ローカル・ログインは機能しません。
MicrosoftクライアントでSSOを構成するには、図28-8に示されている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 Argus Insightインストレーション・ガイドのKerberosトークンを返すためのブラウザの構成に関する項を参照)。
Kerberos認証を使用するようにWebLogic Serverドメイン(この場合はwc_domain)をセットアップします。
MicrosoftドメインのActive Directoryサーバーと手順2で作成したキータブ・ファイルをポイントするJAASログイン・ファイルを作成します(『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの管理』のJAASログイン・ファイルの作成に関する項を参照)。
WebLogic Serverセキュリティ・レルムでネゴシエート・アイデンティティ・アサーション・プロバイダを構成します(「ネゴシエート・アイデンティティ・アサーション・プロバイダの構成」を参照)。
Active Directoryオーセンティケータを使用するようにWebLogic Serverドメインを構成して、WebLogicドメインがアイデンティティ・ストアと同じActive Directoryドメインを使用するようにします。または、別のアイデンティティ・ストアを使用して、このストアのユーザーをドメインのActive Directoryユーザーと照合することもできますが、2つの異なるアイデンティティ・ストアを使用すると同期が失われる危険性があるため、Active Directoryオーセンティケータを使用することをお薦めします(「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_Portal server without going through OHS) -Dnon_sso_host=example.com (the host for the WLS WC_Portal server) -Dnon_sso_port=8888 (the port for the WLS WC_Portal server) -Dsso_base_url=http://example.com:7777 (the URL for accessing the WC_Portal server through OHS)
non_sso値は、プロトコル、ホストおよびポートについてのマシン上の値です。sso値は、OHSを通してルーティングされた際にユーザーに表示される値です。
WebCenter Portalに対しては、「仮想ホストを使用したSSOの構成」の説明に従って、WebCenter Portal用のOracle WebLogic Serverにリクエストを転送するようにWeb層OHSを構成します。
手順5で指定した起動引数を使用して、WebLogic Server (管理サーバーおよび管理対象サーバー)を再起動します。SOAドメインに対して手順4、5および6を繰り返し、SOAアプリケーションでのシングル・サインオンを有効化します。
OHSを再起動して変更を有効にします。
ディスカッション・サーバーを構成します(「SSO用のディスカッション・サーバーの構成」を参照)。
この項では、ネゴシエート・アイデンティティ・アサーション・プロバイダの作成および構成手順を説明します。ネゴシエーションIDアサーション・プロバイダを使用すると、Microsoft社製のクライアントでシングル・サインオン(SSO)を利用できます。アイデンティティ・アサーション・プロバイダは、SPNEGO(Simple and Protected Negotiate)トークンをデコードして、Kerberosトークンを取得し、それらのKerberosトークンを検証して、それらをWebLogicユーザーにマップします。ネゴシエート・アイデンティティ・アサーション・プロバイダはJava GSS(Generic Security Service) API(Application Programming Interface)を使用して、Kerberosを通してGSSセキュリティ・コンテキストを受け付けます。
ネゴシエート・アイデンティティ・アサーション・プロバイダを構成するには:
次の手順に従って、WebLogic管理コンソールを使用してActive Directory認証プロバイダを構成します。
Active Directory認証プロバイダを構成するには:
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
セキュリティ・レルムをクリックします。
セキュリティ・レルムの「設定」ページが表示されます。
「プロバイダ」タブを開き、「認証」サブタブを選択します。
「認証設定」ペインが表示されます。
「新規」をクリックします。
「新しい認証プロバイダの作成」ペインが表示されます。
認証プロバイダの「名前」を入力し、「タイプ」としてActiveDirectoryAuthenticatorを選択します。
「OK」をクリックします。
プロバイダのリストで、今作成した認証プロバイダをクリックします。
プロバイダの「設定」ページが表示されます。
「構成」タブを開き、「共通」サブタブを開きます。
「制御フラグ」をSUFFICIENTに設定して、「保存」をクリックします。
注意:
他のすべてのオーセンティケータの制御フラグの設定も、SUFFICIENTに変更する必要があります。制御フラグがREQUIREDに設定された既存のデフォルト・オーセンティケータがある場合は、これをSUFFICIENTに変更する必要があります。
「プロバイダ固有」サブタブを開きます。
プロバイダ固有の設定ペインが表示されます。
次の表に示されているように、各フィールドに値を入力します。これら以外のフィールドは、デフォルト値のままにします。
表28-2 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_Portalサーバーの起動時にoracle.webcenter.spaces.osso=trueフラグを使用することをお薦めします。このフラグはSSOが使用されていることをWebCenter Portalに告げるため、デフォルトのランディング・ページにログイン・フォームは表示されなくなります。かわりに、ユーザーが自動的にログインしてSSO認証を起動するためのログイン・リンクが表示されます。WNA用に構成されたWindowsネットワーク内でFirefoxを使用してWebCenter Portalにアクセスする場合、またはWindowsネットワーク・ドメインの外側からいずれかのブラウザを使用してWebCenter Portalにアクセスする場合は、ユーザーがこのログイン・リンクをクリックするとログイン・ページが表示されます。
この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。SSO用のディスカッション・サーバーを構成する前に、「外部LDAPを使用するためのディスカッション・サーバーの移行」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。
SSO用のディスカッション・サーバーを設定する手順は次のとおりです。
この項では、コンテキスト・ルートとして/を使用するアプリケーションを含む環境に必要なOHS構成と、シングル・サインオンが呼び出される際にOHSで必要な追加構成について説明します。
この項には次のサブセクションが含まれます:
仮想ホストという用語は、1台のマシン上で複数のWebサイト(www.company1.comとwww.company2.comなど)を実行することを示します。仮想ホストはIPベース(それぞれのWebホストごとに異なるIPアドレスを持つこと)にすることも、名前ベース(各IPアドレスに複数の名前を持つこと)にすることもできます。それらが同じ物理サーバー上で動作しているという事実は、エンド・ユーザーにはわかりません。仮想ホストの詳細は、Apacheのドキュメントを参照してください。
仮想ホスト用にOAM 11gを構成するには、BASIC認証のみをサポートするアプリケーションやシングル・サインオンを必要としないアプリケーションについてシングル・サインオンをバイパスする必要があります。
これらの手順を完了する前に、「Oracle Access Managerの構成」に示されている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の更新も行ってください。
注意:
シングル・サインオンをバイパスするwebtier-spaces.example.com仮想ホストでは、シングル・サインオンをバイパスする必要があるのは、一部のアプリケーションのみです。WebCenter Portalなどの他のアプリケーションでは、シングル・サインオンが必要なため、この仮想ホストからそれらのアプリケーションへのアクセスは拒否されます。
