26 シングル・サインオンの構成
ノート:
Oracle WebCenter Portalでは、Jive機能(お知らせおよびディスカッション)のサポートが非推奨となりました。リリース12c (12.2.1.4.0)より前のリリースからアップグレードした場合、アップグレードしたインスタンスでJive機能は使用可能なままですが、これらの機能にOracleサポートは提供されません。次のリリースでは、アップグレードしたインスタンスでもJive機能は使用できなくなります。
権限:
この章のタスクを実行するには、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の構成
Oracle Access Manager (OAM)は、柔軟で拡張可能な認証と認可のほか、監査サービスを提供します。この項では、WebLogicサーバー側およびSSOに参加するパートナ・アプリケーションとしてのWebCenter Portalアプリケーションの構成方法を含め、OAMシングル・サインオン認証のためにWebCenter Portalを構成する方法を説明します。
次のトピックでは、OAM 11gのインストールと構成のステップを示します。
OAMのコンポーネントとトポロジ
図26-1は、WebCenter Portalアプリケーション用にOracle Access Managerを使用してシングル・サインオンをセットアップするために必要なコンポーネントとトポロジを示しています。
OAMは次のコンポーネントから構成されます。
-
アクセス・サーバー – アクセス・ゲートに対して認証、認可および監査サービスを提供するスタンドアロン・サーバー。OAMには1台のアクセス・サーバーがセットアップされます。これはOAMのインストール自体の一環として行われます。
-
WebGate – Webリソース(HTTP)リクエストをインターセプトして認証と認可のためにアクセス・サーバーに転送する、すぐに利用可能なプラグイン。
-
アイデンティティ・アサーション・プロバイダ(IAP) – 境界認証によって設定されるヘッダー情報に基づいてユーザーのアイデンティティをアサートするセキュリティ・プロバイダの種類。OAMの統合により、OAM IAPとして構成できるOAM IDアサータが提供されます。OAM IDアサータは、認証またはアイデンティティ・アサーションに使用できます。OAM SSOの統合では、プロバイダの「共通」設定の「アクティブなタイプ」で
obSSOCookie
を選択して、アイデンティティ・アサーション・プロバイダ(IAP)としてOAM IDアサータを構成することが必要です。
OAMシングル・サインオン・プロセスのフロー
図26-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にユーザーはリダイレクトされます。
-
OAM構成のロードマップ
表26-1は、OAMを使用してWebCenter Portalのシングル・サインオンを構成するために必要な前提条件とタスクの概要を示しています。
表26-1 OAMを使用したWebCenter Portalのシングル・サインオンの構成
担当者 | タスク |
---|---|
管理者 |
|
管理者 |
|
管理者 | |
管理者 |
OAM 11gのインストールと構成
この項では、OAM 11gのインストールおよび構成方法について説明し、次の内容を含みます。
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のインストールと構成
Oracle HTTP Server 12cまたはOracle HTTP Server 11gのインストールを選択できます。このステップは、OAMをインストールおよび構成した後、WebLogicドメインを構成する前に実行する必要があります。
Oracle HTTP Serverをインストールして構成するには:
Oracle HTTP Server WebGateの構成
Oracle HTTP Server WebGate for Oracle Access Managerを構成する必要があります。Oracle HTTP Server WebGateは、HTTPリクエストをインターセプトし、それを認証および認可のために既存のOracle Access Managerインスタンスに転送するプラグインです。
Oracle HTTP Server 12c WebGateの構成
Oracle HTTP Server 12cをインストールした場合は、インストールの一部としてWebGateソフトウェアがインストールされています。Oracle HTTP Server 12c WebGateの構成の詳細は、『Oracle HTTP Serverのインストールと構成』の「Oracle HTTP Server WebGate for Oracle Access Managerの構成」を参照してください。
Oracle HTTP Server 11g WebGateのインストールと構成
Oracle HTTP Server 11gを使用している場合は、Oracle HTTP Server 11g WebGate for Oracle Access Managerをインストールして構成します。
Webゲート・エージェントの登録
Web層にWebGateをインストールしたら、WebGateエージェントの登録も行う必要があります。次のステップでは、OAMのインストールで構成されたデフォルト認証スキーム(通常はフォームベースの認証スキームLDAPScheme
)を使用する保護されたポリシーを自動的に作成します。シングル・サインオンのログイン・ページをカスタマイズする場合、または他の認証スキームでリソースを保護する場合は、OAMコンソールを使用してそれを変更してください。
ノート:
環境でWebCenter Portalとともに他のアプリケーションを使用しており、これらのアプリケーションにシングル・サインオンが必要な場合は、これらのアプリケーションで使用される認証スキームが同じであるか、少なくとも同じレベルで、同じアイデンティティ・ストアをポイントしていることが必要です。
次のステップに従って、インバンド・モードで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ドメインの構成」の説明に従ってポリシー・マネージャを構成し、「追加のシングル・サインオン構成」の説明に従って適用される追加のサービスとコンポーネントの構成を実行します。
OAM用のWebLogicドメインの構成
環境が複数のドメインにまたがっている場合(たとえば、WebCenter Portalのドメイン、別個のSOAのドメインおよび別個のContent Serverのドメイン)、それぞれのドメインについてこの項のステップを繰り返してください。
この項では、次の内容について説明します。
Oracle Internet Directoryオーセンティケータの構成
Oracle Internet DirectoryがOAMアイデンティティ・ストアをバッキングしている場合、Oracle Internet Directoryオーセンティケータ(OracleInternetDirectoryAuthenticator
)はOAMのアイデンティティ・ストアとして使用されているLDAPサーバー用に構成し、プロバイダはSUFFICIENT
に設定する必要があります。
Oracle Internet Directoryオーセンティケータを構成するには:
OAMアイデンティティ・アサータの構成
OAMアイデンティティ・アサータは、プロバイダの制御フラグをREQUIRED
に設定して構成する必要があります。
OAMアイデンティティ・アサータを構成するには:
デフォルト・オーセンティケータとプロバイダの順序の構成
OAMアイデンティティ・アサータを構成したら、デフォルト・オーセンティケータの制御フラグがSUFFICIENT
に設定されていることを確認して、次のようにプロバイダを並べ替えます。
追加のシングル・サインオン構成
次の項で説明する構成は、サイトのセキュリティを強化するために必要であるか、または役に立ちます。これらの構成が完了したら、「OAMインストールのテスト」の説明に従ってOAMインストールのテストを行ってください。
SSO用のWebCenter Portalの構成
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用のディスカッション・サーバーの構成
この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。SSO用のディスカッション・サーバーを構成する前に、「外部LDAPサーバーへのアイデンティティ・ストアの再関連付け」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。デフォルトの管理者アカウントを外部LDAPに移動しないことを選択した場合は、「外部LDAPを使用するためのディスカッション・サーバーの移行」の指示にも従ってください。
ノート:
SSOの構成後は、ディスカッション・サーバーへの直接のログインはサポートされません。ログインはOracle HTTP Server URLを通して行う必要があります。
SSO用のディスカッション・サーバーを設定するには:
SSO用のSOAサーバー接続の構成
すでにSOAサーバー接続をセットアップしてある場合は、SOAサーバーのホストとポートのかわりにWeb層のホストとポートを使用するようにURLを変更します。このことは、「WebCenter PortalワークフローをホスティングするBPELサーバーの指定」の説明に従い、Fusion Middleware Controlを使用して実行できます。
URLを変更してOAM SSOに必要な設定を完了したら、WebCenter Portal管理サーバー上で次のコマンドを実行して変更を有効にします。
setBPELConnection('webcenter','WebCenter-Worklist', 'http://webtier.example.com:7777')
外部リーダーを使用したRSSフィード用のOAMの構成
デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護されたままの状態では、それらは外部リーダーでうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できるWebLogic ServerのBASIC認証によってRSSサーブレットの認証が処理されるように、WebCenter Portal RSSリソースをOAMポリシーから除外することをお薦めします。
OAM 11gのRSSフィードを非保護にするステップは次のとおりです。
OAM 11g用のWebLogic Server管理コンソールとEnterprise Managerの構成
この項では、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/emOAMのSSOログイン・フォームのプロンプトが表示されます。
SSO用のElasticsearchの構成
WebCenter PortalとElasticsearchに定義された対応する認証エンド・ポイントが使用するWebCenter Portalデータとリポジトリをクロールするために定義されるクロール・ソースは、適切に認証されるようにWeb層OHSポートを通してルーティングする必要があります(認証方式は引き続きBASICになります)。
Elasticsearchを適切に機能させるには、Web層のOHSポートを介してルーティングされるWebCenter ContentのクロールURLがOAMポリシーで除外されていることを確認します。
WebCenter ContentのクロールURLを除外するには:
-
Oracle Access Managementコンソールにログインし、「アプリケーション・セキュリティ」をクリックします。
-
「アプリケーション・セキュリティ」ページで、「Access Manager」セクションの「アプリケーション・ドメイン」リンクをクリックします。
-
「アプリケーション・ドメイン」ページで、アプリケーション・ドメインの名前を入力し、「検索」をクリックします。
-
検索結果から、アプリケーション・ドメインをクリックして開きます。
-
「リソース」タブを開き、「作成」をクリックします。
-
「リソースの作成」ページで、必要な詳細を入力します。
-
タイプ: リソース・タイプとしてHTTPを選択します。
-
説明: リソースの説明を入力します。
-
ホスト識別子: WebGateエージェントの登録時に作成されたホスト識別子を選択します。
-
リソースURL: リソースURLを
/cs/idcplg
と入力します -
問合せ: 「名前と値のリスト」を選択し、「追加」アイコンをクリックして値を追加します。名前を
IdcService
、値をSES_CRAWLER_*
と入力します。 -
操作: すべての操作を選択します
-
保護レベル: 「除外」を選択します
-
-
「適用」をクリックします。
-
Oracle Access Managementの除外が適切に構成されているかどうかを確認するには:
-
Oracle WebCenter Portalに管理者としてログインします。
-
ドキュメント・クロール用のOracle HTTP Server URLを構成します。「ドキュメント・クロール・ソースの作成」を参照してください。
-
「テスト」をクリックして、ドキュメント・クロール・エンドポイントをテストします。
OAMの除外が適切に構成されている場合、テストは成功です。
-
SSO用のContent Serverの構成
SSOのセットアップが完了し、Content Serverの接続をセットアップしたら、Fusion Middleware ControlまたはWLSTコマンドsetContentServerConnection
を使用して、Webコンテキスト・ルートを指定します。たとえば:
setContentServerConnection(appName, name, webContextRoot='/cs')
コマンドの構文と例は、『WebCenter WLSTコマンド・リファレンス』のsetContentServerConnectionに関する項を参照してください。
Webコンテキスト・ルートを設定することで、SSOがセットアップされていることをドキュメント・ライブラリのコードに伝えます。この設定は、SSOを完全にセットアップするまでは設定しないでください。
接続フィルタを使用したアクセスの制限
ユーザーが適切に認証されるように、Web層OHSポートを通してのみWebCenter Portalおよび関連するコンポーネントへのアクセスを許可するには、次のステップに従います。
OAMインストールのテスト
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ログイン・チャレンジを使用する必要があります。
SAMLベースのシングル・サインオンの構成
Security Assertion Markup Language (SAML)によって、WebLogic ServerドメインおよびWebブラウザまたは他のHTTPクライアントで実行されているWebベースのアプリケーションやWebサービス間でクロスプラットフォームの認証が可能になります。WebLogic ServerではWebCenter PortalのためのSAMLに基づくシングル・サインオン(SSO)がサポートされています。
シングル・サインオン構成に参加する1つのサイトでユーザーが認証されると、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ベースのシングル・サインオンおよびSAML 2.0ベースのシングル・サインオンをセットアップする方法を説明します。
Oracle WebCenter Portalでは、次のSAMLベースのシングル・サインオン構成をサポートします。
SAMLのコンポーネントとトポロジ
図26-4は、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アサーションの形式でセキュリティ情報をアサートする権限を持つエンティティ)です。
図26-3は、WebCenter PortalとSOAドメインの両方を含む、POSTが構成されたSAML SSO構成のコンポーネントとフローを示しています。このフローは、ディスカッションのようなシングル・サインオンに参加する他の宛先アプリケーションの場合と似ています。
図26-3 詳細なSAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)
![図26-3の説明が続きます 図26-3の説明が続きます](img/wcadm_sec_samlsso2.gif)
「図26-3 詳細なSAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)」の説明
図26-4は、WebCenter Portalとディスカッション・アプリケーションの間のSAML SSOフローを含む、POSTが構成されたSAML SSO構成の簡略化されたバージョンのコンポーネントとフローを示しています。
図26-4 SAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)
![図26-4の説明が続きます 図26-4の説明が続きます](img/wcadm_sec_samlsso.gif)
「図26-4 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ベースのシングル・サインオンの構成
この項では、一連の自動化されたスクリプトを使用して、SAML1.1ベースのシングル・サインオンに対応するようにWebCenter Portalおよび関連するサービスとコンポーネントを構成する方法について説明します。
この項には次のトピックが含まれます:
SAMLシングル・サインオンの前提条件
この項では、SAMLベースのシングル・サインオンを構成する前に実行する必要がある一連のステップを説明します。これらのステップでは、WebCenter Portalと関連付けられたコンポーネントがインストール済で、関連する接続が構成およびテスト済であることを前提としています。
SAMLベースのSSOの前提条件について、次のトピックで説明します。
SAML SSO用のWebCenter Content Serverの構成
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>
セクションにあることを確認します。
SAML SSO用のディスカッション・サーバーの構成
デフォルトでは、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形式でのみエクスポートする必要があることに注意してください。
SSLの設定
トランスポートレベルのセキュリティを提供するためにWebCenter PortalのインストールでSSLを必要とする場合は、「SSLの構成」で説明されているようにシングル・サインオンを構成する前にSSLを構成する必要があります。SSLのセットアップはSSOの有効化とは無関係であることに注意してください。
SAMLベースの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.p
y
)
configureForum.py
ディスカッションのアサーティングおよびリライイング・パーティを構成するための実行可能スクリプト(WCP_ORACLE_HOME
/webcenter/scripts/samlsso/configureForum.p
y
)
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構成を削除したら、スクリプトを再実行してください。
外部リーダーを使用したRSS用の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の場合は、プロファイル・ユーザー・インタフェースに移動し、ログインをチャレンジされずに、iFrame内に埋め込まれているContent Server画面が表示されることを確認します。すでにWebCenter Portalにログインしている際には、ログインをチャレンジされずにコンテンツ・プレゼンタ・テンプレートのSite Studioコンテンツにもアクセスできます。
http://host:port/rest/api/resourceIndex
にアクセスし、BASIC認証チャレンジが表示されることを確認します。同じSSOを使用する別の関連アプリケーションにすでにログインしている場合は、ログインへのチャレンジなしでコンテンツを表示できるはずです。- SOAをテストするには、ワークフロー・タスク・フローのリンクにアクセスして、ログインをチャレンジされないことを確認します。
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構成を一時的に無効にする方法を説明します。
SAML SSO構成を無効にするには:
-
WebCenter PortalドメインのWLS管理コンソールにログオンします。
-
セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択し、そこに示されたリライイング・パーティをすべて無効にします。
-
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて無効にします。
-
SOAやContent Serverなど、SAML SSOで構成されている他のWLSドメインがある場合は、それらのドメインからもSAML SSO構成を削除します。
-
WLSドメインのWLS管理コンソールにログインします。
-
セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて無効にします。
-
-
アプリケーションを開き、サインインを要求されないことをチェックして、SAML SSO構成が無効になっていることを確認します。
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を再構成できるようになります。
SAML 2.0ベースのシングル・サインオンの構成
SAML-2.0を使用してシングル・サインオンを構成すると、ユーザーは1つのアプリケーションに一度サインオンするだけで複数のアプリケーションにアクセスできるようになります。SAML-2.0を使用すると、WebLogic Serverドメイン上で動作しているアイデンティティ・プロバイダとサービス・プロバイダ間で認証情報を交換できます。アイデンティティ・プロバイダはソース・サイトとして機能し、認証の資格証明を提供します。サービス・プロバイダはアイデンティティ・プロバイダによって渡される認証情報を消費します。
WebLogic Serverは、SAMLアイデンティティ・プロバイダおよびサービス・プロバイダとして機能するように構成できます。アイデンティティ・プロバイダの場合は、アイデンティティ・プロバイダがアサーションを生成できるようにSAML資格証明マッピング・プロバイダを構成する必要があります。サービス・プロバイダの場合は、サービス・プロバイダがアサーションを消費できるようにSAMLアイデンティティ・アサーション・プロバイダを構成する必要があります。
このトピックで説明する構成では、WebCenter Portalをアイデンティティ・プロバイダとして、WebCenter Contentをサービス・プロバイダとして構成しています。WebLogic Server上で動作しているWebCenter Portalと別のWebLogic Server上で動作しているWebCenter Contentとの間でシングル・サインオンが確立されます。
SAML 2.0コンポーネント
-
アイデンティティ・プロバイダ(IdP)—アイデンティティ・プロバイダは、システムとやり取りしているユーザーに識別子を提供し、ユーザーが認証済で、関連する属性が付与されていることをアサートするシステム(管理ドメイン)です。IDプロバイダは、SAML認証局、アサーティング・パーティ、またはソース・サイトとも呼ばれ、しばしばIdPと略されます。
-
サービス・プロバイダ(SP)—アイデンティティ・プロバイダによって提供されたアサーションを信頼するかどうかを決定するシステム(管理ドメイン)です。SAMLには、提供されたアサーションをサービス・プロバイダが信頼できるようにするための複数のメカニズムが定義されています。サービス・プロバイダは、リライイング・パーティまたは宛先サイトとも呼ばれ、しばしばSPと略されます。
たとえば: WebCenter Portal資格証明を使用してWebCenter Contentにログインする場合、WebCenter Contentはサービス・プロバイダとして機能します。
-
資格証明マッピング・プロバイダ—SAML 2.0アサーションを生成します。このプロバイダは、IDプロバイダとして機能するWebLogic Serverインスタンスのために構成する必要があります。
-
アイデンティティ・アサーション・プロバイダ—SAML 2.0アサーションを消費します。このプロバイダは、サービス・プロバイダとして機能するWebLogic Serverインスタンスのために構成する必要があります。
-
SAML認証プロバイダ—SAML 2.0アイデンティティ・アサーション・プロバイダの「仮想ユーザー」機能を有効にします。
詳細は、『Oracle WebLogic Serverセキュリティの理解』のSAML (Security Assertion Markup Language)に関する項を参照してください。
前提条件
-
インストールした
webcenter.ear
では、Cookieパスが/webcenterで設定されています。WebLogic Server SAML 2.0の制限のために、Cookieパスを/で設定する必要があります。これが必要になるのは、WebLogic Service ProviderではSAML 2.0のCookieパスとして/のみがサポートされているためです。詳細は、SAML 2.0シングル・サインオン用のサービス・プロバイダ・サイトの構成に関する項を参照してください。 -
IdPとSPが同じマシン上にインストールされているか、同じドメインで動作している場合、先にIdPにログインしてからSPにログインしようとすると、IdPのログイン時に確立されたCookieパス/は、SPへのログイン試行時にSAML 2.0によってオーバーライドされます。これにより、IDPセッションがタイムアウトするので、IdPに再度ログインする必要があります。この問題を回避するには、SPとIdPの両方に仮想ホストを作成し、これらの仮想ホストをIdPとSPのWebLogic Server構成に登録します。このドキュメントでは、仮想ホストはOHSを使用して作成されます。詳細は、https://httpd.apache.org/docs/2.2/vhosts/examples.htmlを参照してください。
主なステップ
ここでは、SAML 2.0サービスを構成する主なステップを示します。
-
SAML 2.0アイデンティティ・プロバイダ・サイトを構成します。この構成では、WebCenter Portalをアイデンティティ・プロバイダ・サイトとして構成します。
-
SAML 2.0資格証明マッピング・プロバイダのインスタンスを作成して構成します。詳細は、「SAML 2.0資格証明マッピング・プロバイダの作成」を参照してください。
-
SAML 2.0アイデンティティ・プロバイダ・サービスを構成します。「SAML 2.0アイデンティティ・プロバイダ・サービスの構成」を参照してください。
-
SAML 2.0全般サービスを構成して、メタデータ・ファイルを公開します。詳細は、「アイデンティティ・プロバイダのSAML 2.0全般サービスの構成」を参照してください。
-
サービス・プロバイダ・パートナを作成して構成します。詳細は、「SAMLアイデンティティ・プロバイダのソース・サイトでのサービス・プロバイダ・パートナのメタデータの構成」を参照してください。
-
-
SAML 2.0サービス・プロバイダ・サイトを構成します。この構成では、WebCenter Contentをサービス・プロバイダ・サイトとして構成します。
-
SAML 2.0アイデンティティ・アサーション・プロバイダのインスタンスを作成して構成します。詳細は、「SAML 2.0アイデンティティ・アサーション・プロバイダの作成」を参照してください。
-
SAML 2.0サービス・プロバイダ・サービスを構成します。詳細は、「SAML 2.0サービス・プロバイダ・サービスの構成」を参照してください。
-
SAML 2.0全般サービスを構成して、メタデータ・ファイルを公開します。詳細は、「サービス・プロバイダのSAML 2.0全般サービスの構成」を参照してください。
-
IDプロバイダ・パートナを作成して構成します。詳細は、「SAMLサービス・プロバイダでのアイデンティティ・プロバイダのメタデータの構成」を参照してください。
-
詳細は、『Oracle WebLogic Serverセキュリティの管理』の「SAML 2.0サービスの構成」を参照してください。
SAML 2.0資格証明マッピング・プロバイダの作成
アイデンティティ・プロバイダとして機能するWebLogic Serverインスタンスに対して資格証明マッピング・プロバイダを構成する必要があります。資格証明マッピング・プロバイダを使用することで、WebLogic Serverはユーザーかわって認証済のリモート・システムにログインできるようになります。資格証明マッピング・プロバイダはソース・サイトで構成する必要があり、この例では、WebCenter Portal上で構成されます。
次に、「SAML 2.0アイデンティティ・プロバイダ・サービスの構成」の説明に従って、アイデンティティ・プロバイダを構成します。
SAML 2.0アイデンティティ・プロバイダ・サービスの構成
Weblogic Server上で動作しているWebCenter Portalをアイデンティティ・プロバイダ・サービスとして機能するように構成し、SAML 2.0を使用したシングル・サインオンを有効にできます。
アイデンティティ・プロバイダのSAML 2.0全般サービスの構成
SAML 2.0アイデンティティ・アサーション・プロバイダの作成
SAML 2.0アイデンティティ・アサーション・プロバイダはSAML 2.0セキュリティ・アサーションのコンシューマとして機能するように構成でき、これにより、WebLogic ServerをWebシングル・サインオンのサービス・プロバイダとして機能させることができます。アイデンティティ・アサーション・プロバイダは宛先サイトで構成する必要があり、この例ではWebCenter Content上で構成されます。
次に、「SAML 2.0サービス・プロバイダ・サービスの構成」の説明に従って、SAML 2.0サービス・プロバイダ・サービスを構成します。
SAML 2.0サービス・プロバイダ・サービスの構成
サービス・プロバイダのSAML 2.0全般サービスの構成
SAML 2.0に関する一般的な問題のトラブルシューティング
この項では、SAML 2.0ベースのシングル・サインオンの構成中に発生する可能性がある問題のトラブルシューティングに役立つ情報を提供します。
アイデンティティ・プロバイダとサービス・プロバイダ間で時刻に誤差があると、SSOは確立できません。
たとえば、サービス・プロバイダの時刻がアイデンティティ・プロバイダよりも1分遅れで設定された場合、サービス・プロバイダ・インスタンスにアクセスすると、次のエラーが表示されます。
<Sep 2, 2015 1:08:28 AM EDT> <Debug> <SecuritySAML2Service> <BEA-000000> <[Security:090377]Identity Assertion Failed, weblogic.security.spi.IdentityAssertionException: [Security:090377]Identity Assertion Failed, weblogic.security.spi.IdentityAssertionException: [Security:096537]Assertion is not yet valid (NotBefore condition).>
アイデンティティ・プロバイダとサービス・プロバイダは同期してください。「デフォルト存続時間」と「デフォルト存続時間のオフセット」のデフォルト値を調整し、アイデンティティ・プロバイダとサービス・プロバイダ間の時刻のオフセットを修正することをお薦めします。
図26-14 デフォルト時間の設定
![この画像は、デフォルト時間の設定ページを示しています。 この画像は、デフォルト時間の設定ページを示しています。](img/saml-2-0-offset.png)
Microsoftクライアント用の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トークンを解析する必要があります。
この項には次のサブセクションが含まれます:
MicrosoftクライアントSSOの概念
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クライアントの構成
MicrosoftクライアントでSSOを構成するには、図26-17に示されているMicrosoft Active Directory、MicrosoftクライアントおよびWebLogic Serverドメインを構成する必要があります。構成ステップとトラブルシューティングの詳細は、『Oracle WebLogic Serverセキュリティの管理』の「Microsoftのクライアントに対するシングル・サインオンの構成」を参照してください。
SSO用にMicrosoftクライアントを構成するには:
-
Kerberosを使用するようにネットワーク・ドメインを構成します。
-
WebLogic Server用にKerberos識別情報を作成します。
-
WebLogic Serverの動作するホスト用にActive Directoryのユーザー・アカウントを作成します。
-
作成したアカウント用にサービス・プリンシパル名を作成します。
-
このアカウントのユーザー・マッピングとキータブ・ファイルを作成します(『Oracle WebLogic Serverセキュリティの管理』の「Microsoftのクライアントに対するシングル・サインオンの構成」を参照)。
-
-
ブラウザ・クライアント(Internet ExplorerまたはMozilla Firefox)を選択し、Kerberosトークンを使用するようにそれを構成します(Oracle Argus Insightインストレーション・ガイドのKerberosトークンを返すためのブラウザの構成に関する項を参照)。
-
Kerberos認証を使用するようにWebLogic Serverドメイン(この場合は
wc_domain
)をセットアップします。-
MicrosoftドメインのActive Directoryサーバーとステップ2で作成したキータブ・ファイルをポイントするJAASログイン・ファイルを作成します(『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セキュリティ・コンテキストを受け付けます。
ネゴシエート・アイデンティティ・アサーション・プロバイダを構成するには:
Active Directory認証プロバイダの構成
次のステップに従って、WebLogic管理コンソールを使用してActive Directory認証プロバイダを構成します。
Active Directory認証プロバイダを構成するには:
-
WebLogic Server管理コンソールにログインします。
WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。
-
「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。
「セキュリティ・レルムのサマリー」ペインが表示されます。
-
セキュリティ・レルムをクリックします。
セキュリティ・レルムの「設定」ページが表示されます。
-
「プロバイダ」タブを開き、「認証」サブタブを選択します。
「認証設定」ペインが表示されます。
-
「新規」をクリックします。
「新しい認証プロバイダの作成」ペインが表示されます。
-
認証プロバイダの「名前」を入力し、「タイプ」として
ActiveDirectoryAuthenticator
を選択します。 -
「OK」をクリックします。
-
プロバイダのリストで、今作成した認証プロバイダをクリックします。
プロバイダの「設定」ページが表示されます。
-
「構成」タブを開き、「共通」サブタブを開きます。
-
「制御フラグ」を
SUFFICIENT
に設定して、「保存」をクリックします。ノート:
他のすべてのオーセンティケータの制御フラグの設定も、
SUFFICIENT
に変更する必要があります。制御フラグがREQUIRED
に設定された既存のデフォルト・オーセンティケータがある場合は、これをSUFFICIENT
に変更する必要があります。 -
「プロバイダ固有」サブタブを開きます。
プロバイダ固有の設定ペインが表示されます。
-
次の表に示されているように、各フィールドに値を入力します。これら以外のフィールドは、デフォルト値のままにします。
表26-4 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
) -
他のオーセンティケータ
-
WebCenter Portalの構成
ネゴシエート・アイデンティティ・アサーション・プロバイダとActive Directoryオーセンティケータの構成ステップを完了し、WebLogicドメインの全アプリケーションと必要なドメインのMicrosoftクライアントをシングル・サインオン用に構成したら、ユーザーがWebCenter Portalにアクセスしたときにシームレスなシングル・サインオン・エクスペリエンスを提供するための最終ステップを実行する必要があります。これは次の2通りの方法で実行できます。
-
管理者としてWebCenter Portalにログインし、
Public-User
ロールからView
アクセスを削除することで、パブリック・アクセスをオフにします。パブリック・アクセスをオフにすると、URLhttp://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用のディスカッション・サーバーの構成
この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。SSO用のディスカッション・サーバーを構成する前に、「外部LDAPを使用するためのディスカッション・サーバーの移行」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。
SSO用のディスカッション・サーバーを設定するには:
仮想ホストを使用したSSOの構成
この項では、コンテキスト・ルートとして/を使用するアプリケーションを含む環境に必要なOHS構成と、シングル・サインオンが呼び出される際にOHSで必要な追加構成について説明します。
この項には次のサブセクションが含まれます:
仮想ホストの必要性の理解
仮想ホストという用語は、1台のマシン上で複数のWebサイト(www.company1.com
とwww.company2.com
など)を実行することを示します。仮想ホストはIPベース(それぞれのWebホストごとに異なるIPアドレスを持つこと)にすることも、名前ベース(各IPアドレスに複数の名前を持つこと)にすることもできます。それらが同じ物理サーバー上で動作しているという事実は、エンド・ユーザーにはわかりません。仮想ホストの詳細は、Apacheのドキュメントを参照してください。
OAM 11gでの仮想ホストの構成
仮想ホスト用に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などの他のアプリケーションでは、シングル・サインオンが必要なため、この仮想ホストからそれらのアプリケーションへのアクセスは拒否されます。