ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebCenter Portalの管理
11gリリース1 (11.1.1.8.3)
E51441-03
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

30 Oracle WebCenter Portalセキュリティの管理

この章では、WebCenter PortalおよびPortal Frameworkアプリケーションの保護の概要を説明し、さらにアプリケーションの初期デプロイ時に設定されているセキュリティ構成について説明します。また、トラブルシューティングの項では、セキュリティ関連の構成でよく見られる問題の解決策を示します。

この章には次の項が含まれます:

WebCenter PortalおよびPortal Frameworkアプリケーションのセキュリティ構成の特定の局面に関する詳細は、次を参照してください。


権限:

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

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


30.1 アプリケーション・セキュリティの概要

WebCenter PortalおよびPortal Frameworkアプリケーションの推奨セキュリティ・モデルは、Java Authentication and Authorization Service (JAAS)モデルを実装するOracle ADF Securityに基づいています。Oracle ADF Securityの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

図30-1は、WebCenter PortalまたはPortal Frameworkアプリケーション・デプロイメントとそのサービス、サーバー、ポートレット、ポートレット・プロデューサ、アイデンティティ・ストア、資格証明ストア、ポリシー・ストア、およびOracle Enterprise Managerの関係を示しています。

図30-1 WebCenter Portalアプリケーションの基本的なアーキテクチャ

図30-1の説明が続きます
「図30-1 WebCenter Portalアプリケーションの基本的なアーキテクチャ」の説明

図30-2は、バックエンド・サーバーが接続された、デプロイ後の基本的なWebCenter PortalまたはPortal Frameworkアプリケーションを示しています。

図30-2 バックエンド・サーバーが接続されたWebCenter Portalアプリケーションのアーキテクチャ

図30-2の説明が続きます
「図30-2 バックエンド・サーバーが接続されたWebCenter Portalアプリケーションのアーキテクチャ」の説明

図30-3は、WebCenter PortalおよびPortal Frameworkアプリケーションのセキュリティ・レイヤーを示しています。

図30-3 WebCenter Portalのセキュリティ・レイヤー

図30-3の説明が続きます
「図30-3 WebCenter Portalのセキュリティ・レイヤー」の説明

WebCenter PortalおよびPortal Frameworkアプリケーションは4つの同一下部セキュリティ・レイヤー(WebCenterセキュリティ・フレームワーク、ADFセキュリティ、OPSSおよびWebLogicサーバー・セキュリティ)を共有します。当然ながら、アプリケーション・レイヤーは実装に依存します。

WebCenter Portalアプリケーション・セキュリティ

WebCenter Portalでは、次のものがサポートされています。

WebCenter Portalセキュリティ・フレームワーク

WebCenter Portalセキュリティ・フレームワークでは、次のものがサポートされています。

ADFセキュリティ

ADFセキュリティでは、次のものがサポートされています。

Oracle Platform Security Services(OPSS)

OPSSでは、次のものがサポートされています。

WebLogic Serverセキュリティ

WebLogic Serverセキュリティでは、次のものがサポートされています。

30.2 デフォルトのセキュリティ構成

この項では、WebCenter PortalおよびPortal Frameworkアプリケーションのデプロイ時に設定されているセキュリティ構成と、デプロイ後に実行する必要のある構成タスクについて説明します。

30.2.1 管理者アカウント

Portal Frameworkアプリケーションでは、事前に用意されているアカウントがないため、Oracle Fusion Middlewareのインストール時に設定されるシステム管理者アカウント(デフォルトではweblogic)が使用されます。この管理者アカウントを使用して、Fusion Middleware Controlにログインし、新規アカウントを設定します。

WebCenter Portalアプリケーションでは、事前に用意されているアカウントはありませんが、WebCenter Portalアプリケーションのデフォルトのシステム管理者アカウント(weblogic)には特定の権限が事前に付与されています。インストール環境でシステム管理者ロールのアカウント名にweblogicを使用しない場合は、第32.6項「ユーザーおよびアプリケーション・ロールの管理」の手順に従って、このロールにその他のユーザーを1つ以上構成する必要があります。


注意:

