27 シングル・サインオンの構成

WebCenter Portalで利用できるシングル・サインオン(SSO)ソリューションのいずれかを構成します。

注意:

12c (12.2.1.3.0)からは、Oracle WebCenter PortalでのJive機能(お知らせとディスカッション)のサポートは非推奨になりました。 以前のリリースからアップグレードする場合、これらの機能はアップグレード対象の既存のインストールで引き続き使用できます。

権限:

この章のタスクを実行するには、Oracle WebLogic Server管理コンソールでWebLogic ServerのAdminロールが付与されている必要があります。MonitorまたはOperatorロールを持つユーザーは、セキュリティ情報を表示できますが変更することはできません。

「管理操作、ロールおよびツールの理解」も参照してください。

トピック:

• シングル・サインオンの概要

• Oracle Access Managerの構成

• SAMLベースのシングル・サインオンの構成

• Microsoftクライアント用のSSOの構成

• 仮想ホストを使用したSSOの構成

シングル・サインオンの概要

シングル・サインオンでは、ユーザーがコンポーネントにアクセスするたびにログインする必要があるのではなく、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のコンポーネントとトポロジ

• OAM構成のロードマップ

• OAM 11gのインストールと構成

• OAM用のWebLogicドメインの構成

• 追加のシングル・サインオン構成

• OAMインストールのテスト

OAMのコンポーネントとトポロジ

図27-1は、WebCenter Portalアプリケーション用にOracle Access Managerを使用してシングル・サインオンをセットアップするために必要なコンポーネントとトポロジを示しています。

図27-1 OAMシングル・サインオンのコンポーネントとトポロジ

「図27-1 OAMシングル・サインオンのコンポーネントとトポロジ」の説明

OAMは次のコンポーネントから構成されます。

• アクセス・サーバー: アクセス・ゲートに対して認証、認可および監査サービスを提供するスタンドアロン・サーバー。OAMには1台のアクセス・サーバーがセットアップされます。これはOAMのインストール自体の一環として行われます。

• WebGate: Webリソース(HTTP)リクエストをインターセプトして認証と認可のためにアクセス・サーバーに転送する、すぐに利用可能なプラグイン。

• アイデンティティ・アサーション・プロバイダ(IAP): 境界認証によって設定されるヘッダー情報に基づいてユーザーのアイデンティティをアサートするセキュリティ・プロバイダの種類。OAMの統合により、OAM IAPとして構成できるOAM IDアサータが提供されます。OAM IDアサータは、認証またはアイデンティティ・アサーションに使用できます。OAM SSOの統合では、プロバイダの「共通」設定の「アクティブなタイプ」でobSSOCookieを選択して、アイデンティティ・アサーション・プロバイダ(IAP)としてOAM IDアサータを構成することが必要です。

OAMシングル・サインオン・プロセスのフロー

図27-2は、OAMのシングル・サインオン・プロセスのフローを示しています。

図27-2 OAMシングル・サインオン・プロセスのフロー

「図27-2 OAMシングル・サインオン・プロセスのフロー」の説明

OAMエージェントを使用したSSOログイン処理

1. ユーザーがリソースをリクエストします。

2. ポリシー評価のためにWebGateがOAMにリクエストを転送します。

3. OAM:

   • SSO Cookieの有無をチェックします。

   • ポリシーをチェックして、リソースが保護されているかどうか、保護されている場合はどのような方法で保護されているかを判断します。

4. OAMサーバーが判定をログして返します。

5. WebGateは、次のように応答します。

   • 無保護リソース: リソースはユーザーに提供されます。

   • 保護リソース:

     • リクエストは資格証明コレクタにリダイレクトされます。

     • 認証ポリシーに基づいてログイン・フォームが提供されます。

     • 認証処理が開始します

6. ユーザーが資格証明を送信します。

7. OAMが資格証明を検証します。

8. OAMがセッションを開始して、次のホストベースのCookieを作成します。

   • パートナ当たり1つ: 認証に成功した後でOAMサーバーから受信される認証トークンを使用して、11g WebGateがOAMAuthnCookieを設定します(10g WebGateの場合はObSSOCookie)。

     注意: セッションには有効なCookieが必要です。

   • OAMサーバーに1つ: OAM_ID

9. OAMが成功または失敗をログします。

10. OAM資格証明コレクタがWebGateにリダイレクトし、認可処理が開始します。

11. ポリシーをルックアップして、それらをユーザーのアイデンティティと比較し、ユーザーの認可レベルを判定するようにWebGateがOAMに指示します。

12. OAMがポリシーに関する判定をログして、セッションCookieをチェックします。

13. OAMサーバーが認可ポリシーを評価して、結果をキャッシュします。

14. OAMサーバーが判定をログして返します。

15. WebGateは、次のように応答します。

    • 認可ポリシーでアクセスが許可されている場合は、次に示すように、リクエストはmod_wlにリダイレクトされ、さらにWebCenter Portalアプリケーションを実行中のWLSサーバーにリダイレクトされて、そこから目的のコンテンツやアプリケーションがユーザーに提供されます。

      WebGate→mod_wl→WebCenter Portalアプリケーション(ディスカッションなど)→コンテンツが認証されたユーザーに提供されます

    • 認可ポリシーでアクセスが拒否されている場合は、管理者が決定した別のURLにユーザーはリダイレクトされます。

OAM構成のロードマップ

表27-1は、OAMを使用してWebCenter Portalのシングル・サインオンを構成するために必要な前提条件とタスクの概要を示しています。

表27-1 OAMを使用したWebCenter Portalのシングル・サインオンの構成

担当者	タスク
管理者	OAM 11gのインストールと構成 Oracle HTTP Serverのインストールと構成 Oracle HTTP Server WebGateの構成 WebGateエージェントの登録
管理者	OAM用のWebLogicドメインの構成 Oracle Internet Directoryオーセンティケータの構成 OAMアイデンティティ・アサータの構成 デフォルト・オーセンティケータとプロバイダの順序の構成 OAMシングル・サインオン・プロバイダの追加
管理者	追加のシングル・サインオン構成
管理者	OAMインストールのテスト

OAM 11gのインストールと構成

この項では、OAM 11gのインストールおよび構成方法について説明し、次の内容を含みます。

• OAM 11gのインストールと構成

• Oracle HTTP Serverのインストールと構成

• Oracle HTTP Server WebGateの構成

• WebGateエージェントの登録

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をインストールして構成するには:

1. Oracle HTTP Server 12cまたはOracle HTTP Server 11gをインストールします。

   Oracle HTTP Server 12cをインストールするには、『Oracle HTTP Serverのインストールと構成』の「Oracle HTTP Serverのインストールについて」を参照してください。

   Oracle HTTP Server 11gをインストールするには、 『Oracle Web Tierインストレーション・ガイド』の「インストールの概要」を参照してください。Oracle HTTP Serverは、Oracle Web Tierのコンポーネントです。

2. mod_wl_ohs.confを更新して、WebCenter Portal用のOracle WebLogic Serverにリクエストを転送するようにWeb層OHSを構成します。次に示したサンプル・エントリを参照してください。WebLogicポート番号が構成と一致するようにしてください。

   注意:

   この例では、WebCenter Portalが非クラスタベースのインストールであることを前提としています。クラスタ化環境の場合は、WebLogicHostとWebLogicPortを環境の必要に応じてWeblogicClusterに変更してください。

   # NOTE : This is a template to configure mod_weblogic. 
    
   LoadModule weblogic_module   "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"
    
   # This empty block is needed to save mod_wl related configuration from EM to this file when changes are made at the Base Virtual Host Level
   <IfModule weblogic_module>
   #      WebLogicHost <WEBLOGIC_HOST>
   #      WebLogicPort <WEBLOGIC_PORT>
   #      Debug ON
   #      WLLogFile /tmp/weblogic.log
   #      MatchExpression *.jsp
    
   <Location /webcenter>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8888
   </Location>
    
   <Location /webcenterhelp>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8888
   </Location>
    
   <Location /rss>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8888
   </Location>
    
   <Location /rest>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8888
   </Location>
    
   <Location /rsscrawl>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8888
   </Location>
   
   <Location /sesUserAuth>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8888
   </Location>
   
   <Location /owc_discussions>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8890
   </Location>
    
   <Location /wcps>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8891
   </Location>
    
   <Location /workflow>
         SetHandler weblogic-handler
         WebLogicHost soa.example.com
         WebLogicPort 8001
   </Location>
    

   <Location /integration/worklistapp>
         SetHandler weblogic-handler
         WebLogicHost soa.example.com
         WebLogicPort 8001
   </Location>
    
   <Location /integration/services>
         SetHandler weblogic-handler
         WebLogicHost soa.example.com
         WebLogicPort 8001
   </Location>
    
   <Location /soa-infra>
         SetHandler weblogic-handler
         WebLogicHost soa.example.com
         WebLogicPort 8001
   </Location>
    
   <Location /sdpmessaging/userprefs-ui>
         SetHandler weblogic-handler
         WebLogicHost soa.example.com
         WebLogicPort 8001
   </Location>
    
   <Location /DefaultToDoTaskFlow>
         SetHandler weblogic-handler
         WebLogicHost soa.example.com
         WebLogicPort 8001
   </Location>
    
   <Location /cs>
         SetHandler weblogic-handler
         WebLogicHost ucm.example.com
         WebLogicPort 16200
   </Location>
    
   <Location /adfAuthentication>
         SetHandler weblogic-handler
         WebLogicHost ucm.example.com
         WebLogicPort 16200
   </Location>
   
   <Location /pagelets>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8889
   </Location>
   
   <Location /services-producer>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8889
   </Location>
    
   <Location /wsrp-tools>
         SetHandler weblogic-handler
         WebLogicHost webcenter.example.com
         WebLogicPort 8889
   </Location>
    
   </IfModule>
    
   # <Location /weblogic>
   #      SetHandler weblogic-handler
   #      PathTrim /weblogic
   #      ErrorPage  http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
   #  </Location>
   

   注意:

   前述のLocationリストのエントリは、着信パスを、対応するアプリケーションが常駐する適切なWebLogic 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をインストールして構成します。

1. 『WebGate for Oracle Access Managerのインストール』の「Oracle HTTP Server 11g WebGate for OAMのインストールおよび構成」の説明に従って、WebGateをインストールします。Oracle HTTP Serverのインストール時に指定したものと同じミドルウェア・ホームを使用します。

   注意:

   OHS WebGateのインストール中は必ずOracle HTTP Serverを停止し、「WebGateエージェントの登録」の説明に従ってWebGateエージェントを登録した後でのみ再起動してください。

