| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理 12c (12.2.1.3.0) E90347-06 |
|
 前 |
 次 |
この章の内容は次のとおりです:
Oracle Identity Cloud Integratorプロバイダでは、認証とアイデンティティ・アサーションを組み合せて単一のプロバイダにしています。このプロバイダは、アイデンティティ・ストアがOracle Identity Cloud Serviceである場合、認証ユーザー、ユーザーのグループおよびユーザーのアプリケーション・ロールを使用してアイデンティティ(サブジェクト)をWebLogic Serverに対して確立します。
Oracle Identity Cloud Serviceでは、オンプレミス、クラウド内またはモバイル・デバイスで、アプリケーションにアイデンティティ管理、シングル・サインオンおよびアイデンティティ・ガバナンスを提供します。カスタム・アプリケーションの認可にOAuth 2.0を利用する他、フェデレーテッド・シングル・サインオンを使用した認証の外部化にOpenID接続を利用します。Oracle Identity Cloud Serviceの詳細は、http://docs.oracle.com/en/cloud/paas/identity-cloud/index.htmlを参照してください。
次の各項で説明するように、Oracle Identity Cloud IntegratorプロバイダはOracle Identity Cloud Serviceとともに使用できます。
Basic認証
Basic認証では、サーバーはクライアントからのユーザー名とパスワードを要求し、Oracle Identity Cloud Serviceの認可ユーザーと比較することで、そのユーザー名とパスワードが有効であることを検証します。Basic認証を使用すると、Oracle Identity Cloud Serviceテナント内のユーザーは、WebLogic Server管理コンソールにログインしたり、WebLogic Scripting Tool (WLST)を使用したり、WebLogic Serverで実行されているアプリケーションにログインできます。
プロバイダでは、アイデンティティ・ドメインがサポートされており、これはユーザーおよびグループのテナンシを表すのに使用されます。テナントという用語は、アイデンティティ・ドメインの同義語です(アイデンティティ・ドメインは、マルチテナント・システムの1つのテナントを表します)。Oracle Identity Cloud Integratorプロバイダでは、任意のアイデンティティ・ドメインでユーザーを認証できます。プロバイダでは、「任意のアイデンティティ・ドメインの有効化」属性は常にtrueに設定されています。アイデンティティ・ドメインの詳細は、『WebLogic Server Multitenantの使用』の「セキュリティの構成」を参照してください。
境界認証
境界認証は、アプリケーション・サーバー・ドメインの外側にいるリモート・ユーザーのIDを認証するプロセスです。境界認証は通常、アサートされたアイデンティティおよびある種の対応する証明データを指定してリモート・ユーザーによって実行されますが、シングル・サインオンの概念が境界まで拡張されます。Oracle Identity Cloud Integratorプロバイダでは、次の境界認証メカニズムを使用してOracle Identity Cloud Serviceで認証されたユーザーからの境界認証がサポートされます。
Oracle Identity Cloud Serviceで作成されたOpenID接続アイデンティティ(ID)のトークン。アイデンティティ・アサーション・プロバイダでは、Oracle Identity Cloud Serviceのアイデンティティ・トークンのidcs_user_assertion HTTPヘッダーをデフォルトで処理します。ユーザー・アサーション(IDトークン)は、Oracle Identity Cloud Serviceによって認証されたユーザーを表し、ユーザー、グループおよびOracle Identity Cloud Serviceアプリケーション・ロール情報とともにプリンシパルが含まれるWebLogic Serverサブジェクトへのマップに使用されます。
この機能には、新しいIDCSAppRoleプリンシパルが組み込まれています。詳細は、Oracle WebLogic Server Java APIリファレンスのweblogic.security.principalに関する項を参照してください。
また、ロール・マッピングおよび認可ポリシーで使用できる新しいweblogic.entitlement.rules.IDCSAppRoleName ()述部が追加されました。
Oracle Identity Cloud Serviceで保護されるリソースのREMOTE_USER HTTPヘッダー。REMOTE_USERヘッダーでは、HTTP Basicヘッダーを使用してOracle Identity Cloud Serviceポリシー保護によって検証された後、REMOTE_USER HTTPヘッダーを使用してサーバーに送信されたユーザーを処理します。
HTTPヘッダーを使用してREMOTE_USERを設定する他に、Oracle Identity Cloud Serviceでは、HTTPヘッダーを使用してユーザー・テナンシも指定します。
Oracle Identity Cloud Serviceで匿名ユーザーによるサービスへのアクセスが指定されると、WebLogic Serverでは保護されたJava EEリソースへのアクセスが拒否されます。
保護リソースに対するOracle Identity Cloud Serviceのアクセス・トークン。アクセス・トークンは、OAuthクライアンによる保護リソースへのアクセスを可能にし、トークンに基づいてユーザー、グループ、Identity Cloud Serviceアプリケーション・ロール、スコープおよびオーディエンス情報を使用してプリンシパルが含まれるWebLogic Serverサブジェクトにマップする場合に使用される資格証明です。プロバイダでは、「認可」トークン・タイプを使用したトークンへのアクセスがサポートされており、Authorization HTTPヘッダーからアクセス・トークンが取得されます。
この機能には、サブジェクトにクライアント情報とスコープ情報を格納できるように、2つの新しいプリンシパルIDCSScopeおよびIDCSClientが組み込まれています。Oracle Identity Cloud Serviceオーディエンス(IDCSAudience)は、必要に応じてサブジェクトのパブリック資格証明に格納されます。詳細は、Oracle WebLogic Server Java APIリファレンスのweblogic.security.principalに関する項およびClass IDCSAudienceに関する項を参照してください。
ロール・マッピングおよび認可ポリシーで使用できる新しいweblogic.entitlement.rules.Scope ()述部が追加されました。
REMOTE_USER HTTPヘッダーおよびAuthorization HTTPヘッダーは、デフォルトでは有効になっていません。REMOTE_USERヘッダーは信頼性のあるクライアントによってのみ送信される必要があるため、このヘッダーはデフォルトでは有効になっていません。Oracle Identity Cloud IntegratorプロバイダでREMOTE_USERが有効になっている場合、パブリックにアクセス可能なエンドポイントを保持できません。パブリック・エンドポイントと保護エンドポイントの両方を公開している場合、REMOTE_USERを使用すると、アプリケーションおよびWebLogic Serverがセキュリティ脆弱性にさらされたままとなる可能性があります。アクセス・トークンからユーザー情報を安全に受け入れるには、Oracle Identity Cloud Serviceによってサービスを保護する必要があるので、Authorization HTTPヘッダーはデフォルトでは有効になっていません。
必要があれば、WebLogic Server管理コンソールでプロバイダの「共通」ページの「アクティブなタイプ」設定を使用するか、またはWLSTを使用して、Authorization HTTPヘッダーおよびREMOTE_USER HTTPヘッダーを有効にする必要があります。「AuthorizationヘッダーおよびREMOTE_USERヘッダーのサポートの有効化: 主なステップ」を参照してください。
アクセス・トークン処理を制御するために、さらにAudienceEnabledやClientAsUserPrincipalEnabledなどの構成属性およびアクセス・トークン要求属性を「プロバイダ固有」ページで設定するか、MBeanで直接設定することができます。これらの属性の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのOracle Identity Cloud Integratorプロバイダ: プロバイダ固有に関する項を参照してください。
プログラムによるアイデンティティ・アサーション
Oracle Identity Cloud Integratorプロバイダは、Oracle Identity Cloud Serviceから取得されたOpenID接続IDトークンからのプログラムによるアサーションに使用できます。このシナリオでは、アプリケーション・ロジックはOAuthプロトコル(認可コード付与フローなど)を実装してOracle Identity Cloud ServiceからIDトークンを取得します。IDトークンを取得すると、アプリケーション・ロジックでは、WebLogic Server認証APIを使用してOracle Identity Cloud Serviceユーザー・アイデンティティをIDトークンからアサートします。次の仕様およびAPIリファレンス・ドキュメントを参照してください。
Oracle WebLogic Server Java APIリファレンスのweblogic.security.services.Authenticationに関する項
さらに、プロバイダは、Oracle Platform Security Services (OPSS)、Oracle Web Services Manager (OWSM)またはSSOメカニズム(SAML2.0など)の使用時にOracle Identity Cloud Serviceユーザーの検証に使用できます。
複数のアイデンティティ・ストア環境
Oracle Identity Cloud Integratorプロバイダを使用して、ユーザーの単一ソースとしてまたは他のアイデンティティ・ストアと組み合せたハイブリッド環境でOracle Identity Cloud Serviceにアクセスできます。WebLogicセキュリティ・フレームワークの一部として、Oracle Identity Cloud Integratorプロバイダを他の認証プロバイダとともにセキュリティ・レルムで構成できるため、各プロバイダではそれぞれのアイデンティティ・ストア内のユーザーを認証できます。たとえば、組込みLDAPサーバーのユーザーを認証するようにデフォルトの認証プロバイダを構成し、Oracle Identity Cloud Serviceのユーザーを認証するようにOracle Identity Cloud Integratorを構成することができます。複数の認証プロバイダを構成する場合、各認証プロバイダのJAAS制御フラグを使用して、ログイン・シーケンスにおける認証プロバイダの使用方法を制御します。 「複数の認証プロバイダの使用」を参照してください。
Oracle Identity Cloud Integratorプロバイダは、セキュリティ・レルム内で構成されている唯一の認証プロバイダである場合、Oracle Identity Cloud ServiceユーザーはWebLogic Serverを起動できます。そのためには、Oracle Identity Cloud Serviceユーザーをグループに追加するか、WebLogic ServerのAdminロールに割り当てられているロールを付与する必要があります。そうでない場合、WebLogic Serverは起動できません。Oracle Identity Cloud IntegratorプロバイダがOracle Identity Cloud Serviceへの接続に失敗するか、例外をスローする場合、構成設定がこのプロバイダに対して正しく設定されていることを確認します。
さらに、SAML 2.0を使用するなど、シングル・サインオン構成を設定している場合は、Oracle Identity Cloud Integratorプロバイダをユーザーを検証するための認証プロバイダとして構成できます。SAMLを使用したWebブラウザとHTTPクライアントによるシングル・サインオンの構成を参照してください。
Oracle Identity Cloud Serviceのシングル・サインオン(SSO)およびログアウトの同期
Basic認証、境界認証またはプログラムによる認証のメカニズムを使用してアイデンティティを確立している場合、プロバイダにはOracle Identity Cloud Service SSOセッションをローカル・コンテナ・セッションと同期するためのSSO同期フィルタが組み込まれています。SSO同期フィルタは、サーブレット・フィルタの実装です。このフィルタは、コンテナに対する各リクエストをインターセプトし、リクエストの一部である特定のHTTPヘッダーに基づいてリクエストを処理するかどうかを判別します。フィルタの役割は、コンテナのユーザー・アイデンティティ(テナントおよびユーザー名)がSSOセッションのアイデンティティと一致していることを確認することです。アイデンティティが一致した場合、セッションは続行します。アイデンティティに不一致がある(ユーザーがログアウトしていたり、セッションがタイムアウトしているなど)場合、フィルタはコンテナのユーザー・セッションを無効にし、続行するためにリダイレクトを実行します。
同期フィルタは、デフォルトで有効になっています。必要な場合は、WebLogic Server管理コンソールの「プロバイダ固有」ページの「同期フィルタ」セクションで設定を調整するか、MBeanで設定できます。これらの属性の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのOracle Identity Cloud Integratorプロバイダ: プロバイダ固有に関する項を参照してください。
WebLogic ServerでOracle Identity Cloud Serviceによるユーザー認証を行うには、Oracle Identity Cloud IntegratorプロバイダをOracle Identity Cloud Serviceに登録されているOAuthクライアントに関連付ける必要があります。OAuthクライアントにより、Oracle Identity Cloud Serviceへのプロバイダ・アクセスが可能になります。
プロバイダを構成するには、必要なOAuthクライアント情報をOracle Identity Cloud Serviceから取得する必要があります。そのためには、Oracle Identity Cloud Serviceコンソールで信頼できるアプリケーションを作成します。Oracle Identity Cloud Serviceでの信頼できるアプリケーションとは一種のカスタム・アプリケーションで、複数のユーザーがアクセスでき、信頼できるアプリケーションでOAuth 2.0が使用されるセキュアな保護された場所(サーバー)でホスト管理されます。アプリケーションがホスト管理される場所をユーザーが認識しているため、そのアプリケーションを信頼性があるとして扱うことができます。Oracle Identity Cloud Serviceでアプリケーションを作成すると、OAuthクライアントのプロビジョニングが行われます。
OAuthクライアントの作成: 主なステップ
Identity Cloud ServiceコンソールでOAuthクライアントを作成するには:
Identity Cloud Serviceコンソールにテナント管理者としてログインします。
信頼できるアプリケーションを作成します。Oracle Identity Cloud Serviceの管理の信頼できるアプリケーションの追加に関する項を参照してください。
OAuthクライアントは、プロビジョニングされた特定のテナント内でのみ使用できることに注意してください。
信頼できるアプリケーションの追加ウィザードで次のようにします。
クライアント名と、オプションで説明を入力します。
使用可能な権限付与タイプとして、「クライアント資格証明」のみを選択します。この設定は、認可スコープがクライアントの制御下にある保護リソースまたは認可サーバーに登録されている保護リソースに制限されている場合に使用されます。クライアントは、独自の資格証明を提示してアクセス・トークンを取得します。
クライアントを「アイデンティティ・ドメイン管理者」アプリケーション・ロールに割り当てます。そのためには、「Identity Cloud Service管理APIへのクライアント・アクセス権を付与します。」を選択し、表示されるボックスで「アイデンティティ・ドメイン管理者」を選択します。
「アイデンティティ・ドメイン管理者」アプリケーション・ロールを使用すると、Oracle Identity Cloud Serviceユーザー・ストアへの書込み権限が提供されます。WebLogic ServerのOracle Identity Cloud Integratorプロバイダでは、更新操作は一切サポートされません。したがって、Identity Cloud Service管理コンソールを使用してユーザー・ストアの内容を変更する必要があります。
ウィザードの残りのページを通って「終了」をクリックします。アプリケーションの作成時に表示されるクライアントIDおよびクライアント・シークレットを記録します。これらの値は、Oracle Identity Cloud Integratorプロバイダを構成する際に必要です。プロバイダの構成時に指定する必要がある属性の詳細は、「必要な構成属性」を参照してください。
アプリケーションをアクティブにします。
必要な構成属性
WebLogic ServerでOracle Identity Cloud Integratorプロバイダを構成するには、OAuthクライアントの次の属性を指定する必要があります。
テナント — OAuthクライアントをプロビジョニングしたOracle Identity Cloud Serviceのプライマリ・テナントの名前。
ClientId — Oracle Identity Cloud Serviceアイデンティティ・ストアへのアクセスに使用するOAuthクライアントID。
ClientSecret — アクセス・トークンの生成に使用するOAuthクライアント・シークレット(パスワード)。
クライアント・テナント(オプション) — クライアントIDが存在するOAuthクライアント・テナントの名前。この属性は、クライアント・テナントがプライマリ・テナントと同じ場合、必要ありません。
接続の構成に必要な属性の詳細は、「Oracle Identity Cloud Integratorプロバイダを構成するための前提条件」を参照してください。Oracle Identity Cloud ServiceにアクセスできるOracle Identity Cloud Serviceのホストおよびポートも指定する必要があります。ホストのこの値は、Identity Cloud ServiceのテナントURLのベース名(identity.host.comなど)であり、テナント名は含まれません。TLS/SSLが有効である場合、必ずセキュアなポートを使用してください。
プロバイダの追加構成属性の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのOracle Identity Cloud Integratorプロバイダ: プロバイダ固有に関する項を参照してください。
WebLogic Server管理コンソールを使用したプロバイダの構成の主なステップは次のとおりです。
「セキュリティ・レルム」→「realm-name」→「プロバイダ」→「認証」を選択し、「新規」を選択します。
「新しい認証プロバイダの作成」ページで、プロバイダの名前を入力して、「タイプ」メニューから「OracleIdentityCloudIntegrator」を選択し、「OK」をクリックします。
プロバイダ、「プロバイダ固有」ページの順に選択し、Oracle Identity Cloud Serviceへの接続に必要な属性を構成します。
TLS/SSLが必要な場合は、「SSLの有効化」を選択します。
「保存」をクリックします。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのOracle Identity Cloud Integratorプロバイダの構成に関する項を参照してください。
Oracle Identity Cloud Integratorプロバイダの構成: WLSTオンラインの例
プロバイダをセキュリティ・レルムに追加し、Oracle Identity Cloud Serviceへの接続を構成するスクリプトを作成して実行することで、WLSTオンラインをスクリプト・モードで使用してOracle Identity Cloud Integratorプロバイダを構成できます。
そのためには、例20-1に示すサンプル・スクリプトIdentityCloudIntegrator.pyのようなWLSTスクリプトを作成します。
スクリプトの必要な変数idcsHost、idcsPort、clientTenant、clientIDおよびclientSecretを、使用している環境に適した値で置き換えます。スクリプトのconnectコマンドでは、username、passwordおよびhost:portをプロバイダの追加先となるドメイン内のサーバーの値で置き換えます。『WebLogic Scripting Toolの理解』の「WebLogic Scripting Toolの使用」の説明に従ってスクリプトを実行します
このスクリプトにより、WLSTオンラインが起動し、プロバイダがセキュリティ・レルムに追加され、プロバイダ構成およびJAAS制御フラグが設定され、変更がアクティブなります。
ドメインの更新後に、サーバーを再起動する必要があります。
例20-1 IdentityCloudIntegrator.py WLSTサンプル・スクリプト
ノート:
明確にするために、このWLSTサンプル・スクリプトでは、ユーザー名およびパスワードをクリア・テキストで表示しています。通常はWLSTコマンドにクリア・テキストのパスワードを入力しないでください。特に、クリア・テキストのパスワードが含まれるWLSTスクリプトをディスクに保存することは避けてください。このような状況では、暗号化されたパスワードを渡すメカニズムをかわりに使用する必要があります。#
# Use appropriate Oracle Identity Cloud Service host, port, client tenant, client Id, and client secret.
#
idcsHost="identity.host.com"
idcsPort=443
clientTenant="myTenant"
clientId="123456789"
clientSecret="987654321"
#
# Start WLST edit session
#
connect("username","password","t3://host:port")
edit()
startEdit()
#
# Add the Oracle Identity Cloud Integrator provider to the security realm configuration where the Default
# Authenticator is the only existing authentication provider.
#
realm = cmo.getSecurityConfiguration().getDefaultRealm()
atn = realm.lookupAuthenticationProvider('IdentityCloudServiceIntegrator')
if atn == None:
atn = realm.createAuthenticationProvider('IdentityCloudServiceIntegrator','weblogic.security.providers.authentication.OracleIdentityCloudIntegrator')
#
# Setup the Oracle Identity Cloud Integrator provider configuration
#
atn.setHost(idcsHost)
# Example host requires SSL. Comment out next line if using an Oracle Identity Cloud Service instance that does not require SSL.
atn.setSSLEnabled(true)
atn.setPort(idcsPort)
atn.setTenant(clientTenant)
# If the Client Tenant == Tenant then no need to set the Client Tenant value
atn.setClientTenant(clientTenant)
atn.setClientId(clientId)
atn.setClientSecret(clientSecret)
atn.setControlFlag('SUFFICIENT')
#
# Adjust the JAAS control flag for the DefaultAuthenticator such that users from the embedded LDAP server or the
# Oracle Identity Cloud Service are allowed to log into WebLogic Server.
#
atnDefault = realm.lookupAuthenticationProvider('DefaultAuthenticator')
if atnDefault != None:
atnDefault.setControlFlag('SUFFICIENT')
#
# Activate changes
#
activate()
exit()
#
# Restart WebLogic Server
#
Oracle Identity Cloud Integratorプロバイダの構成: WLSTオフラインの例
プロバイダをセキュリティ・レルムに追加し、Oracle Identity Cloud Serviceへの接続を構成する一連のコマンドを実行することで、WLSTオフラインを使用してOracle Identity Cloud Integratorプロバイダを構成できます。
WLSTオフラインの使用の詳細は、『WebLogic Scripting Toolの理解』のWLSTオフラインを使用した既存のWebLogicドメインの更新に関する項を参照してください。
これらのコマンドを実行すると、ドメインが次のように編集されます。
編集するためにドメイン構成を開きます。必ず変数domainDirNameおよびDOMAIN_NAMEを、使用している環境に適した値で置き換えてください。たとえば、ドメインの作成時にデフォルト値を受け入れた場合、domainDirNameはORACLE_HOME/user_projects/domains/base_domainとなり、DOMAIN_NAMEはbase_domainとなります。また、必ずセキュリティ・レルムの実際の名前を指定してください。この例では、myrealmを使用しています。
Oracle Identity Cloud Integratorプロバイダをデフォルトの認証プロバイダが唯一の既存の認証プロバイダであるセキュリティ・レルム構成に追加します
idcsHost、idcsPort、clientTenant、clientIDおよびclientSecretに指定する値を使用して、Oracle Identity Cloud Serviceへの接続を構成します。
組込みLDAPサーバーまたはOracle Identity Cloud ServiceからのユーザーがWebLogic Serverにログインできるように、DefaultAuthenticatorのJAAS制御フラグを調整します。
ドメインを更新して閉じ、WLSTオフラインを終了します。
例20-2 Oracle Identity Cloud Integratorプロバイダを構成するWLSTオフラインのコマンド
readDomain('domainDirName')
cd('SecurityConfiguration/DOMAIN_NAME/Realm/myrealm')
create('IdentityCloudServiceIntegrator','weblogic.security.providers.authentication.OracleIdentityCloudIntegrator','AuthenticationProvider')
cd('AuthenticationProviders/IdentityCloudServiceIntegrator')
# Execute the set commands needed to configure the Oracle Identity Cloud Integrator provider host, port, tenant,
# client tenant, client id, client secret and JAAS control flag.
idcsHost="identity.host.com"
idcsPort=443
clientTenant="myTenant"
clientId="123456789"
clientSecret="987654321"
# Set attributes
set("Host",idcsHost)
set("SSLEnabled", true)
set("Port", idcsPort)
set("Tenant", clientTenant)
set("ClientTenant", clientTenant)
set("ClientId", clientId)
set("ClientSecretEncrypted", clientSecret)
set("ControlFlag", "SUFFICIENT")
# Set any other authenticators to SUFFICIENT. In this example, set the JAAS control flag for the DefaultAuthenticator
# such that users from the embedded LDAP server or the Oracle Identity Cloud Service are allowed to log into WebLogic Server.
cd("..")
cd("DefaultAuthenticator")
set("ControlFlag", "SUFFICIENT")
updateDomain()
closeDomain()
exit()
Oracle Identity Cloud Integratorプロバイダでは、一方向SSLがサポートされています。TLS/SSLを使用して接続を保護するには、WebLogic ServerとOracle Identity Cloud Service間の信頼を確立する必要があります。そのためには、Oracle Identity Cloud ServiceのSSL証明書を取得してWebLogic Serverの信頼ストアにインポートする必要があります。
ノート:
Oracle Identity Cloud ServiceでSymantecなどのよく知られている認証局(CA)を使用し、WebLogicドメインでJava標準信頼を使用している場合、WebLogic Serverではデフォルトでそれを信頼するため、証明書のインポートは必要ありません。しかし、ドメインがカスタム信頼用に構成されている場合は、Oracle Identity Cloud Serviceでよく知られているCAを使用しているかどうかに関係なく、証明書を信頼ストアにインポートする必要があります。WebLogic Serverに対してFIPSを有効にするときに、Oracle Identity Cloud Integratorプロバイダが構成されている場合、Java SSLコンテキストの初期化例外が発生したり、Oracle Identity Cloud Serviceのユーザーが認証に失敗したりする可能性があります。これらの問題は、CA証明書ストアであるcacertsがFIPSに準拠していない場合にシステムでデフォルトのJavaシステムのトラスト・ストアを使用した結果である可能性があります。
JDKデバッグを有効にすると(-Djavax.net.debug=ssl)、例外のエラー・メッセージが次のようになります。
Default SSLContext initialization Key Store: Key Store type: jks Initializing key managers Exception while initializing default context JKS keystores cannot be loaded in FIPS-140 mode. Only PKCS12 PBES2 key stores are supported
FIPSに準拠していないPKCS12キーストア(たとえば、Sun JSSEプロバイダを使用してkeytoolコマンドで作成されたもの)を使用する場合、keytoolコマンドの使用時に次のようなエラーも発生する可能性があります。
keytool error: java.lang.SecurityException: Algorithm not allowable in FIPS140 mode: PBE/PKCS12/SHA1/RC2/CBC/40
これらエラーに対処し、WebLogic Serverが正常に動作するようにするには、最初にJDKキーストアをFIPS準拠のPKCS12キーストアに変換してから、Javaシステムのプロパティを設定し、デフォルトのSSLコンテキストとともに使用されるトラスト・ストアのJavaのデフォルト設定を更新する必要があります。詳細は、「FIPSに準拠するためのデフォルトのJKSキーストアの変換」を参照してください。
Oracle Identity Cloud Integratorプロバイダでは、Authorization HTTPヘッダーを介したOracle Identity Cloud Serviceアクセス・トークンと、REMOTE_USER HTTPヘッダーを介してOracle Identity Cloud Serviceによって検証されたユーザーがサポートされています。
ここでは、次の項目について説明します。
Authorization HTTPヘッダーおよびREMOTE_USER HTTPヘッダーは、デフォルトでは有効になっていません。サービスは、アクセス・トークンおよび証明または署名のデータが含まれていないHTTPヘッダーからユーザー情報を安全に受け入れるために、Oracle Identity Cloud Serviceによって保護する必要があります。したがって、これらのヘッダーを受け入れるには、それらのサポートを有効にする必要があります。
ノート:
REMOTE_USER HTTPヘッダーを有効にする前に注意してください。このヘッダーは、信頼性のあるクライアントによってのみ送信される必要があります。Oracle Identity Cloud IntegratorプロバイダでREMOTE_USERが有効になっている場合、パブリックにアクセス可能なエンドポイントを保持できません。パブリック・エンドポイントと保護エンドポイントの両方を公開している場合、REMOTE_USERを使用すると、アプリケーションおよびWebLogic Serverがセキュリティ脆弱性にさらされたままとなる可能性があります。Oracle Identity Cloud Serviceアイデンティティ・トークンidcs_user_assertionおよびIdcs_user_assertionのアクティブなタイプのみがデフォルトで受け入れられます。Authorization HTTPヘッダーおよびREMOTE_USER HTTPヘッダーのサポートを有効にするには:
プロバイダの「共通」ページの「アクティブなタイプ」設定を使用するか、この例に示すようにWLSTを使用して、WebLogic Server管理コンソールでAuthorizationヘッダーまたはREMOTE_USERヘッダー(あるいはその両方)を有効にします。これらのヘッダーは、使用している環境の必要に応じて個別に有効にできます。
connect("username", "password", "t3://host:port")
edit()
startEdit()
realm = cmo.getSecurityConfiguration().getDefaultRealm()
atn = realm.lookupAuthenticationProvider('IdentityCloudServiceIntegrator')
atn.setActiveTypes(["idcs_user_assertion","REMOTE_USER","Authorization"])
activate()
disconnect()
exit()
#
# Restart WebLogic Server
#
複数のトークン・タイプに対して処理順序を確実に定義するには、RealmMBeanで優先順位を設定して、様々なHTTPヘッダーの順序を指定します。「アイデンティティ・アサーションのヘッダーの順序付け」を参照してください。
WebLogic ServerコンテナによってHTTPリクエストが処理される際、アイデンティティ・アサーションに使用できる一致が複数存在することがあります。Oracle Identity Cloud Integratorプロバイダに渡されるヘッダーには、Oracle Identity Cloud Serviceアイデンティティ・トークン、Oracle Identity Cloud Serviceアクセス・トークンまたはREMOTE_USERが含まれます。ただし、プロバイダが一度に消費できるのは1つのアクティブなトークン・タイプのみです。つまり、一度の呼出しで一連のトークンを消費できる方法は提供されていません。したがって、WebLogic Serverコンテナでは、アイデンティティ・アサーションを実行するために複数のトークンから1つを選択する必要があります。
REMOTE_USERまたはAuthorizationのアクティブなタイプを有効にした場合は、RealmMBeanでIdentityAssertionHeaderNamePrecedenceプロパティも更新して様々なHTTPヘッダーの優先順位を設定する必要があります。それ以外の場合は、定義しません。
表20-1に、基本的なユースケースおよび各ケースでの優先順位付けの例をまとめます。
表20-1 様々なユースケースにおけるHTTPヘッダーの優先順位付け
| ユースケース | 優先順位 | 説明 |
|---|---|---|
HTTPリクエストには、すべてのサポートされるトークンまたはヘッダーが含まれることがあります |
Authorization: Bearer (アクセス・トークン) idcs_user_assertion (アイデンティティ・トークン) REMOTE_USER |
この順序を設定すると、まずIdentity Cloud Serviceトークンからの要求が優先されます。Identity Cloud Serviceトークンが指定されていない場合、認証はリモート・ユーザー情報のみを使用することになります。 Oracle Identity Cloud ServiceでBasic認証を処理して |
HTTPリクエストには、主にアクセス・トークンおよびWebシングル・サインオン(SSO)トークンを伴うHTTP Basic認証が含まれます |
Authorization: Bearer (アクセス・トークン) REMOTE_USER |
場合によっては、アクセス・トークンからのスコープなど、セキュリティ・コンテキストがさらに必要になることがあります。追加情報が必要な場合は、アクセス・トークンおよびアイデンティティ・トークンがリモート・ユーザー情報より優先されます。 この順序を設定すると、アクセス・トークンが優先され、アクセス・トークンからのユーザー、クライアント、アプリケーション・ロール、スコープおよびオーディエンス・データが含まれるセキュリティ・コンテキストが設定されます。Oracle Identity Cloud Serviceによって検証されたWeb SSOおよびHTTP Basic資格証明に対して、デプロイされたアプリケーションでは、ユーザーのIdentity Cloud Serviceアプリケーション・ロールを含め、セキュリティ・コンテキストに設定されたリモート・ユーザー情報が使用されます。 ノート: Oracle Identity Cloud Serviceアイデンティティ・トークンが含まれる場合、リモート・ユーザー情報は引き続き優先され、ユーザーのIdentity Cloud Serviceアプリケーション・ロールは引き続き取得されます。 |
HTTPリクエストには、複数のトークンが含まれることがありますが、リモート・ユーザーが優先されます |
REMOTE_USER |
サービスでリモート・ユーザー情報のみ使用する場合、リモート・ユーザーを最優先として設定すると、確実に ノート: <auth-methodCLIENT-CERT, BASIC</auth-methodを使用してアプリケーションの認証メカニズムを定義する場合、CLIENT-CERTがWebコンテナによって認証に使用される最初の方式であるため、リモート・ユーザー情報は引き続きAuthorization: Basic資格証明よりも優先されます。したがって、リモート・ユーザー情報(トークン)からのアサーションが失敗するか、トークン関連のHTTPヘッダーがHTTPリクエストから省略されている場合は、HTTP BASIC資格証明のみが処理されます。『WebLogicセキュリティ・サービスによるアプリケーションの開発』の認証方式に対するフォールバック・メカニズムの提供に関する項を参照してください。 |
HTTPヘッダーの優先順位の設定: WLSTの例
ここで示すように、WLSTオンラインを使用してHTTPトークンの優先順位を設定できます。この例では、1つ目のユースケースに示すように、認可(アクセス・トークン)、アイデンティティ・トークン、リモート・ユーザーの順に順位付けを設定します。
connect("username", "password", "t3://host:port")
edit()
startEdit()
realm = cmo.getSecurityConfiguration().getDefaultRealm()
realm.setIdentityAssertionHeaderNamePrecedence(["Authorization: Bearer","idcs_user_assertion","REMOTE_USER"])
activate()
disconnect()
exit()
#
# It is not necessary to restart the server.
#