weblogicアカウントはシステム管理者アカウントです。そのため、ユーザーレベルのアーティファクトを作成する際には使用しないでください。weblogicアカウントは、Fusion Middleware Controlで新規ユーザー・アカウントを作成する場合にのみ使用してください。


30.2.2 アプリケーション・ロールとエンタープライズ・ロール

アプリケーション・ロールは、組込みLDAPサーバーのアイデンティティ・ストア部分に存在するロールや、エンタープライズLDAPプロバイダにより定義されたロールとは異なります。アプリケーション・ロールはアプリケーションに固有であり、ポリシー・ストアのアプリケーション固有のストライプで定義されます。

エンタープライズ・アイデンティティ・ストアに格納されているエンタープライズ・ロールは、エンタープライズ・レベルでのみ適用されます。つまり、ユーザーやシステム管理者がエンタープライズ・アイデンティティ・ストア内部に定義したロールおよび権限は、アプリケーション内の権限とは異なります。

WebCenter PortalまたはPortal Frameworkアプリケーション内では、アプリケーション・ロールおよび権限を企業アイデンティティ・ストア内のユーザーに割り当てることができます。また、エンタープライズ・アイデンティティ・ストア内に定義されたエンタープライズ・ロールに対してアプリケーション・ロールおよび権限を割り当てることもできます。

30.2.3 デフォルトのアイデンティティ・ストアおよびポリシー・ストア

WebCenter PortalおよびPortal Frameworkアプリケーションはデフォルトで、ファイルベースの組込みLDAPアイデンティティ・ストアを使用してアプリケーションレベルのユーザーIDを格納し、ファイルベースのLDAPポリシー・ストアを使用してポリシー権限を格納するように構成されています。

組込みLDAPアイデンティティ・ストアはセキュアではありますが、本番クラスのストアではないため、エンタープライズ本番環境向けの外部LDAPベース・アイデンティティ・ストア(Oracle Internet Directoryなど)と置き換える必要があります。サポートされているアイデンティティ・ストアLDAPサーバーのリストは、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のサポートされているLDAPアイデンティティ・ストアのタイプに関する項を参照してください。


注意:

デフォルトのファイルベースのポリシー・ストアは、開発用および単一ノードのWebCenter Portal構成用にのみ使用してください。エンタープライズ・デプロイメントでは、第31章「アイデンティティ・ストアの構成」の説明に従って、ポリシー・ストアおよび資格証明ストアをデータベースまたは外部LDAPベースのストアに再度関連付ける必要があります。


ポリシー・ストアおよび資格証明ストアでは、Oracle Internet Directory 11gR1または10.1.4.3、またはOracle RDBMS (リリース10.2.0.4以降、リリース11.1.0.7以降およびリリース11.2.0.1以降)のいずれかを使用できます。外部LDAPベースのストアを使用する場合は、ポリシー・ストアと資格証明ストアで同じLDAPサーバーを使用するように構成する必要がある点に注意してください。同様に、データベースを使用する場合は、ポリシー・ストアと資格証明ストアで同じデータベースを使用する必要があります。

サポートされているアイデンティティ・ストア、ポリシー・ストアおよび資格証明ストアの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のサポートされているLDAPベース、DBベース、およびファイルベースのサービスに関する項を参照してください。アイデンティティ・ストア、ポリシー・ストアおよび資格証明ストアの再構成の詳細は、第31章「アイデンティティ・ストアの構成」および第32章「ポリシーおよび資格証明ストアの構成」を参照してください。


注意:

ディスカッションはデフォルトで、組込みLDAPアイデンティティ・ストアを使用するように構成されています。組込みLDAPストア内のすべてのユーザーがディスカッション・サーバーにログオンできます。また、Administratorsグループ内のすべてのユーザーがディスカッション・サーバーの管理権限を保有します。

アイデンティティ・ストアを外部LDAPサーバーに再度関連付けた場合、システム管理者アカウントを外部LDAPに移行するか(第31.4項「外部LDAPサーバーへの管理者アカウントの移行」を参照)、管理者アカウントを移行しない場合には、ディスカッション・サーバーの新しい管理者アカウントを識別するために追加の手順が必要になります(第31.4.1項「外部LDAPを使用するためのディスカッション・サーバーの移行」を参照)。