2. Oracle Access Manager用のOracle HTTP Server 11g WebGateをインストールしたら、WebGate用のOracleホームの下にある次のディレクトリに移動します。

   UNIXオペレーティング・システムの場合:

   <Webgate_Home>/webgate/ohs/tools/deployWebGate
   

   Windowsオペレーティング・システムの場合:

   <Webgate_Home>\webgate\ohs\tools\deployWebGate
   

3. コマンド行で次のコマンドを実行して、必要なエージェントの部分をWebgate_HomeディレクトリからWebGateインスタンスの場所にコピーします。

   UNIXオペレーティング・システムの場合:

   ./deployWebGateInstance.sh -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home>
   

   Windowsオペレーティング・システムの場合:

   deployWebGateInstance.bat -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home>
   

   <Webgate_Oracle_Home>には、次の例のように、Oracle HTTP Server WebGateがインストールされており、かつWebGateのOracleホームとして定義されているディレクトリを指定します。

   <MW_HOME>/Oracle_OAMWebGate1
   

   <Webgate_Instance_Directory>には、次の例のように、WebGateインスタンス・ホームの場所を指定します(これはOracle HTTP Serverのインスタンス・ホームと同じであることが必要です)。

   <MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1
   

   Oracle HTTP Serverのインスタンス・ホームは、Oracle HTTP Serverの構成後に作成されることに注意してください。この構成は、Oracle HTTP Serverのインストールまたはパッチ適用後に実行する必要があります。

4. 次のコマンドを実行し、LD_LIBRARY_PATH変数に<Oracle_Home_for_Oracle_HTTP_Server>/libが含まれるようにします。

   UNIXオペレーティング・システムの場合(シェルにより異なる):

   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<Oracle_Home_for_Oracle_HTTP_Server>/lib
   

   Windowsオペレーティング・システムの場合:

   <Webgate_Installation_Directory>\webgate\ohs\libおよび<Oracle_Home_for_Oracle_HTTP_Server>\binの場所をPATH環境変数に追加します。PATH環境変数のエントリの末尾に、セミコロン(;)に続けてこのパスを追加します。

5. 現在の作業ディレクトリから、1つ上のレベルに移動します。

   UNIXオペレーティング・システムの場合、次に移動します。

   <Webgate_Home>/webgate/ohs/tools/setup/InstallTools
   

   Windowsオペレーティング・システムの場合、次に移動します。

   <Webgate_Home>\webgate\ohs\tools\EditHttpConf
   

6. コマンド行で次のコマンドを実行して、apache_webgate.templateをWebgate_HomeディレクトリからWebGateインスタンスの場所にコピーします(webgate.confにその名前を変更します)。さらに、httpd.confファイルを更新し、1行を追加してwebgate.confファイルの名前を含めます。

   UNIXオペレーティング・システムの場合:

   ./EditHttpConf -w <Webgate_Instance_Directory> [-oh <Webgate_Oracle_Home>] [-o <output_file>]
   

   Windowsオペレーティング・システムの場合:

   EditHttpConf.exe -w <Webgate_Instance_Directory> [-oh <Webgate_Oracle_Home>] [-o <output_file>]

   注意:

   -oh <WebGate_Oracle_Home>および-o <output_file>パラメータはオプションです。

   <Webgate_Oracle_Home>には、次の例のように、Oracle HTTP Server WebGateがインストールされており、かつWebGateのOracleホームとして定義されているディレクトリを指定します。

   <MW_HOME>/Oracle_OAMWebGate1
   

   <Webgate_Instance_Directory>には、次の例のように、WebGateインスタンス・ホームの場所を指定します(これはOHSのインスタンス・ホームと同じであることが必要です)。

   <MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1

Webゲート・エージェントの登録

Web層にWebGateをインストールしたら、WebGateエージェントの登録も行う必要があります。次の手順では、OAMのインストールで構成されたデフォルト認証スキーム(通常はフォームベースの認証スキームLDAPScheme)を使用する保護されたポリシーを自動的に作成します。シングル・サインオンのログイン・ページをカスタマイズする場合、または他の認証スキームでリソースを保護する場合は、OAMコンソールを使用してそれを変更してください。

注意:

環境でWebCenter Portalとともに他のアプリケーションを使用しており、これらのアプリケーションにシングル・サインオンが必要な場合は、これらのアプリケーションで使用される認証スキームが同じであるか、少なくとも同じレベルで、同じアイデンティティ・ストアをポイントしていることが必要です。

次の手順に従って、インバンド・モードでoamregツールを使用して、OAMがインストールされているマシン上でWebGateエージェントを登録します。

1. ディレクトリを<RREG_Home>/inputに変更します(ここで<RREG_Home>はRREG.tar.gz/rregのコンテンツを抽出したディレクトリです)。

2. このOracle WebCenter Portalのインストールから$WEBCENTER_HOME/webcenter/scripts/webcenter.oam.confをコピーします。

   WEBCENTER_HOMEのデフォルトの場所は$ORACLE_HOME/Oracle_WC1です。

3. 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も有効になります。

4. 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>
   

5. ディレクトリを<RREG_Home>に変更します。

6. 次のコマンドを実行します。

   <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.
     

