| Oracle® Fusion Middleware Oracle WebCenter Portal管理者ガイド 11g リリース1 (11.1.1.7.0) B72085-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portal管理者ガイド 11g リリース1 (11.1.1.7.0) B72085-02 |
|
前 |
次 |
この章では、WebCenter Portal: Frameworkアプリケーションの保護の概要を説明し、さらにFrameworkアプリケーションおよびSpacesアプリケーションの初期デプロイ時に設定されているセキュリティ構成について説明します。また、トラブルシューティングの項では、セキュリティ関連の構成でよく見られる問題の解決策を示します。
この章の内容は次のとおりです。
WebCenter Portalアプリケーション(FrameworkアプリケーションおよびSpacesアプリケーションを含む)のセキュリティ構成の特定の局面に関する詳細は、次を参照してください。
対象読者
この章の内容は、Fusion Middleware管理者(Oracle WebLogic Server管理コンソールを使用してAdminロールを付与されたユーザー)を対象としています。MonitorまたはOperatorロールを持つユーザーは、セキュリティ情報を表示できますが変更することはできません。第1.8項「管理操作、ロールおよびツールの理解」も参照してください。
WebCenter Portalアプリケーションの推奨セキュリティ・モデルは、Java Authentication and Authorization Service (JAAS)モデルを実装するOracle ADF Securityに基づいています。Oracle ADF Securityの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
図29-1は、WebCenter Portalアプリケーション・デプロイメントとそのサービス、サーバー、ポートレット、ポートレット・プロデューサ、アイデンティティ・ストア、資格証明ストア、ポリシー・ストア、およびOracle Enterprise Managerの関係を示しています。
図29-2は、バックエンド・サーバーが接続されたデプロイ後の基本的なWebCenter Portalアプリケーションを示しています。
図29-2 バックエンド・サーバーが接続されたWebCenter Portalアプリケーションのアーキテクチャ
図29-3は、WebCenter Portalアプリケーションのセキュリティ・レイヤーを示しています。
FrameworkアプリケーションとSpacesは4つの同一下部セキュリティ・レイヤー(WebCenterセキュリティ・フレームワーク、ADFセキュリティ、OPSSおよびWebLogicサーバー・セキュリティ)を共有します。当然ながら、アプリケーション・レイヤーは実装に依存します。
WebCenter Portalアプリケーション・セキュリティ
WebCenter Portalでは、次のものがサポートされています。
アプリケーション・ロール管理および権限マッピング
自己登録
スペースレベルのセキュリティ管理
外部アプリケーションの資格証明管理
WebCenter Portalセキュリティ・フレームワーク
WebCenter Portalセキュリティ・フレームワークでは、次のものがサポートされています。
サービス・セキュリティ拡張フレームワーク(サービスのセキュリティ・モデルを指定する際に一般的に使用される、権限ベースおよびロール・マッピングベースのモデル)
権限ベースの認可
ロール・マッピングベースの認可
外部アプリケーションと資格証明とのマッピング
ADFセキュリティ
ページ認可
タスク・フロー認可
セキュアな接続管理
資格証明マッピングAPI
ログアウトの呼出し(Oracle Access ManagerおよびOracle SSOを使用したSSO対応構成からのログアウトなど)
ADFセキュリティベースのアプリケーション(adfAuthenticationサーブレット)用に保護されたログインURL
Oracle Platform Security Services (OPSS)
Anonymous-role
Authenticated-role
アイデンティティ・ストア、ポリシー・ストアおよび資格証明ストア
アイデンティティ管理サービス
Oracle Web Service Manager Security
認可
ポリシーおよび資格証明のライフ・サイクル
WebLogic Serverセキュリティ
WebLogic Serverセキュリティでは、次のものがサポートされています。
WebLogicオーセンティケータ
アイデンティティ・アサータ
J2EEコンテナ・セキュリティ
SSL
この項では、WebCenter Portal: FrameworkアプリケーションとWebCenter Portal: Spacesのデプロイ時に設定されているセキュリティ構成と、デプロイ後に実行する必要のあるタスクについて説明します。
Frameworkアプリケーションでは、事前に用意されているアカウントがないため、Fusion Middlewareのインストール時に設定されるFusion Middleware管理者アカウント(デフォルトではweblogic)が使用されます。この管理者アカウントを使用して、Fusion Middleware Controlにログインし、新規アカウントを設定します。
Spacesアプリケーションでは、事前に用意されているアカウントはありませんが、SpacesアプリケーションのデフォルトのFusion Middleware管理者アカウント(weblogic)には特定の権限が事前に付与されています。インストール環境でFusion Middleware管理者ロールのアカウント名にweblogicを使用しない場合は、第31.6項「ユーザーおよびアプリケーション・ロールの管理」の手順に従って、このロールにその他のユーザーを1つ以上構成する必要があります。
|
注意:
|
アプリケーション・ロールは、組込みLDAPサーバーのアイデンティティ・ストア部分に存在するロールや、エンタープライズLDAPプロバイダにより定義されたロールとは異なります。アプリケーション・ロールはアプリケーションに固有であり、ポリシー・ストアのアプリケーション固有のストライプで定義されます。
エンタープライズ・アイデンティティ・ストアに格納されているエンタープライズ・ロールは、エンタープライズ・レベルでのみ適用されます。つまり、ユーザーやシステム管理者がエンタープライズ・アイデンティティ・ストア内部に定義したロールおよび権限は、アプリケーション内の権限とは異なります。
SpacesまたはFrameworkアプリケーション内では、アプリケーション・ロールおよび権限を企業アイデンティティ・ストア内のユーザーに割り当てることができます。また、エンタープライズ・アイデンティティ・ストア内に定義されたエンタープライズ・ロールに対してアプリケーション・ロールおよび権限を割り当てることもできます。
WebCenter Portalアプリケーションはデフォルトで、ファイルベースの組込みLDAPアイデンティティ・ストアを使用してアプリケーションレベルのユーザーIDを格納し、ファイルベースのLDAPポリシー・ストアを使用してポリシー権限を格納するように構成されています。
組込みLDAPアイデンティティ・ストアはセキュアではありますが、本番クラスのストアではないため、エンタープライズ本番環境向けの外部LDAPベース・アイデンティティ・ストア(Oracle Internet Directoryなど)と置き換える必要があります。サポートされているアイデンティティ・ストアLDAPサーバーのリストは、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のサポートされているLDAPアイデンティティ・ストアのタイプに関する項を参照してください。
|
注意: デフォルトのファイルベースのポリシー・ストアは、デプロイ用および単一ノードのSpaces構成用のみに使用してください。エンタープライズ・デプロイメントでは、第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ベース、およびファイルベースのサービスに関する項を参照してください。アイデンティティ・ストア、ポリシー・ストアおよび資格証明ストアの再構成の詳細は、第30章「アイデンティティ・ストアの構成」および第31章「ポリシーおよび資格証明ストアの構成」を参照してください。
|
注意: WebCenter Portalのディスカッション・サービスはデフォルトで、組込みLDAPアイデンティティ・ストアを使用するように構成されています。組込みLDAPストア内のすべてのユーザーがディスカッション・サーバーにログオンできます。また、 アイデンティティ・ストアを外部LDAPサーバーに再度関連付けた場合、Fusion Middlewareの管理者アカウントを外部LDAPに移動するか(第30.4項「外部LDAPサーバーへの管理者アカウントの移行」を参照)、管理者アカウントを移動しない場合には、ディスカッション・サーバーの新しい管理者アカウントを識別するために追加の手順が必要になります(第30.4.1項「外部LDAPを使用するためのWebCenter Portalのディスカッション・サーバーの移行」を参照)。 Spacesに関しては、SpacesおよびContent Serverは同じLDAPサーバーを共有する必要があります。詳細は、第30.5項「Oracle Content ServerとSpacesでアイデンティティ・ストアLDAPサーバーを共有するための構成」を参照してください。 |
ADFセキュリティの権限モデルでは、権限ベースの認可およびロールベースの認可の両方がサポートされています。次の項では、この2つの認可タイプ、デフォルトのポリシー・ストア権限およびコードベース権限について説明します。
権限ベースの認可は、リストなど、Oracle Platform Security Services (OPSS)を使用してWebCenter Portalアプリケーション内にアクセス制御が実装されているサービスで使用されます。Spacesには、ユーザーおよびロール管理ツールが豊富に用意されています。これらのツールによってアプリケーション・ロールを作成し、そのロールに付与する必要がある権限を定義できます。Spacesでのユーザーおよびロールの管理の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal: Spacesユーザーズ・ガイド』のアプリケーション・ロールおよび権限の管理に関する項を参照してください。
リモート(バックエンド)リソースへのアクセスが必要なサービスでは、ロール・マッピングベースの認可が必須になります。たとえば、ディスカッション・サービスで、WebCenter Portalアプリケーションの(1つ以上のアプリケーション・ロールにマップされている)ユーザーをディスカッション・サーバーの別のロール・セットにマップする必要がある場合は、ロール・マッピングが必須です。
たとえば、Spacesアプリケーションでは次のようになります。
Spacesのロールは、バックエンドのディスカッション・サーバーの対応するロールにマップされます。
ユーザーに新しいSpacesスペース・ロールが付与されると、バックエンドのディスカッション・サーバーで同様の権限が付与されます。たとえば、ユーザーPatがSpacesでDiscussions-Create/Edit/Delete権限を付与された場合、バックエンドのディスカッション・サーバーで、対応する権限がPatに付与されます。
『Oracle Fusion Middleware Oracle WebCenter Portal: Spacesユーザーズ・ガイド』のディスカッション・サーバーのロールおよび権限マッピングの概要に関する項も参照してください。
Spacesには、初期設定で次のデフォルト・ロールが用意されています。
デフォルトのアプリケーション・ロール:
管理者
認証されたユーザー
パブリック・ユーザー
デフォルトのアプリケーション・ロールの詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal: Spacesユーザーズ・ガイド』のアプリケーション・ロールのデフォルトの権限に関する項を参照してください。
スペース内のデフォルトのロール
モデレータ
参加者
ビューア
スペース内のデフォルトのロールの詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal: Spacesユーザーズ・ガイド』のスペース内のロールに対するデフォルトの権限に関する項を参照してください。
WebCenter Portalアプリケーションは、権限チェックを使用して保護されたセキュリティ・プラットフォームでAPIを内部的にコールします。したがって、OPSSのAPIを呼び出すには、WebCenter Portalアプリケーションに適切な権限を付与する必要があります(たとえば、ポリシー・ストアにアクセスして権限を付与または取り消す(PolicyStoreAccessPermission)ための権限や、アプリケーション・ロールに基本的な権限を付与するための権限など)。Spacesでは、アプリケーション・ロールの基本的な権限はデフォルトで付与されています(『Oracle Fusion Middleware Oracle WebCenter Portal: Spacesユーザーズ・ガイド』のアプリケーション・ロールのデフォルトの権限に関する項を参照してください)。
同様に、WebCenter Portalアプリケーションでは、WebCenter Portalの権限を使用して公開する各種操作に対して事前にアクセスを認可しておき、OPSS APIを権限付きアクションとして呼び出す必要があります。
FrameworkアプリケーションまたはSpacesをデプロイした後で、次のセキュリティ関連の構成タスクをサイトに対して実行することを考慮します。
外部LDAPを使用するためのアイデンティティ・ストアの再関連付け
WebCenter Portalアプリケーションではデフォルトで、アイデンティティ・ストアに組込みLDAPが使用されます。事前に構成されている組込みLDAPは、セキュアではありますが、大規模なエンタープライズ本番環境には適さない場合があります。Oracle Internet Directory (OID)などの外部LDAPを使用するようにアイデンティティ・ストアを構成する方法の詳細は、第30章「アイデンティティ・ストアの構成」を参照してください。
|
注意: Oracle WebCenter Portalのディスカッション・サーバーはデフォルトで、組込みLDAPアイデンティティ・ストアを使用するように構成されています。組込みLDAPストア内のすべてのユーザーがディスカッション・サーバーにログオンできます。また、 アイデンティティ・ストアを外部LDAPサーバーに再度関連付けた場合、Fusion Middlewareの管理者アカウントを外部LDAPに移動するか(第30.4項「外部LDAPサーバーへの管理者アカウントの移行」を参照)、管理者アカウントを移動しない場合には、ディスカッション・サーバーの新しい管理者アカウントを識別するために追加の手順が必要になります(第30.4.1項「外部LDAPを使用するためのWebCenter Portalのディスカッション・サーバーの移行」を参照)。 Spacesに関しては、SpacesおよびContent Serverは同じLDAPサーバーを共有する必要があります。詳細は、第30.5項「Oracle Content ServerとSpacesでアイデンティティ・ストアLDAPサーバーを共有するための構成」を参照してください。 |
外部LDAPまたはデータベースを使用するためのポリシー・ストアの再関連付け
Frameworkアプリケーションではデフォルトで、ポリシー権限を格納するためにファイルベースのsystem-jazn-data.xmlポリシー・ストアが使用されます。LDAPベースまたはデータベースのポリシー・ストアを使用することを考慮する必要があります。LDAPサーバーまたはデータベースを使用するようにポリシー・ストアを構成する方法の詳細は、第31章「ポリシーおよび資格証明ストアの構成」を参照してください。
WS-Securityの構成
WS-Securityを使用すると、Frameworkアプリケーションおよびそれを使用する一連のプロデューサの構成や管理が複雑になりますが、Frameworkアプリケーションで公開される情報のセキュリティを確保する上で役立ちます。WS-Securityを追加すると、コンシューマの認証およびメッセージレベルのセキュリティを使用できるようになります。
Frameworkアプリケーションおよびコンポーネントに対してWS-Securityを構成する方法の詳細は、第35章「WS-Securityの構成」を参照してください。
SSOの構成
シングル・サインオン(SSO)を使用すると、ユーザーはサブアプリケーションごとにログインするのではなく(Spaces内のwikiページにアクセスする場合など)、WebCenter Portalアプリケーションおよびコンポーネント全体で1回ログインするだけで済みます。ユーザーは、アクセスするアプリケーションまたはコンポーネントごとに別個のユーザーIDおよびパスワードを保持する必要がありません。ただし、より厳密な方式を使用して機密性の高いアプリケーションを保護できるように、多様な認証方式を構成することもできます。WebCenter Portalでは、4つのシングル・サインオン・ソリューション(Oracle Access Manager (OAM)、Oracle Single Sign-on (OSSO)、Oracle WebCenter Portalアプリケーション専用のSAMLベースのシングル・サインオン・ソリューション、およびSimple and Protected Negotiate (SPNEGO)メカニズムとKerberosプロトコルに基づいたWindows認証による、Microsoftクライアント用SSOソリューション)がサポートされています。これらのソリューションの説明およびシングル・サインオンの概要については、第32章「シングル・サインオンの構成」を参照してください。
SSLの構成
Secure Sockets Layer (SSL)は、WebCenter Portalアプリケーションまたはコンポーネントの間の接続に対して追加の認証レイヤーを提供し、交換されるデータを暗号化することにより、接続セキュリティを強化するものです。データ交換が機密的なアプリケーションまたはコンポーネント間の接続では、SSLを使用して接続を保護することを考慮してください。本番環境でSSLを使用して保護できる、または保護する必要のある接続のリストは、第34章「SSLの構成」を参照してください。
|
注意: SSLを使用すると、計算が集中的に行われ、接続のオーバーヘッドが増加します。このため、SSLは必要でないかぎりは使用しないでください。SSLは本番環境まで保留しておくことをお薦めします。 |
この項の内容は次のとおりです。
問題
外部LDAPプロバイダを使用してWeblogic Serverを構成しました。外部LDAPのユーザーはSpacesにログインできますが、Spacesで外部LDAPのユーザーに管理者ロールを割り当てようとすると、ユーザーが一人も見つかりません。
解決策
第30章「アイデンティティ・ストアの構成」の手順に従って、DefaultAuthenticator認証プロバイダの制御フラグをSufficientに変更します。ドメインの管理サーバーと管理対象サーバーを再起動します。
問題
OIDユーザー(orcladminなど)としてSpacesにログインしている場合にスペースを作成しようとすると、スペースは作成されますがエラーが発生します。エラー・メッセージには「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サーバーを再起動します。
問題
Spacesで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エラーが発生したため、デバッグ・ロギングを有効化(第32.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アイデンティティ・アサータに適切な証明書が登録されていない可能性があります。SpacesドメインにSAML SSOを設定したときにcertAliasおよびcertPasswordで指定した証明書をエクスポートして、宛先ドメインでアクセス可能な場所にコピーします。
Spacesドメインのwcsamlsso.propertiesファイルで関連する構成セクションを更新します(たとえば、SOA構成で証明書が無効の場合は、soa_configセクションのcertPathを更新します)。
WebLogic Server管理コンソールを開いて、WC_Spacesドメインから「セキュリティ・レルム」→「プロバイダ」→「資格証明マッピング」→「wcsamlcm」→「管理」→「リライイング・パーティ」に移動し、ドメインに関連するリライイング・パーティ(たとえば、SOAの場合は、ワークリスト統合、ワークリスト詳細およびワークリストSDPになります)を削除します。
「宛先ドメイン」→「セキュリティ・レルム」→「プロバイダ」→「認証」→「wcsamlia」→「管理」→「アサーティング・パーティ」に移動し、対応するアサーティング・パーティを削除します。
「証明書」タブを開き、証明書も削除します。
Spacesドメインに戻り、アサーティング・パーティとリライイング・パーティの組合せを作成するためスクリプトを再実行します。たとえば、SOAの場合は、次のように再実行する必要があります。
$WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistIntegration.py $WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistDetail.py $WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistSDP.py
構成を再度テストします。すべて問題なく機能すれば、SAMLロギングを無効化できます。