WebCenter Portalに関しては、WebCenter PortalアプリケーションおよびContent Serverは同じLDAPサーバーを共有する必要があります。詳細は、第31.5項「Oracle Content ServerとWebCenter Portalでアイデンティティ・ストアLDAPサーバーを共有するための構成」を参照してください。


30.2.3.1 ファイルベースの資格証明ストア

初期設定の資格証明ストアはウォレットベース(ファイルベース)であり、ファイルcwallet.ssoに含まれています。このファイルの場所は、Oracle Platform Security構成ファイルjps-config.xmlで指定されています。ポリシー・ストアをLDAPディレクトリに再度関連付けると、アプリケーションの資格証明がポリシー・ストアと同じLDAPディレクトリに自動的に移行されます。

30.2.4 デフォルトのポリシー・ストアの権限および付与

ADFセキュリティの権限モデルでは、権限ベースの認可およびロールベースの認可の両方がサポートされています。次の項では、この2つの認可タイプ、デフォルトのポリシー・ストア権限およびコードベース権限について説明します。

30.2.4.1 権限ベースの認可

権限ベースの認可は、リストなど、Oracle Platform Security Services (OPSS)を使用してWebCenter PortalまたはPortal Frameworkアプリケーション内にアクセス制御が実装されているツールで使用されます。WebCenter Portalには、ユーザーおよびロール管理ツールが豊富に用意されています。これらのツールによってアプリケーション・ロールを作成し、そのロールに付与する必要がある権限を定義できます。WebCenter Portalでのユーザーおよびロールの管理の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの使用』のアプリケーション・ロールおよび権限の管理に関する項を参照してください。

30.2.4.2 ロール・マッピングベースの認可

リモート(バックエンド)リソースへのアクセスが必要なツールおよびサービスでは、ロール・マッピングベースの認可が必須になります。たとえば、ディスカッションで、WebCenter PortalまたはPortal Frameworkアプリケーションの(1つ以上のアプリケーション・ロールにマップされている)ユーザーをディスカッション・サーバーの別のロール・セットにマップする必要がある場合は、ロール・マッピングが必須です。

たとえば、WebCenter Portalアプリケーションでは次のようになります。

  • WebCenter Portalのロールは、バックエンドのディスカッション・サーバーの対応するロールにマップされます。

  • ユーザーに新しいWebCenter Portalロールが付与されると、バックエンドのディスカッション・サーバーで同様の権限が付与されます。たとえば、ユーザーPatがWebCenter PortalでDiscussions-Create/Edit/Delete権限を付与された場合、バックエンドのディスカッション・サーバーで、対応する権限がPatに付与されます。

『Oracle Fusion Middleware Oracle WebCenter Portalの使用』のディスカッション・サーバーのロールおよび権限マッピングの理解に関する項も参照してください。

30.2.4.3 WebCenter Portalのデフォルトのポリシー・ストア権限

WebCenter Portalには、初期設定で次のデフォルト・ロールが用意されています。

デフォルトのアプリケーション・ロール:

  • 管理者

  • アプリケーション・スペシャリスト

  • 認証されたユーザー

  • パブリック・ユーザー

デフォルトのアプリケーション・ロールの詳細は、次を参照してください。

ポータル内のデフォルトのロール

  • モデレータ

  • 参加者

  • ビューア

ポータル内のデフォルトのロールの詳細は、第43.4.2.1項「アプリケーション・ロールの理解」を参照してください。

30.2.4.4 デフォルトのコードベース権限

WebCenter PortalおよびPortal Frameworkアプリケーションは、権限チェックを使用して保護されたセキュリティ・プラットフォームでAPIを内部的にコールします。したがって、OPSSのAPIを呼び出すには、アプリケーションに適切な権限を付与する必要があります(たとえば、ポリシー・ストアにアクセスして権限を付与または取り消す(PolicyStoreAccessPermission)ための権限や、アプリケーション・ロールに基本的な権限を付与するための権限など)。WebCenter Portalでは、アプリケーション・ロールの基本的な権限はデフォルトで付与されています(第43.4.2項「アプリケーション・ロールおよび権限の理解」を参照)。