7. 生成されたファイルとアーティファクト(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
   

8. ディレクトリを<RREG_Home>/inputに変更します。

9. SOAまたはWebCenter Content Serverがインストールされている場合は、次の手順に従います。

   1. 次の例に示されているように、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>
      

   2. 次のコマンドを実行します。

      <RREG_Home>/bin/oamreg.sh policyUpdate input/WebCenterOAM11gPolicyUpdate.xml
      

      入力を要求されたら、OAMの資格証明を入力します。URIファイルをインポートするかどうか尋ねられたら、yesと入力して、<RREG_HOME>/input/soa.oam.confを指定します。

      ポリシーはSOAリソースを使用して更新されます。

   3. 再度policyUpdateコマンドを実行します。今回は<RREG_HOME>/input/oam.confを指定して、Content Serverのリソースを使用してポリシーを更新します。これでポリシーに、Oracle WebCenter Portal、SOAおよびContent Serverのアーティファクトが含まれます。

10. OAMコンソールから、次のアーティファクトを表示できるはずです。

    • $$webtierhost$$_webcenterという名前の11g WebGateエージェント

    • 同じ名前の11gホスト識別子

    • 認証ポリシーと認可ポリシー(保護されたポリシーとパブリック・ポリシーを含む)を含む同じ名前のアプリケーション・ドメイン

11. 「アプリケーション・ドメイン」→$$webtierhost$$_webcenter→「認証ポリシー」に移動します。次のポリシーを表示できるはずです。

    • 除外スキーム

    • 保護されたリソース・ポリシー

    • パブリック・リソース・ポリシー

    • WebCenter RESTポリシー

12. WebCenter RESTポリシーを開いて、認証スキームがBasicSessionlessSchemeまたはBasicSchemeに設定されていることを確認します。

13. 「リソース」タブを開いて、認証ポリシーがExclusion Schemeに設定されているリソースを検索します。次のリソースが表示されるはずです。

    • /rsscrawl*

    • /rsscrawl/.../*

    • /sesUserAuth*

    • /sesUserAuth/.../*

    • /services-producer/portlets*

    • /services-producer/portlets/.../*

    • /wsrp-tools/portlets

    • /wsrp-tools/portlets/.../*

14. 検索結果の/rsscrawl*リソースを選択して、「編集」をクリックします。

15. 保護レベルをProtectedからExcludedに変更して、「適用」をクリックします。リソースの認証ポリシーと認可ポリシーが削除されることに注意してください。

16. 「リソース」タブを閉じて、残りのExclusion Schemeリソースについてこの手順を繰り返します。

    この時点で認証ポリシーがExclusion Schemeに設定されているリソースを検索すると、結果はゼロになります。

17. OHSを再起動します。

18. Web層と関連するコンポーネントをインストールおよび構成したら、「OAM用のWebLogicドメインの構成」の説明に従ってポリシー・マネージャを構成し、「追加のシングル・サインオン構成」の説明に従って適用される追加のサービスとコンポーネントの構成を実行します。

OAM用のWebLogicドメインの構成

環境が複数のドメインにまたがっている場合(例: WebCenter Portalのドメイン、別個のSOAのドメインおよび別個のContent Serverのドメイン)、それぞれのドメインについてこの項の手順を繰り返してください。

この項では、次の内容について説明します。

• Oracle Internet Directoryオーセンティケータの構成

• OAMアイデンティティ・アサータの構成

• デフォルト・オーセンティケータとプロバイダの順序の構成

• OAMシングル・サインオン・プロバイダの追加

Oracle Internet Directoryオーセンティケータの構成

Oracle Internet DirectoryがOAMアイデンティティ・ストアをバッキングしている場合、Oracle Internet Directoryオーセンティケータ(OracleInternetDirectoryAuthenticator)はOAMのアイデンティティ・ストアとして使用されているLDAPサーバー用に構成し、プロバイダはSUFFICIENTに設定する必要があります。

Oracle Internet Directoryオーセンティケータを構成するには:

1. WebLogic Server管理コンソールにログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。

   「セキュリティ・レルムのサマリー」ペインが表示されます。

3. OIDオーセンティケータを構成するレルム・エントリをクリックします。

   レルムの「設定」ペインが表示されます。

4. 「プロバイダ」タブを開きます。

   「プロバイダ設定」が表示されます。

5. 「新規」をクリックして、プロバイダを作成します。

   「新しい認証プロバイダの作成」ペインが表示されます。

6. 新しいプロバイダの名前(例: OID Authenticator)を入力し、そのタイプとしてOracleInternetDirectoryAuthenticatorを選択して、「OK」をクリックします。
7. 「プロバイダ」タブで、新しく追加したプロバイダをクリックします。

   オーセンティケータの「共通設定」ペインが表示されます。

8. 制御フラグをSUFFICIENTに設定し、「保存」をクリックします。
9. 「プロバイダ固有」タブを開きます。

   オーセンティケータのプロバイダ固有の設定ペインが表示されます。

10. 次の表に示されているように、各フィールドに値を入力します。これら以外のフィールドは、デフォルト値のままにします。

    フィールド	値	コメント
    ホスト:		LDAPサーバーのホストID
    ポート:		LDAPサーバーのポート番号
    プリンシパル:		LDAP管理者プリンシパル(例: cn=orcladmin)
    資格証明:	<password>	管理者プリンシパルのパスワード
    資格証明の確認:	<password>
    ユーザー・ベースDN:		ユーザー検索ベース - この値はOAM Access Managerのセットアップの値と同じであることが必要
    すべてのユーザーのフィルタ:	"(&(uid=*)(objectclass=person))"	指定したユーザー名属性は、「すべてのユーザーのフィルタ」、「ユーザー名属性」および「名前指定によるユーザー・フィルタ」の3つのフィルタに一致する必要があります。
    ユーザー名属性:	"uid"
    名前指定によるユーザー・フィルタ:	"(&(uid=%u)(objectclass=person))"
    グループ・ベースDN:		グループ検索ベース - ユーザー・ベースDNと同じ
    取得したユーザー名をプリンシパルとして使用する	選択済	通常はユーザー・ログインIDでは大/小文字は区別されません。このフラグは、設定されたサブジェクトに、OIDに格納されたユーザー名が含まれるようにするために必要とされます。

    注意:

    「ユーザー名属性」、「すべてのユーザーのフィルタ」および「名前指定によるユーザー・フィルタ」のすべてのフィールドが、同じOID属性(この場合はuid)をポイントし、OAMのアイデンティティ・ストア構成に一致する必要があります。また、これらの3つのフィールドは、OAMおよびWebCenter Portalと同様にシングル・サインオンに参加するすべてのサービスでも一致する必要があります。

11. 「保存」をクリックします。

OAMアイデンティティ・アサータの構成

OAMアイデンティティ・アサータは、プロバイダの制御フラグをREQUIREDに設定して構成する必要があります。

OAMアイデンティティ・アサータを構成するには:

1. WebLogic Server管理コンソールにログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。

   「セキュリティ・レルムのサマリー」ペインが表示されます。

3. OAMアイデンティティ・アサータを構成するレルム・エントリをクリックします。

   レルムの「設定」ペインが表示されます。

4. 「プロバイダ」タブを開きます。

   「プロバイダ設定」が表示されます。

5. 「新規」をクリックして、プロバイダを作成します。

   「新しい認証プロバイダの作成」ペインが表示されます。

6. 新しいプロバイダの名前(例: OAM ID Asserter)を入力し、そのタイプとしてOAMIdentityAsserterを選択して、「OK」をクリックします。
7. 「プロバイダ」タブで、新しく追加したプロバイダをクリックします。

   オーセンティケータの「共通設定」ペインが表示されます。

8. 制御フラグをREQUIREDに設定し、OAM_REMOTE_USERとObSSOCookieが「アクティブなタイプ」に設定されていることをチェックします。
9. 「保存」をクリックして、設定を保存します。

デフォルト・オーセンティケータとプロバイダの順序の構成

OAMアイデンティティ・アサータを構成したら、デフォルト・オーセンティケータの制御フラグがSUFFICIENTに設定されていることを確認して、次のようにプロバイダを並べ替えます。

1. プロバイダの設定ペインに移動します。
2. デフォルト・オーセンティケータを開き、制御フラグがSUFFICIENTに設定されていることを確認します。
3. 先ほど作成した2つのプロバイダ以外の全プロバイダについて、同じことを行います。
4. 設定ペインで、プロバイダの順序を次のようにリセットします:

   • OAMIdentityAsserter (REQUIRED)

   • OracleInternetDirectoryAuthenticator (SUFFICIENT)

   • DefaultAuthenticator (SUFFICIENT)

   • DefaultIdentityAsserter

5. 引き続いて、「SSO用のWebCenter Portalの構成」の説明に従って、シングル・サインオン・モード用にWebCenter Portalを構成します。また、「追加のシングル・サインオン構成」の説明に従って、環境に適用する他のサービスおよびコンポーネントの構成を実行してください。

OAMシングル・サインオン・プロバイダの追加

デフォルト・オーセンティケータの制御フラグが適切に設定されていることとプロバイダの順序が正しいことをチェックしたら、次で説明されているように、OAM SSOプロバイダを追加して、すべてのサーバーを再起動します。

1. WLSTを使用してWebLogicドメインに接続し、次のコマンドを実行します。

   addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html")
   

2. すべてのサーバーを再起動します。

追加のシングル・サインオン構成

次の項で説明する構成は、サイトのセキュリティを強化するために必要であるか、または役に立ちます。これらの構成が完了したら、「OAMインストールのテスト」の説明に従ってOAMインストールのテストを行ってください。

• SSO用のWebCenter Portalの構成

• SSO用のディスカッション・サーバーの構成

• SSO用のSOAサーバー接続の構成

• 外部リーダーを使用したRSSフィード用のOAMの構成

• OAM 11g用のWebLogic Server管理コンソールとEnterprise Managerの構成

• SSO用のElasticsearchの構成 

• SSO用のSecure Enterprise Searchの構成

• SSO用のContent Serverの構成

• 接続フィルタを使用したアクセスの制限

• ポートレット・プロデューサと追加コンポーネントの構成

SSO用のWebCenter Portalの構成

WebCenter PortalアプリケーションをSSO用に構成するには、EXTRA_JAVA_PROPERTIESに設定を追加します。

アプリケーションがSSOモードに構成されており、特別な処理が必要であることをWebCenter PortalとADFに伝えるシステム・プロパティがあります。このモードでは、次のシステム・プロパティが必要とされます。

フィールド	値	コメント
oracle.webcenter.spaces.osso	true	このフラグは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用のディスカッション・サーバーを設定する手順は次のとおりです。

1. ディスカッション・サーバー管理コンソールにログインします。

   http://host:port/owc_discussions/admin
   

   hostおよびportは、WC_Collaboration管理対象サーバーのホストIDとポート番号です。

2. 「システム・プロパティ」ページを開き、owc_discussions.sso.modeプロパティを編集(存在している場合)または追加します(値をtrueに設定します)。
3. Web層のベースURLを示すようにjiveURLプロパティを編集または追加します。例:

   jiveURL = webtier.example.com:7777/owc_discussions
   

   jiveURLプロパティは、電子メールのフォーラムへのリンクを構築する際に使用されます。

   注意:

   WebCenter Portalでディスカッションおよびフォーラム用に登録したWebCenter接続は、OHS URLをポイントしている必要があります。

WebCenter Portal用のディスカッション・サーバー接続の作成

この項では、Web層のホストおよびポートの値を使用するようにWebCenter Portal用のディスカッション・サーバー接続を更新する方法を説明します。次の手順では、ディスカッション・コンポーネントがWebCenter Portalドメインにすでにインストールおよび構成されていることを前提としています。

1. Fusion Middleware ControlまたはWLSTを使用して、ディスカッション・サーバーのURLホストおよびポート設定をWC_Portal管理対象サーバーの設定からWeb層のホストおよびポート設定に変更します。これらの設定の変更方法の詳細は、「ディスカッション・サーバー接続の詳細の変更」を参照してください。
2. WC_Portal管理対象サーバーを再起動します。

   WebCenter Portalにログインすると、ディスカッション・サーバーにも自動的にサインオンします。

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フィードを非保護にする手順は次のとおりです。

1. OAM管理コンソールを開きます。
2. 「ポリシー構成」タブを開いて、「アプリケーション・ドメイン」→<該当するアプリケーション・ドメイン>を選択します。
3. 「リソース」タブを開いて、/rss*を検索します。

   結果の中に、次のような項目が表示されるはずです。

   /rss*

   /rss/.../*

   /rss/rssservlet*

   /rss/rssservlet/.../*

4. それぞれのリソースについて、そのリソースを選択して「編集」をクリックします。
5. 各リソースの保護レベルをProtectedからExcludedに変更して、「適用」をクリックします。

   リソースの認証ポリシーと認可ポリシーが削除されることに注意してください。

6. タブを閉じてOHSを再起動します。

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をセットアップする手順は次のとおりです。

1. ブラウザを使用して、OAMコンソールにログインします。

   http://host:port/oamconsole
   

2. 「ポリシー構成」→「アプリケーション・ドメイン」に移動します。

   「ポリシー・マネージャ」ペインが表示されます。

3. WebGateエージェントの登録時の名前を使用して、作成したアプリケーション・ドメインを見つけます。

4. 「リソース」ノードを展開して、「作成」をクリックします。

   リソース・ページが表示されます。

5. セキュリティ保護が必要なリソースを追加します。各リソースに対して、次の手順を実行します。

   1. 「リソース・タイプ」としてhttpを選択します。

   2. WebGateエージェントの登録時に作成したホスト識別子を選択します。

   3. 「リソースURL」に、WebLogic Server管理コンソールのリソースURL(/console)またはEnterprise ManagerのリソースURL(/em)を入力します。

   4. リソースの「説明」を入力し、「適用」をクリックします。

6. 「認証ポリシー」→保護されているリソース・ポリシーに移動し、新しく作成したリソースを追加します。

7. 「認可ポリシー」→保護されたリソース・ポリシーに移動して、新しく作成されたリソースを追加します。

8. 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>
   

9. 変更を有効にするために、Oracle HTTP Serverを再起動します。

   これで、次のリンクでWebLogic Server管理コンソールとEnterprise Managerにアクセスできるようになります。

   http://host:OHS port/console
   http://host:OHS port/em
   

   OAMのSSOログイン・フォームのプロンプトが表示されます。

SSO用のElasticsearchの構成 

WebCenter PortalとElasticsearchに定義された対応する認証エンド・ポイントが使用するWebCenter Portalデータとリポジトリをクロールするために定義されるクロール・ソースは、適切に認証されるようにWeb層OHSポートを通してルーティングする必要があります(認証方式は引き続きBASICになります)。

Elasticsearchを適切に機能させるには、Web層のOHSポートを介してルーティングされるWebCenter ContentのクロールURLがOAMポリシーで除外されていることを確認します。

WebCenter ContentのクロールURLを除外するには:

1. Oracle Access Managementコンソールにログインし、「アプリケーション・セキュリティ」をクリックします。

2. 「アプリケーション・セキュリティ」ページで、「Access Manager」セクションの「アプリケーション・ドメイン」リンクをクリックします。

3. 「アプリケーション・ドメイン」ページで、アプリケーション・ドメインの名前を入力し、「検索」をクリックします。

4. 検索結果から、アプリケーション・ドメインをクリックして開きます。

5. 「リソース」タブを開き、「作成」をクリックします。

6. 「リソースの作成」ページで、必要な詳細を入力します。

   • タイプ: リソース・タイプとしてHTTPを選択します。

   • 説明: リソースの説明を入力します。

   • ホスト識別子: WebGateエージェントの登録時に作成されたホスト識別子を選択します。

   • リソースURL: リソースURLを/cs/idcplgと入力します

   • 問合せ: 「名前と値のリスト」を選択し、「追加」アイコンをクリックして値を追加します。名前をIdcService、値をSES_CRAWLER_*と入力します。

   • 操作: すべての操作を選択します

   • 保護レベル: 「除外」を選択します

7. 「適用」をクリックします。

8. Oracle Access Managementの除外が適切に構成されているかどうかを確認するには:

   1. Oracle WebCenter Portalに管理者としてログインします。

   2. ドキュメント・クロール用のOracle HTTP Server URLを構成します。「ドキュメント・クロール・ソースの作成」を参照してください。

   3. 「テスト」をクリックして、ドキュメント・クロール・エンドポイントをテストします。

      OAMの除外が適切に構成されている場合、テストは成功です。

SSO用のSecure Enterprise Searchの構成

WebCenter PortalとSESに定義された対応する認証エンド・ポイントが使用するWebCenter Portalデータとリポジトリをクロールするために定義されるクロール・ソースは、適切に認証されるようにWeb層OHSポートを通してルーティングする必要があります(認証方式は引き続きBASICおよびレルムjazn.comになります)。SES接続の構成の詳細は、「Oracle SES接続の設定」を参照してください。

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および関連するコンポーネントへのアクセスを許可するには、次の手順に従います。

1. WebLogic Server管理コンソールにログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、構成するドメインを選択します(例: webcenter)。
3. 「セキュリティ」タブを開き、「フィルタ」サブタブを開きます。

   セキュリティ・フィルタの設定ペインが表示されます。

4. 「接続ロガーの有効化」を選択して、受け入れられたメッセージのログを有効にします。

   接続ロガーは、成功した接続と接続データをサーバーにログします。この情報を使用して、サーバー接続に関する問題をデバッグできます。

5. 「接続フィルタ」フィールドに、ドメインで使用する接続フィルタ・クラスを指定します。

   • デフォルトの接続フィルタを構成するには、weblogic.security.net.ConnectionFilterImplと指定します。

   • カスタム接続フィルタを構成するには、ネットワーク接続フィルタを実装するクラスを指定します。このクラスはWebLogic ServerのCLASSPATHにも指定されていることが必要です。

6. 「接続フィルタ・ルール」フィールドに、接続フィルタ・ルールの構文を入力します。

   例:

   <webtier IP>/0 * * allow
   0.0.0.0/0  *  *  deny
   

   これは、ローカル・ホストからの全トラフィックを許可し、他のIPアドレスからの全トラフィックを拒否するように指定しています。もちろん、環境に適切なネットワーク・フィルタを作成する必要があります。接続フィルタの作成の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のカスタム接続フィルタの開発に関する項を参照してください。

7. 「保存」をクリックして、変更をアクティブ化します。
8. すべての管理対象サーバーと管理サーバーを再起動します。
9. WebLogic Serverへのすべての直接トラフィックが、次へのナビゲートを試行することでブロックされることを検証します。

   http://host:WLS_port/webcenter
   

   これによって次のエラーが生成されます。

   「サーバーがこのリクエストを処理できません:[ソケット:000445]接続が拒否され、フィルタがソケットをブロックしました、weblogic.security.net.FilterException: [セキュリティ:090220]rule 3」

   ただし、OHSポートを通してWebCenter Portalにアクセスすることは今でも可能です。

   http://host:OHS_port/webcenter

ポートレット・プロデューサと追加コンポーネントの構成

OHSを通してルーティングされるようにポートレット・プロデューサ・アプリケーションをセットアップした場合は、登録用のプロデューサURLを指定する際に必ずOHSホストおよびポートを使用してください。これは、wsrp-toolsのようなデフォルトのプロデューサ、サービス・プロデューサ、ページレット・プロデューサおよび明示的に構成した他のプロデューサに適用されます。

OAMインストールのテスト

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 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のコンポーネントとトポロジ

• SAML1.1ベースのシングル・サインオンの構成

SAMLのコンポーネントとトポロジ

図27-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アサーションの形式でセキュリティ情報をアサートする権限を持つエンティティ)です。

図27-3は、WebCenter PortalとSOAドメインの両方を含む、POSTが構成されたSAML SSO構成のコンポーネントとフローを示しています。このフローは、ディスカッションのようなシングル・サインオンに参加する他の宛先アプリケーションの場合と似ています。

図27-3 詳細なSAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)

「図27-3 詳細なSAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)」の説明

図27-4は、WebCenter Portalとディスカッション・アプリケーションの間のSAML SSOフローを含む、POSTが構成されたSAML SSO構成の簡略化されたバージョンのコンポーネントとフローを示しています。

図27-4 SAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)

「図27-4 SAMLシングル・サインオンのコンポーネントとトポロジ(POSTプロファイルを構成)」の説明

フローの手順は次のとおりです。

1. ユーザーのブラウザが、ユーザーの資格証明を入力して、WebCenter Portalドメイン(wc_domain)のWebLogic管理対象サーバー(WC_Portal)上にホストされているWebCenter Portal (ソース・サイト)にアクセスします。

2. WebCenter Portalが、認証サービス・プロバイダにユーザーの資格証明を渡します。

3. 認証に成功すると、認証されたセッションが確立されて、WebCenter Portalのようこそページが表示されます。

4. ユーザーがようこそページで、同じドメインの異なるWebLogic Server (WC_Collaboration)上にホストされているディスカッション宛先サイトのセキュアなWebページにアクセスするためのリンクをクリックします。これによって、構成されているサイト間転送サービス(ITS)サーブレットへのコールがトリガーされます。この場合は、ITSサーブレットが、WebCenter Portalと同じJSESSIONID Cookieを共有するソース・サイト内(つまり、WC_Portal管理対象サーバー上のWebCenter Portalアプリケーション上)にホストされます。

5. ITSサーブレットは、WebCenter Portalドメイン(wc_domain)で構成されているSAML資格証明マッパーをコールして、コール元アサーションをリクエストします。SAML資格証明マッパーはアサーションを返します。また、宛先サイト・アプリケーションWebページ(ディスカッション用のセキュアなWebページ)のURLと適切なPOSTフォームのパス(ソース・サイトがPOSTプロファイルを使用するように構成されている場合)も返します。

6. SAML ITSサーブレットが、生成されたアサーションを含むSAMLレスポンスを生成し、それに署名して、BASE64にエンコードし、HTMLフォームに埋め込んで、そのフォームをユーザーのブラウザに返します。

7. ユーザーのブラウザがそのフォームを宛先サイトのアサーション・コンシューマ・サービス(ACS)にPOSTします。この場合は、ACSサーブレットが宛先サイト(ディスカッション)にホストされ、そのログインCookieを共有します。

8. アサーションが検証されます。

9. アサーションに成功すると、ユーザーがターゲット(ディスカッションのセキュアなWebページ)にリダイレクトされます。

10. ユーザーは再認証の必要なしで宛先サイト(ディスカッション)にログインします。

SAML1.1ベースのシングル・サインオンの構成

この項では、一連の自動化されたスクリプトを使用して、SAML1.1ベースのシングル・サインオンに対応するようにWebCenter Portalおよび関連するサービスとコンポーネントを構成する方法について説明します。

この項には次のトピックが含まれます:

• SAMLシングル・サインオンの前提条件

• SAMLベースのSSOの構成

• 外部リーダーを使用したRSS用のSAML SSOの構成

• 構成のチェック

• SAML SSO構成の無効化

• SAML SSO構成の削除

SAMLシングル・サインオンの前提条件

この項では、SAMLベースのシングル・サインオンを構成する前に実行する必要がある一連の手順を説明します。これらの手順では、WebCenter Portalと関連付けられたコンポーネントがインストール済で、関連する接続が構成およびテスト済であることを前提としています。

SAMLベースのSSOの前提条件について、次のトピックで説明します。

• SAML SSO用のWebCenter Content Serverの構成

• SAML SSO用のディスカッション・サーバーの構成

• 証明書の構成とエクスポート

• SSLのセットアップ

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のディスカッション・サーバーをデプロイおよび構成する手順は次のとおりです。

1. WebLogic Server管理コンソールに管理者としてログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、「デプロイメント」をクリックします。

   デプロイメントのサマリー・ペインが表示されます。

3. デプロイメントのサマリー・ページで、owc_discussions stop and deleteを選択して「インストール」をクリックします。
4. アプリケーション・インストール・アシスタントの「パス」フィールドを使用して、SSO対応のowc_discussions .EARファイル(owc_discussions_samlsso.ear、通常はWCP_ORACLE_HOME /discussionserverにあります)を見つけます。
5. owc_discussions_samlsso.earファイルを選択して「次」をクリックします。
6. 「Install this deployment as an application」を選択してから「Next」をクリックします。
7. 「名前」をowc_discussionsに設定します。
8. .EARファイルをデプロイします。
9. ディスカッション・サーバー管理コンソールに管理者としてログインします(ディスカッション・サーバー管理コンソールへのログインの詳細は、「SSO用のディスカッション・サーバーの構成」を参照してください)。
10. 「システム・プロパティ」ページを開き、owc_discussions.sso.modeプロパティを追加または編集(すでに存在している場合)して、その値をtrueに設定します。
11. (ディスカッション・サーバーがデプロイされた)WC_Collaboration管理対象サーバーを再起動します。

証明書の構成とエクスポート

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.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アーティファクトをクリーンアップする必要があります。

1. この構成で使用されるすべてのドメインの管理サーバーが稼働中であることを確認してください。

2. プロパティ・ファイルを適用するため、WCP_ORACLE_HOME/common/binからstoreUserConfig WLSTコマンドを使用して、様々なドメインの接続情報を含む構成およびキー・ファイルを生成します。使用方法と構文の詳細は、コマンド行のヘルプ(help('storeUserConfig'))を使用してください。

   1. WLSTを使用し、管理ユーザー名とパスワードを使用してWebCenter Portalドメインに接続し、次のコマンドを実行します。

      storeUserConfig('spacesconfig.secure', 'spaceskey.secure')

      これによってユーザー構成ファイルと関連するキー・ファイルが作成されます。ユーザー構成ファイルには、暗号化されたユーザー名とパスワードが含まれます。キー・ファイルには、ユーザー名とパスワードの暗号化と復号化に使用される秘密鍵が含まれます。前述のコマンドは、WLSTを呼び出したディレクトリに構成およびキー・ファイルを格納します。または、より安全なパスをオプションで指定できます。

   2. 管理ユーザー名とパスワードを使用してコラボレーション・ドメインに接続した後で、手順2aを繰り返します。ユーティリティ・サーバーがWebCenter Portalと同じドメイン(wc_domain)内にある場合でも、WebCenter Portalドメインに接続し、このコマンドを実行する必要があります。

      storeUserConfig('collabconfig.secure', 'collabkeykey.secure')

   3. 管理ユーザー名とパスワードを使用してユーティリティ・ドメインに接続した後で、手順2aを繰り返します。ユーティリティ・サーバーがWebCenter Portalと同じドメイン(wc_domain)内にある場合でも、WebCenter Portalドメインに接続し、このコマンドを実行する必要があります。

      storeUserConfig('utilitiesconfig.secure', 'utilitieskey.secure')

   4. 管理ユーザー名とパスワードを使用してSOAドメインに接続した後で、手順2aを繰り返します。WebCenter Portalと同じドメインにSOAがインストールされていても、WebCenter Portalドメインに接続してこのコマンドを実行する必要があります。

      storeUserConfig('soaconfig.secure', 'soakey.secure')

   5. 管理ユーザー名とパスワードを使用してContent Serverドメインに接続した後で、手順2aを繰り返します。

      storeUserConfig('ucmconfig.secure', 'ucmkey.secure')

3. 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ドメインから暗号化ユーティリティが実行されるようになります。

4. WCP_ORACLE_HOME/common/bin/wcsamlsso.propertiesを編集して、セットアップに適用されるセクションを指定します。プロパティ・ファイルのセクションの詳細な説明は、「シングル・サインオンのスクリプト」を参照してください。

5. WCP_ORACLE_HOME/common/binからWLSTを起動して、次に示された順番でスクリプトを実行します。

   注意:

   スクリプトには明示的な接続コマンドが含まれているので、スクリプトはWLSTオフライン・モードで実行してください。

   1. execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureSpaces.py')

      WebCenter Portalドメインの管理サーバーを含むすべてのサーバーを再起動します。

   2. ディスカッション・サーバーをセットアップしてある場合は、configureCollab.pyスクリプトを実行します。

      execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureCollab.py')

      ディスカッションがWebCenter Portalと同じドメインに属している場合は、WC_Collaboration管理対象サーバーのみを再起動します。そうでない場合は、コラボレーション・ドメインの管理サーバーを含むすべてのサーバーを再起動します。

   3. ユーティリティ・サーバーをセットアップしてある場合は、configureUtilities.pyスクリプトを実行します。

      execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureUtilities.py')

      ユーティリティ・サーバーがWebCenter Portalと同じドメインに属している場合は、WC_Utilitiesサーバーのみを再起動します。そうでない場合は、ユーティリティ・ドメインの管理サーバーを含むすべてのサーバーを再起動します。

   4. WebCenter PortalのSOAサーバー接続を構成してある場合は、configureSOA.pyスクリプトを実行します。

      execfile('<WCP_ORACLE_HOME>/webcenter/scripts/samlsso/configureSOA.py')

      SOAドメインの管理サーバーを含むすべてのサーバーを再起動します。

   5. WebCenter Portalにドキュメントを構成してある場合は、次のようにconfigureUCM.pyスクリプトを実行します。

      execfile('WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureUCM.py')
      

      Content Serverドメインの管理サーバーを含むすべてのサーバーを再起動します。

6. 環境の必要に応じて次の個々のコマンドを実行します。

   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ワークリストがインストールされている場合はこれを行ってください。再起動は不要です。

7. 「構成のチェック」の手順を使用して、インストールをチェックします。

   注意:

   プロパティ・ファイルには機密情報が含まれているので、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フィードを非保護にします。

1. WebCenter PortalドメインのWLS管理コンソールにログオンします。
2. セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択します。
3. RSSのリライイング・パーティを無効化または削除します。
4. セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択します。
5. RSSのアサーティング・パーティを無効化または削除します。

構成のチェック

次の手順に従って、シングル・サインオン構成が正しく動作することをチェックします。

シングル・サインオン構成をテストする手順は次のとおりです。

1. 新しいブラウザを使用して、WebCenter Portalにログインし、「ポータル設定」→「サービス」→「ディスカッション」の「フォーラム管理」をクリックしても、資格証明についてチャレンジされないことをチェックします(このサービスがポータル用にプロビジョニングされていると仮定します)。
2. ディスカッションまたはワークリスト・タスク・フローからRSSリンクにアクセスして、ログインのためにチャレンジされないことをチェックします。
3. Content Serverの場合は、プロファイル・ユーザー・インタフェースに移動し、ログインをチャレンジされずに、iFrame内に埋め込まれているContent Server画面が表示されることを確認します。すでにWebCenter Portalにログインしている際には、ログインをチャレンジされずにコンテンツ・プレゼンタ・テンプレートのSite Studioコンテンツにもアクセスできます。
4. http://host:port/rest/api/resourceIndexにアクセスし、BASIC認証チャレンジが表示されることを確認します。同じSSOを使用する別の関連アプリケーションにすでにログインしている場合は、ログインへのチャレンジなしでコンテンツを表示できるはずです。
5. 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構成を無効にする手順は次のとおりです。

1. WebCenter PortalドメインのWLS管理コンソールにログオンします。

2. セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択し、そこに示されたリライイング・パーティをすべて無効にします。

3. セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて無効にします。

4. SOAやContent Serverなど、SAML SSOで構成されている他のWLSドメインがある場合は、それらのドメインからもSAML SSO構成を削除します。

   1. WLSドメインのWLS管理コンソールにログインします。

   2. セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて無効にします。

5. アプリケーションを開き、サインインを要求されないことをチェックして、SAML SSO構成が無効になっていることを確認します。

SAML SSO構成の削除

SAML SSO構成スクリプトにはクリーンアップ機能は含まれていないので、wcsamlsso.propertiesファイルの更新中やスクリプトの実行中にミスをすると、構成は無効な状態になる可能性があります。この場合は、ここですべてのSAML SSO構成をクリーンアップして、もう一度やりなおすことをお薦めします。この項では、SAML SSO構成を削除する手順を説明します。

SAML SSOを完全にセットアップした場合(つまり、スクリプトが完全に実行された場合)は、次のすべての指示が有効になることに注意してください。ただし、スクリプトの実行中にエラーが発生すると、構成は不完全なものになる可能性があります。その場合は次のアーティファクトの一部のみが存在し、削除することが必要になります。

SAML SSO構成を削除するには:

1. WebCenter PortalドメインのWLS管理コンソールにログオンします。

2. セキュリティ・レルムを開き、「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」を選択し、そこに示されたリライイング・パーティをすべて削除します。

3. セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて削除します。

4. 「プロバイダ」→「認証」→「wcsamlia」→「管理」→「証明書」に移動し、そこで証明書をすべて削除します。

5. 「プロバイダ」→「資格証明マッピング」→「wcsamlcm」に移動して、SAML資格証明マッパーを削除します。

6. 「プロバイダ」→「認証」→「wcsamlia」に移動し、SAMLアイデンティティ・アサータを削除します。

7. WebCenter Portal WLSドメイン全体を再起動します。

8. SOAやContent Serverなど、SAML SSOで構成されている他のWLSドメインがある場合は、それらのドメインからもSAML SSO構成を削除します。

   1. WLSドメインのWLS管理コンソールにログインします。

   2. セキュリティ・レルムを開き、「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」を選択して、表示されたアサーティング・パーティをすべて削除します。

   3. 「プロバイダ」→「認証」→「wcsamlia」→「管理」→「証明書」に移動し、そこで証明書をすべて削除します。

   4. 「プロバイダ」→「認証」→「wcsamlia」に移動し、SAMLアイデンティティ・アサータを削除します。

   5. WLSドメイン全体を再起動します。

9. アプリケーションを開き、サインインを要求されないことをチェックして、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サービスを構成する主な手順を示します。

1. SAML 2.0アイデンティティ・プロバイダ・サイトを構成します。この構成では、WebCenter Portalをアイデンティティ・プロバイダ・サイトとして構成します。

   1. SAML 2.0資格証明マッピング・プロバイダのインスタンスを作成して構成します。詳細は、「SAML 2.0資格証明マッピング・プロバイダの作成」を参照してください。

   2. SAML 2.0アイデンティティ・プロバイダ・サービスを構成します。「SAML 2.0アイデンティティ・プロバイダ・サービスの構成」を参照してください。

   3. SAML 2.0全般サービスを構成して、メタデータ・ファイルを公開します。詳細は、「アイデンティティ・プロバイダのSAML 2.0全般サービスの構成」を参照してください。

   4. サービス・プロバイダ・パートナを作成して構成します。詳細は、「SAMLアイデンティティ・プロバイダのソース・サイトでのサービス・プロバイダ・パートナのメタデータの構成」を参照してください。

2. SAML 2.0サービス・プロバイダ・サイトを構成します。この構成では、WebCenter Contentをサービス・プロバイダ・サイトとして構成します。

   1. SAML 2.0アイデンティティ・アサーション・プロバイダのインスタンスを作成して構成します。詳細は、「SAML 2.0アイデンティティ・アサーション・プロバイダの作成」を参照してください。

   2. SAML 2.0サービス・プロバイダ・サービスを構成します。詳細は、「SAML 2.0サービス・プロバイダ・サービスの構成」を参照してください。

   3. SAML 2.0全般サービスを構成して、メタデータ・ファイルを公開します。詳細は、「サービス・プロバイダのSAML 2.0全般サービスの構成」を参照してください。

   4. IDプロバイダ・パートナを作成して構成します。詳細は、「SAMLサービス・プロバイダでのアイデンティティ・プロバイダのメタデータの構成」を参照してください。

詳細は、『Oracle WebLogic Serverセキュリティの管理』の「SAML 2.0サービスの構成」を参照してください。

この項には次のトピックが含まれます:

• SAML 2.0資格証明マッピング・プロバイダの作成

• SAML 2.0アイデンティティ・プロバイダ・サービスの構成

• アイデンティティ・プロバイダのSAML 2.0全般サービスの構成

• SAMLアイデンティティ・プロバイダのソース・サイトでのサービス・プロバイダ・パートナのメタデータの構成

• SAML 2.0アイデンティティ・アサーション・プロバイダの作成

• SAML 2.0サービス・プロバイダ・サービスの構成

• サービス・プロバイダのSAML 2.0全般サービスの構成

• SAMLサービス・プロバイダでのアイデンティティ・プロバイダのメタデータの構成

SAML 2.0資格証明マッピング・プロバイダの作成

アイデンティティ・プロバイダとして機能するWebLogic Serverインスタンスに対して資格証明マッピング・プロバイダを構成する必要があります。資格証明マッピング・プロバイダを使用することで、WebLogic Serverはユーザーかわって認証済のリモート・システムにログインできるようになります。資格証明マッピング・プロバイダはソース・サイトで構成する必要があり、この例では、WebCenter Portal上で構成されます。

SAML 2.0資格証明マッピング・プロバイダを作成するには:

1. ソース・ドメインのWebLogic Server管理コンソールに管理者としてログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで「セキュリティ・レルム」をクリックし、「myrealm」を選択します。
3. 「myrealmの設定」ページで、「プロバイダ」タブ→「資格証明マッピング」タブをクリックします。
   「資格証明マッピング・プロバイダ」表には、このセキュリティ・レルムで構成されている資格証明マッピング・プロバイダが表示されます。
4. 「新規」をクリックします。

   「新しい資格証明マッピング・プロバイダの作成」ページが表示されます。

   図27-5 資格証明マッピング・プロバイダの作成

   
5. 「名前」フィールドに、資格証明マッピング・プロバイダの名前を入力します。

   たとえば、SAML2CredentialMapperです。

6. 「タイプ」ドロップダウン・リストから、「SAML2CredentialMapper」を選択し、「OK」をクリックします。
7. 「myrealmの設定」ページで、「プロバイダ」タブ→「資格証明マッピング」タブを選択します。
8. 構成対象の新しい資格証明マッピング・プロバイダの名前をクリックします。たとえば、SAML2CredentialMapperです。
9. 「プロバイダ固有」タブをクリックします。
   新しく追加された資格証明マッピング・プロバイダの「プロバイダ固有」設定ペインが表示されます。

   図27-6 SAML 2.0資格証明マッピング・プロバイダの構成設定

   
10. 新しく追加されたSAML 2.0資格証明マッピング・プロバイダのプロバイダ固有の情報を構成します。これら以外のフィールドは、デフォルト値のままにします。

    • 発行者URI: IDP URL (http://host:port/saml)を入力します。

    • 名前修飾子: 「webcenter.com」と入力します

11. 「保存」をクリックして変更を保存します。
12. すべてのサーバーを停止して再起動します。

次に、「SAML 2.0アイデンティティ・プロバイダ・サービスの構成」の説明に従って、アイデンティティ・プロバイダを構成します。

SAML 2.0アイデンティティ・プロバイダ・サービスの構成

Weblogic Server上で動作しているWebCenter Portalをアイデンティティ・プロバイダ・サービスとして機能するように構成し、SAML 2.0を使用したシングル・サインオンを有効にできます。

SAML 2.0アイデンティティ・プロバイダ・サービスを構成するには:

1. ソース・サイトのWebLogic Server管理コンソールに管理者としてログインします。
2. ホーム・ページの「環境」で、「サーバー」を選択します。
3. 「サーバー」表からWebCenter Portalサーバー(WC_Portal)を選択します。
4. 「フェデレーション・サービス」タブ→「SAML 2.0アイデンティティ・プロバイダ」タブをクリックします。
   「SAML 2.0アイデンティティ・プロバイダ」ページが表示されます。
5. 「SAML 2.0アイデンティティ・プロバイダ」ページで、必要に応じて、SAML 2.0サービス・プロバイダ・サービスの構成オプションを設定します。
   1. 「有効」を選択し、WebCenter PortalサーバーでSAML 2.0サービスをアクティブ化します。
   2. 「優先バインド」リストから、「POST」を選択します。

   図27-7 SAML 2.0アイデンティティ・プロバイダの構成設定

   
6. 「保存」をクリックします。

次に、「アイデンティティ・プロバイダのSAML 2.0全般サービスの構成」の説明に従って、アイデンティティ・プロバイダのSAML 2.0全般サービスを構成します。

アイデンティティ・プロバイダのSAML 2.0全般サービスの構成

アイデンティティ・プロバイダの全般サービスを構成するには:

1. 「WebLogic Server管理コンソール・ホーム」ページの「環境」で、「サーバー」選択します。
2. 「サーバー」表からWebCenter Portalサーバー(WC_Portal)を選択します。
3. 「フェデレーション・サービス」タブ→「SAML 2.0全般」タブをクリックします。
4. 表に示したように、アイデンティティ・プロバイダの全般設定を構成します。これら以外のフィールドは、デフォルト値のままにします。

   表27-2 全般設定のパラメータ

   パラメータ	説明
   レプリケートされたキャッシュの有効化	「レプリケーションされたキャッシュの有効化」を選択して、SAML 2.0アーティファクトを格納するために永続キャッシュを使用します。このオプションは、ドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを構成する場合に必要となります。 たとえば、クラスタでSAML 2.0サービスを構成する場合は、個々の管理対象サーバー・インスタンスでこのオプションを有効化する必要があります。 レプリケーションされたキャッシュを使用すると、SAML 2.0セキュリティ・プロバイダ(SAML 2.0 IDアサーション・プロバイダとSAML 2.0資格証明マッピング・プロバイダのどちらか、または両方)で管理しているデータを、サーバー・インスタンス間で共有して同期させることができます。
   サイト情報	サイト情報は、SAMLフェデレーション内のビジネス・パートナに提供して共有するためのものです。サイト情報には、ローカル・サイトの担当者の連絡先、組織名、組織のURLなどが含まれます。 次のサイト情報を入力します。 連絡先(名) 連絡先(姓) 連絡先のタイプ 連絡先の勤務先 連絡先の電話番号 連絡先の電子メール・アドレス 組織名 組織URL
   公開サイトのURL	「公開サイトのURL」には、SAML 2.0サービスのエンドポイントURLを構築するために使用するベースURLを指定します。 このURLにはサーバーを外部から認識できるホスト名とポートを指定する必要がありますが、これらはローカルでサーバーにアクセスする場合に使用するホスト名やポートとは異なる可能性があります。たとえば、SAML 2.0サービスをクラスタ内で構成する場合のホスト名とポートは、クラスタ内の管理対象サーバーにクライアント・リクエストを配信するロード・バランサまたはプロキシ・サーバーに相当します。 公開サイトのURLには、/saml2を付加する必要があります。例: host:port/saml2
   エンティティID	エンティティIDは人間が読取れる形式の文字列で、サイトをフェデレーション内の他のパートナ・サイトと区別するために使用します。SAML 2.0サービスでは、パートナがアサーションを生成または消費する必要がある場合に、そのアサーションに対応するパートナを特定するプロセスにおいてこのエンティティIDを使用します。 アイデンティティ・プロバイダのエンティティID (webcenter_IDP)を入力します。
   受信者チェックの有効化	「受信者チェックの有効化」を有効にします。認証のリクエストやレスポンスの受信者は、HTTPリクエスト内のURLと一致している必要があります。
   シングル・サインオン	フェデレーション・パートナに送信するドキュメント(認証のリクエストやレスポンス)に署名する際、鍵のキーストアの別名とパスフレーズが使用されます。 次の情報を入力します。 シングル・サインオン署名鍵別名 シングル・サインオン署名鍵のパスフレーズ: 注意: この例では、OOTB WebLogic Server提供のDemoIdentityキーストアが使用され、パスワードはDemoIdentityPassPhraseです。

5. 「保存」をクリックします。
6. 「メタ・データの公開」をクリックし、パートナ・メタデータ・ファイルを作成または更新します。このファイルには、SAML 2.0 Webシングル・サインオンに使用される、フェデレーション・パートナと共有するこのサイトのSAML 2.0サービスに関する情報が格納されます。
   「SAML 2.0メタ・データの公開」ページが開きます。
7. 「SAML 2.0メタ・データの公開」ページで、XMLメタデータ・ファイルのフル・パスを入力します。

   たとえば、/mydomain/myserver/idp_metadata.xmlです

   注意:

   アイデンティティ・プロバイダのメタデータ・ファイルを公開する際には、ファイル名にidp_metadata.xm1を指定します

8. 「OK」をクリックして、メタデータ・ファイルを公開します。

   メタデータ・ファイルが公開され、指定のパスにコピーされます。

次に、「SAMLアイデンティティ・プロバイダのソース・サイトでのサービス・プロバイダ・パートナのメタデータの構成」の説明に従って、SAMLアイデンティティ・プロバイダのソース・サイトでサービス・プロバイダのメタデータを構成します

SAMLアイデンティティ・プロバイダのソース・サイトでのサービス・プロバイダ・パートナのメタデータの構成

ソース・サーバーでSAML 2.0サービス・プロバイダ・パートナのメタデータを構成するには:

1. WebLogic Server管理コンソールで、「セキュリティ・レルム」をクリックして「myrealm」を選択します。
2. 「プロバイダ」タブ→資格証明マッパータブをクリックします
3. SAML 2.0資格証明マッピング・プロバイダを選択します(SAML2CredentialMapperなど)。
4. 「SAML 2.0資格証明マッピング・プロバイダの設定」ページで、「管理」タブをクリックします。
5. 「サービス・プロバイダ・パートナ」で「新規」をクリックし、「新しいWebシングル・サインオンのサービス・プロバイダ・パートナ」を選択します。
6. 「SAML 2.0 Webシングル・サインオン・サービス・プロバイダ・パートナの作成」ページで、次のタスクを実行します。

   図27-8 新しいWebシングル・サインオンのサービス・プロバイダ・パートナ

   
   1. サービス・プロバイダ・パートナの名前を入力します。
      たとえば、SAML_SSO_SP01です
   2. 「パス」の横にあるフィールドで、メタデータ・パートナ・ファイルのフル・パスを指定するか、参照して指定します。

      たとえば、sp_metadata.xmlファイルです。

7. 「OK」をクリックします。
8. 「SAML 2.0資格証明マッパーの設定」ページの「サービス・プロバイダ・パートナ」表で、新しく作成したサービス・プロバイダ・パートナの名前を選択します。
   たとえば、SAML_SSO_SP01です。
9. 「全般」ページで、必要に応じて次の設定を構成します。

   図27-9 SAML 2.0 Webシングル・サインオンのサービス・プロバイダ・パートナの「全般」設定

   

   1. 「有効」を選択し、このサーバーとサービス・プロバイダ・パートナ間の相互作用を有効にします。

   2. 「説明」フィールドにサービス・プロバイダ・パートナの説明を入力します。たとえば、SAML_SSO_SP01です。

   3. 「キー情報を含む」を選択します

10. 「保存」をクリックします。
    サービス・プロバイダ・パートナがローカル・サーバー・インスタンスに作成されます。

SAML 2.0アイデンティティ・アサーション・プロバイダの作成

SAML 2.0アイデンティティ・アサーション・プロバイダはSAML 2.0セキュリティ・アサーションのコンシューマとして機能するように構成でき、これにより、WebLogic ServerをWebシングル・サインオンのサービス・プロバイダとして機能させることができます。アイデンティティ・アサーション・プロバイダは宛先サイトで構成する必要があり、この例ではWebCenter Content上で構成されます。

宛先ドメインでSAML 2.0アイデンティティ・アサーション・プロバイダを作成するには

1. 宛先サイトのWebLogic Server管理コンソールに管理者としてログインします。
2. 「ドメイン構造」ペインで「セキュリティ・レルム」をクリックし、「myrealm」を選択します。
3. 「myrealmの設定」ページで、「プロバイダ」タブ→「認証」タブをクリックします。
4. 「新規」をクリックします。
   「新しい認証プロバイダの作成」ページが表示されます。

   図27-10 認証プロバイダの作成

   
5. 「名前」フィールドに、認証プロバイダの名前を入力します。たとえば、SAML2_IdentityAsserterです
6. 「タイプ」ドロップダウン・リストから「SAML2_IdentityAsserter」を選択します
7. 「OK」をクリックします
8. すべてのサーバーを停止して再起動します。

次に、「SAML 2.0サービス・プロバイダ・サービスの構成」の説明に従って、SAML 2.0サービス・プロバイダ・サービスを構成します。

SAML 2.0サービス・プロバイダ・サービスの構成

サーバーをSAML 2.0サービス・プロバイダとして構成するには、次の手順を実行します。

1. 宛先サイトのWebLogic Server管理コンソールに管理者としてログインします。
2. ホーム・ページの「環境」で、「サーバー」を選択します。
3. 「サーバー」表からWebCenter Contentサーバー(UCM_server1)を選択します。
4. 「フェデレーション・サービス」タブ→「SAML 2.0サービス・プロバイダ」タブをクリックします。
   「SAML 2.0サービス・プロバイダ」ページが開きます。
5. SAML 2.0アイデンティティ・サービスページで、必要に応じて、SAML 2.0サービス・プロバイダ・サービスの構成オプションを設定します。
   1. 「有効」を選択し、WebLogic ServerのSAML 2.0サービスがサービス・プロバイダとして機能するようにアクティブ化します。
   2. 「優先バインド」リストから、「POST」を選択します。
   3. 「デフォルトURL」フィールドに宛先URL (http://host:port/cs/idcplg?IdcService=GET_DOC_PAGE&Action=GetTemplatePage&Page=HOME_PAGE&Auth=Internet)を入力します。

   図27-11 SAML 2.0サービス・プロバイダの構成設定

   
6. 「保存」をクリックします。

次に、「サービス・プロバイダのSAML 2.0全般サービスの構成」の説明に従って、サービス・プロバイダのSAML 2.0全般サービスを構成します。

サービス・プロバイダのSAML 2.0全般サービスの構成

SAML 2.0の全般サービスを構成するには:

1. 「WebLogic Server管理コンソール・ホーム」ページの「環境」で、「サーバー」選択します。
2. 「サーバー」表からWebCenter Contentサーバー(UCM_server1)を選択します。
3. 「フェデレーション・サービス」タブ→「SAML 2.0全般」タブをクリックします。
4. 表に示したように、サービス・プロバイダ・サイトの「全般」設定を構成します。これら以外のフィールドは、デフォルト値のままにします。

   表27-3 「全般」設定のパラメータ

   パラメータ	説明
   レプリケートされたキャッシュの有効化	「レプリケーションされたキャッシュの有効化」を選択して、SAML 2.0アーティファクトを格納するために永続キャッシュを使用します。このオプションは、ドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを構成する場合に必要となります。 たとえば、クラスタでSAML 2.0サービスを構成する場合は、個々の管理対象サーバー・インスタンスでこのオプションを有効化する必要があります。 レプリケーションされたキャッシュを使用すると、SAML 2.0セキュリティ・プロバイダ(SAML 2.0 IDアサーション・プロバイダとSAML 2.0資格証明マッピング・プロバイダのどちらか、または両方)で管理しているデータを、サーバー・インスタンス間で共有して同期させることができます。
   サイト情報	サイト情報は、SAMLフェデレーション内のビジネス・パートナに提供して共有するためのものです。サイト情報には、ローカル・サイトの担当者の連絡先、組織名、組織のURLなどが含まれます。 次のサイト情報を入力します。 連絡先(名) 連絡先(姓) 連絡先のタイプ 連絡先の勤務先 連絡先の電話番号 連絡先の電子メール・アドレス 組織名 組織URL
   公開サイトのURL	「公開サイトのURL」には、SAML 2.0サービスのエンドポイントURLを構築するために使用するベースURLを指定します。 このURLにはサーバーを外部から認識できるホスト名とポートを指定する必要がありますが、これらはローカルでサーバーにアクセスする場合に使用するホスト名やポートとは異なる可能性があります。たとえば、SAML 2.0サービスをクラスタ内で構成する場合のホスト名とポートは、クラスタ内の管理対象サーバーにクライアント・リクエストを配信するロード・バランサまたはプロキシ・サーバーに相当します。 公開サイトのURLには、/saml2を付加する必要があります。例: host:port/saml2
   エンティティID	エンティティIDは人間が読取れる形式の文字列で、サイトをフェデレーション内の他のパートナ・サイトと区別するために使用します。SAML 2.0サービスでは、パートナがアサーションを生成または消費する必要がある場合に、そのアサーションに対応するパートナを特定するプロセスにおいてこのエンティティIDを使用します。 サービス・プロバイダのエンティティID (webcenter_SP)を入力します
   受信者チェックの有効化	「受信者チェックの有効化」を有効にします。認証のリクエストやレスポンスの受信者は、HTTPリクエスト内のURLと一致している必要があります。
   シングル・サインオン	フェデレーション・パートナに送信するドキュメント(認証のリクエストやレスポンス)に署名する際、鍵のキーストアの別名とパスフレーズが使用されます。 次の情報を入力します。 シングル・サインオン署名鍵別名 シングル・サインオン署名鍵のパスフレーズ: 注意: この例では、OOTB WebLogic Server提供のDemoIdentityキーストアが使用され、パスワードはDemoIdentityPassPhraseです。

5. 「保存」をクリックします。
6. 「メタ・データの公開」をクリックし、パートナ・メタデータ・ファイルを作成または更新します。このファイルには、SAML 2.0 Webシングル・サインオンに使用される、フェデレーション・パートナと共有するこのサイトのSAML 2.0サービスに関する情報が格納されます。
   「SAML 2.0メタ・データの公開」ページが開きます。
7. 「SAML 2.0メタ・データの公開」ページで、XMLメタデータ・ファイルのフル・パスを入力します。

   たとえば、/mydomain/myserver/sp_metadata.xmlです

   注意:

   サービス・プロバイダのメタデータ・ファイルを公開する際には、ファイル名にsp_metadata.xm1を指定します
8. 「OK」をクリックして、メタデータ・ファイルを公開します。

   メタデータ・ファイルが公開され、指定のパスにコピーされます。

次に、「SAMLサービス・プロバイダでのアイデンティティ・プロバイダのメタデータの構成」の説明に従って、宛先サーバーでアイデンティティ・プロバイダ・パートナを作成して構成します

SAMLサービス・プロバイダでのアイデンティティ・プロバイダのメタデータの構成

宛先サーバーでSAML 2.0アイデンティティ・プロバイダ・パートナを作成するには:

1. 宛先サイトのWebLogic Server管理コンソールで、「セキュリティ・レルム」→「myrealm」をクリックします。
2. 「myrealmの設定」ページで、「プロバイダ」タブ→「認証」タブをクリックします。
3. 「認証プロバイダ」表で、SAML 2.0アイデンティティ・アサーション・プロバイダ(SAML2_IdentityAsserterなど)を選択します。
4. 「SAML 2.0 IDアサーション・プロバイダの設定」ページで、「管理」タブをクリックします。
5. 「アイデンティティ・プロバイダ・パートナ」の下で、「新規」をクリックして「新しいWebシングル・サインオンのアイデンティティ・プロバイダ・パートナ」を選択します。

   図27-12 「新しいWebシングル・サインオンのアイデンティティ・プロバイダ・パートナ」

   
6. 「SAML 2.0 Webシングル・サインオンIDプロバイダ・パートナの作成」ページで、次のタスクを実行します。

   1. 新しいWebシングル・サインオンのアイデンティティ・プロバイダ・パートナの名前を指定します。たとえば、WebSSO-IdP-Partner-0です

   2. 「パス」の横にあるフィールドで、アイデンティティ・プロバイダ・パートナから受信したSAML 2.0メタデータ・ファイルの名前と場所を指定するか、参照して指定します。たとえば、idp_metadata.xmlファイルです。

7. 「OK」をクリックします。
8. 「SAML 2.0 IDアサーション・プロバイダの設定」ページの「アイデンティティ・プロバイダ・パートナ」表で、新しく作成したWebシングル・サインオン・アイデンティティ・プロバイダ・パートナの名前を選択します。

   たとえば、WebSSO-IdP-Partner-0です

9. 「全般」ページで、必要に応じて次の設定を構成します。

   図27-13 SAML 2.0 Webシングル・サインオン・アイデンティティ・プロバイダ・パートナの「全般」設定

   

   1. 「有効」を選択し、このサーバーとアイデンティティ・プロバイダ・パートナ間の相互作用を有効にします。

   2. このアイデンティティ・プロバイダ・パートナの簡単な説明を入力します。

   3. 「仮想ユーザー」を選択し、このアイデンティティ・プロバイダ・パートナから受信するアサーションに含まれるユーザー情報が、このセキュリティ・レルム内の仮想ユーザーにマップされるように指定します。

   4. 「リダイレクトURI」フィールドに、認可されていないユーザーが呼び出した場合に認証リクエストを生成し、その認証リクエストをアイデンティティ・プロバイダ・パートナに送信する、ローカル・サイトでホストされているリソースのURIを指定します。たとえば、コンテンツ・サーバーの場合は/adfAuthenticationです。

10. 「保存」をクリックします。

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).>

アイデンティティ・プロバイダとサービス・プロバイダは同期してください。「デフォルト存続時間」と「デフォルト存続時間のオフセット」のデフォルト値を調整し、アイデンティティ・プロバイダとサービス・プロバイダ間の時刻のオフセットを修正することをお薦めします。

図27-14 デフォルト時間の設定

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の概念

• システム要件

• Microsoftクライアントの構成

MicrosoftクライアントSSOの概念

Kerberosの理解

Kerberosは、ネットワークのサービスに対するリクエストを認証するためのセキュアな方法です。Kerberosプロトコルは、クライアント、サーバーおよびそれらを仲介するKDC(Key Distribution Center)という信頼できるサード・パーティの3つのパーティから構成されます。Kerberosでは、ユーザーがそのアイデンティティを証明するKerberosチケットをサーバーに提供できる場合は、サーバーはユーザーがそのサービスにアクセスすることを許可します。ユーザーとサービスの両方が、KDCに登録された鍵を持つ必要があります。

次の図は、クライアントがサーバーに接続する前に行われる必要がある基本的なやり取りを示しています。

図27-15 Key Distribution Centerを通したサーバーへの接続

「図27-15 Key Distribution Centerを通したサーバーへの接続」の説明

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が処理します。)

図27-16 SPNEGOベースの認証

「図27-16 SPNEGOベースの認証」の説明

システム要件

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を構成するには、図27-17に示されているMicrosoft Active Directory、MicrosoftクライアントおよびWebLogic Serverドメインを構成する必要があります。構成手順とトラブルシューティングの詳細は、『Oracle WebLogic Serverセキュリティの管理』の「Microsoftのクライアントに対するシングル・サインオンの構成」を参照してください。

図27-17 MicrosoftクライアントでのSSOの構成

「図27-17 MicrosoftクライアントでのSSOの構成」の説明

SSO用にMicrosoftクライアントを構成するには:

1. Kerberosを使用するようにネットワーク・ドメインを構成します。

2. WebLogic Server用にKerberos識別情報を作成します。

   1. WebLogic Serverの動作するホスト用にActive Directoryのユーザー・アカウントを作成します。

   2. 作成したアカウント用にサービス・プリンシパル名を作成します。

   3. このアカウントのユーザー・マッピングとキータブ・ファイルを作成します(『Oracle WebLogic Serverセキュリティの管理』の「Microsoftのクライアントに対するシングル・サインオンの構成」を参照)。

3. ブラウザ・クライアント(Internet ExplorerまたはMozilla Firefox)を選択し、Kerberosトークンを使用するようにそれを構成します(Oracle Argus Insightインストレーション・ガイドのKerberosトークンを返すためのブラウザの構成に関する項を参照)。

4. Kerberos認証を使用するようにWebLogic Serverドメイン(この場合はwc_domain)をセットアップします。

   1. MicrosoftドメインのActive Directoryサーバーと手順2で作成したキータブ・ファイルをポイントするJAASログイン・ファイルを作成します(『Oracle WebLogic Serverセキュリティの管理』のJAASログイン・ファイルの作成に関する項を参照)。

   2. WebLogic Serverセキュリティ・レルムでネゴシエート・アイデンティティ・アサーション・プロバイダを構成します(「ネゴシエート・アイデンティティ・アサーション・プロバイダの構成」を参照)。

   3. Active Directoryオーセンティケータを使用するようにWebLogic Serverドメインを構成して、WebLogicドメインがアイデンティティ・ストアと同じActive Directoryドメインを使用するようにします。または、別のアイデンティティ・ストアを使用して、このストアのユーザーをドメインのActive Directoryユーザーと照合することもできますが、2つの異なるアイデンティティ・ストアを使用すると同期が失われる危険性があるため、Active Directoryオーセンティケータを使用することをお薦めします(「Active Directory認証プロバイダの構成」を参照)。

      注意:

      アイデンティティ・ストアのみをActive Directory用に構成してください。ポリシーおよび資格証明ストアはActive Directoryに対して認証されません。

5. 次のシステム・プロパティを各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を通してルーティングされた際にユーザーに表示される値です。

6. WebCenter Portalに対しては、「仮想ホストを使用したSSOの構成」の説明に従って、WebCenter Portal用のOracle WebLogic Serverにリクエストを転送するようにWeb層OHSを構成します。

7. 手順5で指定した起動引数を使用して、WebLogic Server (管理サーバーおよび管理対象サーバー)を再起動します。SOAドメインに対して手順4、5および6を繰り返し、SOAアプリケーションでのシングル・サインオンを有効化します。

8. OHSを再起動して変更を有効にします。

9. ディスカッション・サーバーを構成します(「SSO用のディスカッション・サーバーの構成」を参照)。

ネゴシエート・アイデンティティ・アサーション・プロバイダの構成

この項では、ネゴシエート・アイデンティティ・アサーション・プロバイダの作成および構成手順を説明します。ネゴシエーションIDアサーション・プロバイダを使用すると、Microsoft社製のクライアントでシングル・サインオン(SSO)を利用できます。アイデンティティ・アサーション・プロバイダは、SPNEGO(Simple and Protected Negotiate)トークンをデコードして、Kerberosトークンを取得し、それらのKerberosトークンを検証して、それらをWebLogicユーザーにマップします。ネゴシエート・アイデンティティ・アサーション・プロバイダはJava GSS(Generic Security Service) API(Application Programming Interface)を使用して、Kerberosを通してGSSセキュリティ・コンテキストを受け付けます。

ネゴシエート・アイデンティティ・アサーション・プロバイダを構成するには:

1. WebLogic Server管理コンソールにログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。

   「セキュリティ・レルムのサマリー」ペインが表示されます。

3. セキュリティ・レルムをクリックします。

   セキュリティ・レルムの「設定」ページが表示されます。

4. 「プロバイダ」タブを開き、「認証」サブタブを選択します。

   「認証設定」ペインが表示されます。

5. 「新規」をクリックします。

   「新しい認証プロバイダの作成」ペインが表示されます。

6. アイデンティティ・アサータの「名前」を入力し、「タイプ」としてNegotiateIdentityAsserterを選択します。
7. 「OK」をクリックします。

Active Directory認証プロバイダの構成

次の手順に従って、WebLogic管理コンソールを使用してActive Directory認証プロバイダを構成します。

Active Directory認証プロバイダを構成するには:

1. WebLogic Server管理コンソールにログインします。

   WebLogic Server管理コンソールへのログインの詳細は、「Oracle WebLogic Server管理コンソール」を参照してください。

2. 「ドメイン構造」ペインで、「セキュリティ・レルム」をクリックします。

   「セキュリティ・レルムのサマリー」ペインが表示されます。

3. セキュリティ・レルムをクリックします。

   セキュリティ・レルムの「設定」ページが表示されます。

4. 「プロバイダ」タブを開き、「認証」サブタブを選択します。

   「認証設定」ペインが表示されます。

5. 「新規」をクリックします。

   「新しい認証プロバイダの作成」ペインが表示されます。

6. 認証プロバイダの「名前」を入力し、「タイプ」としてActiveDirectoryAuthenticatorを選択します。

7. 「OK」をクリックします。

8. プロバイダのリストで、今作成した認証プロバイダをクリックします。

   プロバイダの「設定」ページが表示されます。

9. 「構成」タブを開き、「共通」サブタブを開きます。

10. 「制御フラグ」をSUFFICIENTに設定して、「保存」をクリックします。

    注意:

    他のすべてのオーセンティケータの制御フラグの設定も、SUFFICIENTに変更する必要があります。制御フラグがREQUIREDに設定された既存のデフォルト・オーセンティケータがある場合は、これをSUFFICIENTに変更する必要があります。

11. 「プロバイダ固有」サブタブを開きます。

    プロバイダ固有の設定ペインが表示されます。

12. 次の表に示されているように、各フィールドに値を入力します。これら以外のフィールドは、デフォルト値のままにします。

    表27-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))

13. 「保存」をクリックします。

14. プロバイダのサマリー・ページで、次の順序にプロバイダを並べ替え、それらの制御フラグが適宜SUFFICIENTに設定されていることを確認します。

    1. ネゴシエート・アイデンティティ・アサータ

    2. ActiveDirectoryAuthenticator (SUFFICIENT)

    3. DefaultAuthenticator (SUFFICIENT)

    4. 他のオーセンティケータ

WebCenter Portalの構成

ネゴシエート・アイデンティティ・アサーション・プロバイダと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用のディスカッション・サーバーの構成

この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。SSO用のディスカッション・サーバーを構成する前に、「外部LDAPを使用するためのディスカッション・サーバーの移行」の説明に従って、WebCenter Portalと同じアイデンティティ・ストアLDAPを使用するようにこれが構成されていることを確認してください。

SSO用のディスカッション・サーバーを設定する手順は次のとおりです。

1. Oracle WebCenter Portalのディスカッション・サーバー管理コンソールにログインします。

   http://host:port/owc_discussions/admin
   

   hostおよびportは、WC_Collaboration管理対象サーバーのホストIDとポート番号です。

2. 「システム・プロパティ」ページを開き、owc_discussions.sso.modeプロパティを編集(存在している場合)または追加します(値をtrueに設定します)。

仮想ホストを使用したSSOの構成

この項では、コンテキスト・ルートとして/を使用するアプリケーションを含む環境に必要なOHS構成と、シングル・サインオンが呼び出される際にOHSで必要な追加構成について説明します。

この項には次のサブセクションが含まれます:

• 仮想ホストの必要性の理解

• OAM 11g用の仮想ホストの構成

仮想ホストの必要性の理解

仮想ホストという用語は、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の仮想ホストを構成する手順は次のとおりです。

1. webgate.confの次の構成を見つけてコメント・アウトします。

   #Comment out this and move to VirtualHost configuration
   #<LocationMatch "/*">
   #AuthType Oblix
   #require valid-user
   #</LocationMatch>
   

   このエントリがあると、WebGateはすべてのリクエストをインターセプトして処理します。

2. 次の例に示されているように、シングル・サインオンが必要とされる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)にはシングル・サインオン・エクスペリエンスを提供しないという考え方です。

3. OHSを再起動します。さらに、webtier-spaces.example.comのエントリによるDNSの更新も行ってください。

注意:

シングル・サインオンをバイパスするwebtier-spaces.example.com仮想ホストでは、シングル・サインオンをバイパスする必要があるのは、一部のアプリケーションのみです。WebCenter Portalなどの他のアプリケーションでは、シングル・サインオンが必要なため、この仮想ホストからそれらのアプリケーションへのアクセスは拒否されます。