Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.8.3) E51441-03 |
|
前 |
次 |
この章では、WebCenter PortalおよびPortal Frameworkアプリケーションの保護の概要を説明し、さらにアプリケーションの初期デプロイ時に設定されているセキュリティ構成について説明します。また、トラブルシューティングの項では、セキュリティ関連の構成でよく見られる問題の解決策を示します。
この章には次の項が含まれます:
WebCenter PortalおよびPortal Frameworkアプリケーションのセキュリティ構成の特定の局面に関する詳細は、次を参照してください。
権限: この章のタスクを実行するには、Oracle WebLogic Server管理コンソールでWebLogic Serverの 第1.8項「管理操作、ロールおよびツールの理解」も参照してください。 |
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-2は、バックエンド・サーバーが接続された、デプロイ後の基本的なWebCenter PortalまたはPortal Frameworkアプリケーションを示しています。
図30-2 バックエンド・サーバーが接続されたWebCenter Portalアプリケーションのアーキテクチャ
図30-3は、WebCenter PortalおよびPortal Frameworkアプリケーションのセキュリティ・レイヤーを示しています。
WebCenter PortalおよびPortal Frameworkアプリケーションは4つの同一下部セキュリティ・レイヤー(WebCenterセキュリティ・フレームワーク、ADFセキュリティ、OPSSおよびWebLogicサーバー・セキュリティ)を共有します。当然ながら、アプリケーション・レイヤーは実装に依存します。
WebCenter Portalアプリケーション・セキュリティ
WebCenter Portalでは、次のものがサポートされています。
アプリケーション・ロール管理および権限マッピング
自己登録
ポータルレベルのセキュリティ管理
外部アプリケーションの資格証明管理
WebCenter Portalセキュリティ・フレームワーク
WebCenter Portalセキュリティ・フレームワークでは、次のものがサポートされています。
サービス・セキュリティ拡張フレームワーク(サービスのセキュリティ・モデルを指定する際に一般的に使用される、権限ベースおよびロール・マッピングベースのモデル)
権限ベースの認可
ロール・マッピングベースの認可
外部アプリケーションと資格証明とのマッピング
ADFセキュリティ
ADFセキュリティでは、次のものがサポートされています。
ページ認可
タスク・フロー認可
セキュアな接続管理
資格証明マッピングAPI
ログアウトの呼出し(Oracle Access ManagerおよびOracle SSOを使用したSSO対応構成からのログアウトなど)
ADFセキュリティベースのアプリケーション(adfAuthenticationサーブレット)用に保護されたログインURL
Oracle Platform Security Services(OPSS)
OPSSでは、次のものがサポートされています。
Anonymous-role
Authenticated-role
アイデンティティ・ストア、ポリシー・ストアおよび資格証明ストア
アイデンティティ管理サービス
Oracle Web Service Managerセキュリティ
認可
ポリシーおよび資格証明ライフサイクル
WebLogic Serverセキュリティ
WebLogic Serverセキュリティでは、次のものがサポートされています。
WebLogicオーセンティケータ
アイデンティティ・アサータ
J2EEコンテナ・セキュリティ
SSL
この項では、WebCenter PortalおよびPortal Frameworkアプリケーションのデプロイ時に設定されているセキュリティ構成と、デプロイ後に実行する必要のある構成タスクについて説明します。
Portal Frameworkアプリケーションでは、事前に用意されているアカウントがないため、Oracle Fusion Middlewareのインストール時に設定されるシステム管理者アカウント(デフォルトではweblogic
)が使用されます。この管理者アカウントを使用して、Fusion Middleware Controlにログインし、新規アカウントを設定します。
WebCenter Portalアプリケーションでは、事前に用意されているアカウントはありませんが、WebCenter Portalアプリケーションのデフォルトのシステム管理者アカウント(weblogic
)には特定の権限が事前に付与されています。インストール環境でシステム管理者ロールのアカウント名にweblogic
を使用しない場合は、第32.6項「ユーザーおよびアプリケーション・ロールの管理」の手順に従って、このロールにその他のユーザーを1つ以上構成する必要があります。
注意:
|
アプリケーション・ロールは、組込みLDAPサーバーのアイデンティティ・ストア部分に存在するロールや、エンタープライズLDAPプロバイダにより定義されたロールとは異なります。アプリケーション・ロールはアプリケーションに固有であり、ポリシー・ストアのアプリケーション固有のストライプで定義されます。
エンタープライズ・アイデンティティ・ストアに格納されているエンタープライズ・ロールは、エンタープライズ・レベルでのみ適用されます。つまり、ユーザーやシステム管理者がエンタープライズ・アイデンティティ・ストア内部に定義したロールおよび権限は、アプリケーション内の権限とは異なります。
WebCenter PortalまたはPortal Frameworkアプリケーション内では、アプリケーション・ロールおよび権限を企業アイデンティティ・ストア内のユーザーに割り当てることができます。また、エンタープライズ・アイデンティティ・ストア内に定義されたエンタープライズ・ロールに対してアプリケーション・ロールおよび権限を割り当てることもできます。
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ストア内のすべてのユーザーがディスカッション・サーバーにログオンできます。また、 アイデンティティ・ストアを外部LDAPサーバーに再度関連付けた場合、システム管理者アカウントを外部LDAPに移行するか(第31.4項「外部LDAPサーバーへの管理者アカウントの移行」を参照)、管理者アカウントを移行しない場合には、ディスカッション・サーバーの新しい管理者アカウントを識別するために追加の手順が必要になります(第31.4.1項「外部LDAPを使用するためのディスカッション・サーバーの移行」を参照)。 WebCenter Portalに関しては、WebCenter PortalアプリケーションおよびContent Serverは同じLDAPサーバーを共有する必要があります。詳細は、第31.5項「Oracle Content ServerとWebCenter Portalでアイデンティティ・ストアLDAPサーバーを共有するための構成」を参照してください。 |
ADFセキュリティの権限モデルでは、権限ベースの認可およびロールベースの認可の両方がサポートされています。次の項では、この2つの認可タイプ、デフォルトのポリシー・ストア権限およびコードベース権限について説明します。
権限ベースの認可は、リストなど、Oracle Platform Security Services (OPSS)を使用してWebCenter PortalまたはPortal Frameworkアプリケーション内にアクセス制御が実装されているツールで使用されます。WebCenter Portalには、ユーザーおよびロール管理ツールが豊富に用意されています。これらのツールによってアプリケーション・ロールを作成し、そのロールに付与する必要がある権限を定義できます。WebCenter Portalでのユーザーおよびロールの管理の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの使用』のアプリケーション・ロールおよび権限の管理に関する項を参照してください。
リモート(バックエンド)リソースへのアクセスが必要なツールおよびサービスでは、ロール・マッピングベースの認可が必須になります。たとえば、ディスカッションで、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の使用』のディスカッション・サーバーのロールおよび権限マッピングの理解に関する項も参照してください。
WebCenter Portalには、初期設定で次のデフォルト・ロールが用意されています。
デフォルトのアプリケーション・ロール:
管理者
アプリケーション・スペシャリスト
認証されたユーザー
パブリック・ユーザー
デフォルトのアプリケーション・ロールの詳細は、次を参照してください。
ポータル内のデフォルトのロール
モデレータ
参加者
ビューア
ポータル内のデフォルトのロールの詳細は、第43.4.2.1項「アプリケーション・ロールの理解」を参照してください。
WebCenter PortalおよびPortal Frameworkアプリケーションは、権限チェックを使用して保護されたセキュリティ・プラットフォームでAPIを内部的にコールします。したがって、OPSSのAPIを呼び出すには、アプリケーションに適切な権限を付与する必要があります(たとえば、ポリシー・ストアにアクセスして権限を付与または取り消す(PolicyStoreAccessPermission
)ための権限や、アプリケーション・ロールに基本的な権限を付与するための権限など)。WebCenter Portalでは、アプリケーション・ロールの基本的な権限はデフォルトで付与されています(第43.4.2項「アプリケーション・ロールおよび権限の理解」を参照)。
同様に、WebCenter PortalおよびPortal Frameworkアプリケーションでは、WebCenter Portalの権限を使用して公開する各種操作に対して事前にアクセスを認可しておき、OPSS APIを権限付きアクションとして呼び出す必要があります。
WebCenter PortalまたはPortal Frameworkアプリケーションをデプロイした後で、次のセキュリティ関連の構成タスクをサイトに対して実行することを考慮する必要があります。
外部LDAPを使用するためのアイデンティティ・ストアの再関連付け
WebCenter PortalおよびPortal Frameworkアプリケーションではデフォルトで、アイデンティティ・ストアに組込みLDAPが使用されます。事前に構成されている組込みLDAPは、セキュアではありますが、大規模なエンタープライズ本番環境には適さない場合があります。Oracle Internet Directory (OID)などの外部LDAPを使用するようにアイデンティティ・ストアを構成する方法の詳細は、第31章「アイデンティティ・ストアの構成」を参照してください。
注意: WebCenter Portalのディスカッション・サーバーはデフォルトで、組込みLDAPアイデンティティ・ストアを使用するように構成されています。組込みLDAPストア内のすべてのユーザーがディスカッション・サーバーにログオンできます。また、 アイデンティティ・ストアを外部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は本番環境まで保留しておくことをお薦めします。 |
この項には次のサブセクションが含まれます:
問題
外部LDAPプロバイダを使用してWeblogic Serverを構成しました。外部LDAPのユーザーはWebCenter Portalにログインできますが、WebCenter Portalで外部LDAPのユーザーに管理者ロールを割り当てようとすると、ユーザーが一人も見つかりません。
解決策
第31章「アイデンティティ・ストアの構成」の手順に従って、DefaultAuthenticator
認証プロバイダの制御フラグをSufficient
に変更します。 ドメインの管理サーバーと管理対象サーバーを再起動します。
問題
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"/>
この問題を解決する手順は次のとおりです。
DOMAIN_HOME/config/fmwconfig/jps-config.xml
を編集します。
一般プロパティに次の行を追加します。
<property name="jps.user.principal.class.name" value="weblogic.security.principal.WLSUserImpl"/>
WC_Spaces
サーバーを再起動します。
問題
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
"
解決策
この問題を解決する手順は次のとおりです。
WebLogic管理コンソールでActive Directoryを構成する際に、ユーザー名属性をsAMAccountName
に設定します。
WebLogic管理コンソールでActive Directoryを構成する際に、LDAPのHTTPSポートを使用し、SSLのチェック・ボックスを選択します。
問題
orcladmin
としてログインし、ユーザーを管理者に設定した後でログアウトし、そのユーザーで再度ログインしても、管理者リンクが使用可能になりません。
解決策
この問題は、アイデンティティ・ストア内でcn
エントリが重複しているために起こります。cn
はユーザー名属性にマップされており、一意である必要があります。アイデンティティ・ストアから重複を削除し、そのユーザーに適切なprivileges
.cn
を設定してください。
問題
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="*")
問題
ディスカッションEARファイルをアンデプロイしてから、SAML SSO固有のディスカッションEARファイルをデプロイし、WLS管理コンソールでアプリケーションを起動すると、管理コンソールで次の例外が発生します。
java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration
解決策
WC_Collaboration
サーバーを再起動します。これにより問題が解決され、ディスカッション・アプリケーションがアクティブな状態になるはずです。
問題
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
で指定した証明書をエクスポートして、宛先ドメインでアクセス可能な場所にコピーします。
WebCenter Portalドメインのwcsamlsso.properties
ファイルで関連する構成セクションを更新します(たとえば、SOA構成で証明書が無効の場合は、soa_config
セクションのcertPath
を更新します)。
WebLogic Server管理コンソールを開いて、WC_Spaces
ドメインから「セキュリティ・レルム」→「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」に移動し、ドメインに関連するリライイング・パーティ(たとえば、SOAの場合は、ワークリスト統合、ワークリスト詳細およびワークリストSDPになります)を削除します。
「宛先ドメイン」→「セキュリティ・レルム」→「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」に移動し、対応するアサーティング・パーティを削除します。
「証明書」タブを開き、証明書も削除します。
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
構成を再度テストします。すべて問題なく機能すれば、SAMLロギングを無効化できます。