同様に、WebCenter PortalおよびPortal Frameworkアプリケーションでは、WebCenter Portalの権限を使用して公開する各種操作に対して事前にアクセスを認可しておき、OPSS APIを権限付きアクションとして呼び出す必要があります。

30.2.5 デプロイ後のセキュリティ構成タスク

WebCenter PortalまたはPortal Frameworkアプリケーションをデプロイした後で、次のセキュリティ関連の構成タスクをサイトに対して実行することを考慮する必要があります。

  • 外部LDAPを使用するためのアイデンティティ・ストアの再関連付け

    WebCenter PortalおよびPortal Frameworkアプリケーションではデフォルトで、アイデンティティ・ストアに組込みLDAPが使用されます。事前に構成されている組込みLDAPは、セキュアではありますが、大規模なエンタープライズ本番環境には適さない場合があります。Oracle Internet Directory (OID)などの外部LDAPを使用するようにアイデンティティ・ストアを構成する方法の詳細は、第31章「アイデンティティ・ストアの構成」を参照してください。


    注意:

    WebCenter Portalのディスカッション・サーバーはデフォルトで、組込みLDAPアイデンティティ・ストアを使用するように構成されています。組込みLDAPストア内のすべてのユーザーがディスカッション・サーバーにログオンできます。また、Administratorsグループ内のすべてのユーザーがディスカッション・サーバーの管理権限を保有します。

    アイデンティティ・ストアを外部LDAPサーバーに再度関連付けた場合、システム管理者アカウントを外部LDAPに移行するか(第31.4項「外部LDAPサーバーへの管理者アカウントの移行」を参照)、管理者アカウントを移行しない場合には、ディスカッション・サーバーの新しい管理者アカウントを識別するために追加の手順が必要になります(第31.4.1項「外部LDAPを使用するためのディスカッション・サーバーの移行」を参照)。

    WebCenter Portalに関しては、WebCenter PortalアプリケーションおよびContent Serverは同じLDAPサーバーを共有する必要があります。詳細は、第31.5項「Oracle Content ServerとWebCenter Portalでアイデンティティ・ストアLDAPサーバーを共有するための構成」を参照してください。


  • 外部LDAPまたはデータベースを使用するためのポリシー・ストアの再関連付け

    Portal Frameworkアプリケーションではデフォルトで、ポリシー権限を格納するためにファイルベースのsystem-jazn-data.xmlポリシー・ストアが使用されます。LDAPベースまたはデータベースのポリシー・ストアを使用することを考慮する必要があります。LDAPサーバーまたはデータベースを使用するようにポリシー・ストアを構成する方法の詳細は、第32章「ポリシーおよび資格証明ストアの構成」を参照してください。

  • WS-Securityの構成

    WS-Securityを使用すると、Portal Frameworkアプリケーションおよびそれが使用する一連のプロデューサの構成や管理が複雑になりますが、Portal Frameworkアプリケーションで公開される情報のセキュリティを確保する上で役立ちます。WS-Securityを追加すると、コンシューマの認証およびメッセージレベルのセキュリティを使用できるようになります。

    Portal Frameworkアプリケーションおよびコンポーネントに対してWS-Securityを構成する方法の詳細は、第36章「WS-Securityの構成」を参照してください。

  • SSOの構成

    シングル・サインオン(SSO)を使用すると、ユーザーはサブアプリケーションごとにログインするのではなく(WebCenter Portal内のwikiページにアクセスする場合など)、WebCenter PortalおよびPortal Frameworkアプリケーションおよびコンポーネント全体で1回ログインするだけで済みます。ユーザーは、アクセスするアプリケーションまたはコンポーネントごとに別個のユーザーIDおよびパスワードを保持する必要がありません。ただし、より厳密な方式を使用して機密性の高いアプリケーションを保護できるように、多様な認証方式を構成することもできます。WebCenter PortalおよびPortal Frameworkアプリケーションでは、4つのシングル・サインオン・ソリューション(Oracle Access Manager (OAM)、Oracle Single Sign-on (OSSO)、Oracle WebCenter Portalアプリケーション専用のSAMLベースのシングル・サインオン・ソリューション、およびSimple and Protected Negotiate (SPNEGO)メカニズムとKerberosプロトコルに基づいたWindows認証による、Microsoftクライアント用SSOソリューション)がサポートされています。これらのソリューションの説明およびシングル・サインオンの概要については、第33章「シングル・サインオンの構成」を参照してください。

  • SSLの構成

    Secure Sockets Layer (SSL)は、WebCenter PortalおよびPortal Frameworkアプリケーションまたはコンポーネントの間の接続に対して追加の認証レイヤーを提供し、交換されるデータを暗号化することにより、接続セキュリティを強化するものです。データ交換が機密的なアプリケーションまたはコンポーネント間の接続では、SSLを使用して接続を保護することを考慮してください。本番環境でSSLを使用して保護できる、または保護する必要のある接続のリストは、第35章「SSLの構成」を参照してください。


    注意:

    SSLを使用すると、計算が集中的に行われ、接続のオーバーヘッドが増加します。このため、SSLは必要でないかぎりは使用しないでください。SSLは本番環境まで保留しておくことをお薦めします。


30.3 セキュリティ構成に関する問題のトラブルシューティング

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

30.3.1 WebCenter PortalアプリケーションでLDAPプロバイダのユーザーが見つからない

問題

外部LDAPプロバイダを使用してWeblogic Serverを構成しました。外部LDAPのユーザーはWebCenter Portalにログインできますが、WebCenter Portalで外部LDAPのユーザーに管理者ロールを割り当てようとすると、ユーザーが一人も見つかりません。

解決策

第31章「アイデンティティ・ストアの構成」の手順に従って、DefaultAuthenticator認証プロバイダの制御フラグをSufficientに変更します。 ドメインの管理サーバーと管理対象サーバーを再起動します。

30.3.2 OIDユーザーとしてログインしている場合にポータルを作成するとエラーが発生する

問題

OIDユーザー(orcladminなど)としてWebCenter Portalにログインしている場合にポータルを作成しようとすると、ポータルは作成されますがエラーが発生します。エラー・メッセージには「No matching users were found with search string <login user>」のように表示されます。

解決策

jps-config.xmlファイルに次のプロパティが設定されていません。

<property name="jps.user.principal.class.name" value="weblogic.security.principal.WLSUserImpl"/> 

この問題を解決する手順は次のとおりです。

  1. DOMAIN_HOME/config/fmwconfig/jps-config.xmlを編集します。

  2. 一般プロパティに次の行を追加します。

    <property name="jps.user.principal.class.name" value="weblogic.security.principal.WLSUserImpl"/>

  3. WC_Spacesサーバーを再起動します。

30.3.3 Active Directoryを使用してWebCenter Portalを構成するとユーザーが自己登録できない

問題

WebCenter PortalでADオーセンティケータを使用するように構成すると、ユーザーがActive Directoryに自己登録できません。ユーザーが自己登録しようとすると、次のエラー・メッセージが表示されます。

"User not created. Either the user name or the password does not adhere to the registration policy or the identity store is unavailable. Specify the required user credentials or contact your administrator for assistance"

解決策

この問題を解決する手順は次のとおりです。

  1. WebLogic管理コンソールでActive Directoryを構成する際に、ユーザー名属性をsAMAccountNameに設定します。

  2. WebLogic管理コンソールでActive Directoryを構成する際に、LDAPのHTTPSポートを使用し、SSLのチェック・ボックスを選択します。

30.3.4 管理者に設定されたユーザーが管理者権限を使用できない

問題

orcladminとしてログインし、ユーザーを管理者に設定した後でログアウトし、そのユーザーで再度ログインしても、管理者リンクが使用可能になりません。

解決策

この問題は、アイデンティティ・ストア内でcnエントリが重複しているために起こります。cnはユーザー名属性にマップされており、一意である必要があります。アイデンティティ・ストアから重複を削除し、そのユーザーに適切なprivileges.cnを設定してください。

30.3.5 SSO環境のOmniPortletプロデューサで認可例外が発生する

問題

SSOを使用してWebCenter Portalが構成されている場合に、OmniPortletプロデューサでCredential Store Framework (CSF)ウォレットに接続情報を格納しようとすると認可例外が発生します。

解決策

WLST(詳細は、第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」を参照)を使用してOracle WebCenter Portal Administration Serverに接続し、次の付与コマンドを実行して、ssofilter.jarに必要な権限を付与します。

grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_user,keyName=*",
permActions="*")
grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_default,keyName=*",
permActions="*")
grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1
.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_user,keyName=*",
permActions="*")

30.3.6 SAML SSO固有のディスカッションEARファイルをデプロイすると例外が発生する

問題

ディスカッションEARファイルをアンデプロイしてから、SAML SSO固有のディスカッションEARファイルをデプロイし、WLS管理コンソールでアプリケーションを起動すると、管理コンソールで次の例外が発生します。

java.lang.ClassCastException:
org.apache.xerces.parsers.XIncludeAwareParserConfiguration

解決策

WC_Collaborationサーバーを再起動します。これにより問題が解決され、ディスカッション・アプリケーションがアクティブな状態になるはずです。

30.3.7 SAMLシングル・サインオンを構成すると403エラーが発生する

問題

SAML SSO構成のテスト中に403エラーが発生したため、デバッグ・ロギングを有効化(第33.4.2.4項「構成のチェック」を参照)したところ、宛先サーバーで次のようなエラー・ログが表示されました。

####<Oct 11, 2010 10:20:31 PM PDT> <Debug> <SecuritySAMLLib> <adc2170966>
<soa_server1> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<efaf471a17d5a745:-5ba0524a:12b9b0b7849:-8000-0000000000015385>
<1286860831335> <BEA-000000> <SAMLSignedObject.verify(): validating
signature>
####<Oct 11, 2010 10:20:31 PM PDT> <Debug> <SecuritySAMLService> <adc2170966>
<soa_server1> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<efaf471a17d5a745:-5ba0524a:12b9b0b7849:-8000-0000000000015385>
<1286860831336> <BEA-000000> <SAMLDestinationSiteHelper: Signature
verification failed with exception: org.opensaml.InvalidCryptoException:
SAMLSignedObject.verify() failed to validate signature value>
####<Oct 11, 2010 10:20:31 PM PDT> <Debug> <SecuritySAMLService> <adc2170966>
<soa_server1> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<efaf471a17d5a745:-5ba0524a:12b9b0b7849:-8000-0000000000015385>
<1286860831336> <BEA-000000> <SAMLDestinationSiteHelper: Unable to validate
response -- returning SC_FORBIDDEN>
####<Oct 11, 2010 10:20:31 PM PDT> <Debug> <SecuritySAMLService> <adc2170966>
<soa_server1> <[ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<efaf471a17d5a745:-5ba0524a:12b9b0b7849:-8000-0000000000015385>
<1286860831336> <BEA-000000> <SAMLSingleSignOnService.doACSGet: Failed to get
SAML credentials -- returning>

解決策

SAMLアサーションが検証されていないため、証明書の設定が正しく行われていないことが考えられます。この場合、SAMLアイデンティティ・アサータに適切な証明書が登録されていない可能性があります。WebCenter PortalドメインにSAML SSOを設定したときにcertAliasおよびcertPasswordで指定した証明書をエクスポートして、宛先ドメインでアクセス可能な場所にコピーします。

  1. WebCenter Portalドメインのwcsamlsso.propertiesファイルで関連する構成セクションを更新します(たとえば、SOA構成で証明書が無効の場合は、soa_configセクションのcertPathを更新します)。

  2. WebLogic Server管理コンソールを開いて、WC_Spacesドメインから「セキュリティ・レルム」→「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」に移動し、ドメインに関連するリライイング・パーティ(たとえば、SOAの場合は、ワークリスト統合、ワークリスト詳細およびワークリストSDPになります)を削除します。

  3. 「宛先ドメイン」→「セキュリティ・レルム」→「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」に移動し、対応するアサーティング・パーティを削除します。

  4. 「証明書」タブを開き、証明書も削除します。

  5. WebCenter Portalドメインに戻り、アサーティング・パーティとリライイング・パーティの組合せを作成するためスクリプトを再実行します。たとえば、SOAの場合は、次のように再実行する必要があります。

    WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistIntegration.py
    WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistDetail.py
    WCP_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistSDP.py
    
  6. 構成を再度テストします。すべて問題なく機能すれば、SAMLロギングを無効化できます。