Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの理解 11g リリース1(10.3.6) B61618-04 |
|
![]() 前 |
![]() 次 |
この節では、WebLogic Securityサービスのアーキテクチャについて説明します。アーキテクチャは、以下の節で説明する5つの主要なコンポーネントで構成されています。
図5-1に、WebLogic Securityフレームワークの概観を示します。フレームワークは、weblogic.security.service
パッケージのインタフェース、クラス、および例外で構成されます。
WebLogic Securityフレームワークの主な役割は、簡素化されたアプリケーション・プログラミング・インタフェース(API)を提供することです。APIは、セキュリティ・サービスを定義するセキュリティ開発者およびアプリケーション開発者によって使用されます。そのコンテキスト内でWebLogic Securityフレームワークは、WebLogicコンテナ(WebおよびEJB)、リソース・コンテナ、セキュリティ・プロバイダの間の仲介役としても機能します。
以下の節では、WebLogic Securityフレームワークを介したWebLogicコンテナ、リソース・コンテナ、各セキュリティ・プロバイダの間の対話について説明します。
図5-2に、ファット・クライアント・ログインの認証プロセスを示します。JAASはサーバー上で動作してログインを実行します。シン・クライアント・ログイン(Webブラウザ・クライアント)の場合でも、JAASはサーバー上で動作します。
注意: JAASプロセスを直接扱うのは、カスタム認証プロバイダの開発者だけです。クライアント・アプリケーションは、JNDI初期コンテキストまたはJAASのいずれかを使用してユーザー名とパスワードを受け渡します。 |
ユーザーがユーザー名とパスワードの組合せを使用してシステムにログインしようとすると、WebLogic Serverはそのユーザーのユーザー名とパスワードを検証することによって信頼を確立し、JAASの要件に従って、プリンシパルが格納されたサブジェクトを返します。図5-2で示されているとおり、このプロセスにはLoginModuleとプリンシパル検証プロバイダの使用が必要になります。プリンシパル検証プロバイダの詳細は、「WebLogicプリンシパル検証プロバイダ」を参照してください。
呼出し側のIDの確認に成功すると、認証コンテキストが確立され、IDが確認されたユーザーまたはシステムに関しては、そのコンテキストを通じて他のエンティティに対する認証を行うことができます。認証コンテキストはまた、アプリケーション・コンポーネントに委託することもでき、それによって、そのコンポーネントは別のアプリケーション・コンポーネントを呼び出しつつ、元の呼出し側として動作できるようになります。
IDアサーション・プロバイダは、境界認証プロセスの一部として使用されます。境界認証が使用される場合(図5-3を参照)、WebLogic Serverドメインの外部のトークンが、セキュリティ・レルム内の、そのタイプのトークンの検証を担当し、「アクティブ」として構成されているIDアサーション・プロバイダに渡されます。そのトークンの有効性が問題なく検証されれば、IDアサーション・プロバイダはそのトークンをWebLogic Serverユーザー名にマップし、そのユーザー名をWebLogic Serverに送り返します。その後WebLogic Serverでは、認証プロセスが続行されます。具体的には、ユーザー名がJAAS CallbackHandler
を通じて送信され、構成されている各認証プロバイダのLoginModuleに渡されるので、LoginModuleはサブジェクト内に適切なプリンシパルを格納できるようになります。
注意: X.501およびX.509証明書に対してWebLogic IDアサーション・プロバイダを使用するには、WebLogic Server製品に付属しているデフォルトのユーザー名マッパー(weblogic.security.providers.authentication. DefaultUserNameMapperImpl )を使用するか、または独自のweblogic.security.providers.authentication.UserNameMapper インタフェースの実装を使用するかのいずれかの方法があります。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「カスタムIDアサーション・プロバイダを開発する必要があるか」を参照してください。 |
図5-3でも示されているように、境界認証では認証プロセスと同じ構成要素が必要ですが、IDアサーション・プロバイダも追加されます。
図5-4に示すとおり、ユーザーはユーザー名とパスワードの組み合わせを使ってシステムにログインしようとします。WebLogic Serverは、構成済みの認証プロバイダのLoginModuleを呼び出すことによって信頼を確立します。LoginModuleは、ユーザーのユーザー名とパスワードを検証し、JAASの要件に従って、プリンシパルが格納されたサブジェクトを返します。
WebLogic Serverは、指定されたプリンシパル検証プロバイダにサブジェクトを渡します。プリンシパル検証プロバイダは、そのプリンシパルに署名して、それらをWebLogic Serverを通じてクライアント・アプリケーションに返します。他のセキュリティ操作のためにサブジェクト内のプリンシパルが必要になった場合、同じプリンシパル検証プロバイダが、そのプリンシパルが署名時から変更されていないかどうかを検証します。
図5-5に、認可プロセスにおける認可プロバイダ(および関連する裁決プロバイダとロール・マッピング・プロバイダ)とWebLogic Securityフレームワークとの対話を示します。
ユーザーまたはシステム・プロセスがWebLogicリソースをリクエストし、特定の操作を実行しようとすると、認可プロセスが開始されます。要求されたWebLogicリソースのタイプを処理するリソース・コンテナがリクエストを受け取ります。たとえばEJBコンテナはEJBリソースに対するリクエストを受け取ります。リソース・コンテナは、WebLogic Securityフレームワークを呼び出して、リクエストのサブジェクト、要求されているWebLogicリソースなどの情報を含むリクエスト・パラメータを渡します。WebLogic Securityフレームワークは、構成済みのロール・マッピング・プロバイダを呼び出して、ロール・マッピング・プロバイダが使用できる形式でリクエスト・パラメータを渡します。ロール・マッピング・プロバイダは、リクエスト・パラメータを使用して、要求側のサブジェクトが資格を有する一連のロールを計算し、該当するロールをWebLogic Securityフレームワークに渡します。認可プロバイダは、そのサブジェクトがWebLogicリソースに対してリクエストされたアクションを実行できる資格があるかどうかを判別します(つまり、アクセス決定を行います)。複数の認可プロバイダが構成されている場合には、WebLogic Securityフレームワークは、認可プロバイダから返されたアクセス決定に競合があった場合、その調停を裁決プロバイダに委託します。裁決プロバイダでは、認可判定の最終結果を決定します。
複数の認可プロバイダが構成されている場合(図5-5を参照)には、複数のアクセス決定を調停し、判定するための裁決プロバイダが必要になります。裁決プロバイダはTRUE
かFALSE
の判定を認可プロバイダに返し、認可プロバイダはその判定をWebLogic Securityフレームワークを通してリソース・コンテナに転送します。
判定がTRUE
の場合、リソース・コンテナはリクエストを保護ターゲットのWebLogicリソースにディスパッチします。
判定がFALSE
の場合、リソース・コンテナはセキュリティ例外をスローします。この例外は、リクエスト側にはリクエストしたアクセスを保護されたWebLogicリソースに対して行う権限がなかったことを示します。
WebLogic Securityフレームワークは、認可判定の一環として、セキュリティ・レルム用に構成されている各ロール・マッピング・プロバイダを呼び出します。関連情報については、「認可プロセス」を参照してください。
動的なロール関連付けを作成する場合のロール・マッピング・プロバイダとWebLogic Securityフレームワークとの対話を図5-6に示します。
ユーザーまたはシステム・プロセスがWebLogicリソースをリクエストし、特定の操作を実行しようとすると、ロール・マッピング・プロセスが開始されます。要求されたWebLogicリソースのタイプを処理するリソース・コンテナがリクエストを受け取ります。たとえばEJBコンテナはEJBリソースに対するリクエストを受け取ります。リソース・コンテナは、WebLogic Securityフレームワークを呼び出して、リクエストのサブジェクト、要求されているWebLogicリソースなどの情報を含むリクエスト・パラメータを渡します。WebLogic Securityフレームワークは、適用するロールのリストを取得するために、構成済みの各ロール・マッピング・プロバイダを呼び出します。要求側に特定のロールの資格があるとセキュリティ・ポリシーに指定されている場合には、そのロールがサブジェクトに適用されるロールのリストに追加されます。このプロセスは、WebLogicリソースまたはリソース・コンテナに適用されるセキュリティ・ポリシーがすべて評価されるまで続行されます。ロールのリストはWebLogic Securityフレームワークに返され、アクセス決定などの操作の一環として使用できるようになります。
ロール・マッピング・プロバイダによる動的ロール関連付けの結果、一連のロールが一度にサブジェクト内のプリンシパルに割り当てられます。その後、これらのロールを用いて、保護ターゲットWebLogicリソース、リソース・コンテナ、およびアプリケーション・コードについての認可判定が行われます。たとえば、Enterprise JavaBeans (EJB)であれば、アクセスを許可するかどうかを決めるビジネス・ポリシーを知らなくても、Java EEのisCallerInRole()
メソッドを用いてデータベース内のレコードからフィールドを取得することができます。
図5-7に、監査プロバイダがWebLogic Securityフレームワークと他のタイプのセキュリティ・プロバイダ(ここでは認証プロバイダ)と対話する仕組みを示します。
リソース・コンテナが、ログイン・リクエストの一部としてユーザーの認証情報(ユーザー名とパスワードの組合せなど)をWebLogic Securityフレームワークに渡すと、監査プロセスが開始されます。WebLogic Securityフレームワークは、ログイン・リクエストに関連付けられている情報を構成済みの認証プロバイダに渡します。認証プロバイダが認証サービスを提供するほかに監査イベントをポストする場合、認証プロバイダはAuditEvent
オブジェクトをインスタンス化します。AuditEvent
オブジェクトには、監査対象のイベント・タイプや監査の重大度レベルなどの情報が含まれます。その後、認証プロバイダはWebLogic Securityフレームワーク内の監査サービスを呼び出して、AuditEvent
オブジェクトを渡します。監査サービスは、AuditEvent
オブジェクトを構成済みの監査プロバイダの実行時クラスに渡し、監査イベントの記録を有効にします。監査プロバイダの実行時クラスは、AuditEvent
オブジェクトから取得した情報を使用して監査レコードの内容を管理します。AuditEvent
オブジェクト内に認証プロバイダによって指定された監査条件が満たされると、該当する監査プロバイダの実行時クラスは監査レコードを書き出します。監査プロバイダの実装によっては、監査記録をファイルやデータベースなどの永続ストレージ・メディアに書き込むことができます。
資格証明マッピング・プロセスにおける資格証明マッピング・プロバイダとWebLogic Securityフレームワークとの対話を図5-8に示します。
JavaServer Page (JSP)、サーブレット、Enterprise JavaBeans (EJB)、リソース・アダプタなどのアプリケーション・コンポーネントが、エンタープライズ情報システム(EIS) (たとえば、Oracle、SQL Serverなどのリレーショナル・データベース)にアクセスするために、適切なリソース・コンテナを通じてWebLogic Securityフレームワークを呼び出すと、資格証明マッピング・プロセスが開始されます。呼出しの中で、アプリケーション・コンポーネントは、サブジェクト(「誰が」リクエストしているのか)、WebLogicリソース(「何を」リクエストしているのか)、およびWebLogicリソースにアクセスするために必要な資格証明のタイプについての情報を渡します。WebLogic Securityフレームワークは、資格証明に対するアプリケーション・コンポーネントのリクエストを、アプリケーション・コンポーネントが必要としている資格証明のタイプを処理する構成済資格証明マッピング・プロバイダに送信します。資格証明マッピング・プロバイダは、そのデータベースを照会して、アプリケーション・コンポーネントがリクエストしているものに一致する資格証明群を取得し、WebLogic Securityフレームワークに資格証明を返します。WebLogic Securityフレームワークは、リソース・コンテナを通じてリクエスト側のアプリケーション・コンポーネントに資格証明を返します。アプリケーション・コンポーネントは、資格証明を使用して外部システムにアクセスします。
証明書の検索と検証のプロセスでは、証明書パス・ビルダー、証明書パス検証プロバイダ、証明書検索および検証(CLV)フレームワークの3つが対話します。
次に、証明書チェーンの作成プロセスを示します。
WebLogic Webサービスまたはアプリケーション・コードから、証明書チェーンと証明書パス・セレクタ(目的の証明書、サブジェクトDN、発行者DNとシリアル番号、およびサブジェクト・キー識別子のいずれか)がCLVフレームワークに渡されます。
証明書チェーンを検索して検証するため、CLVフレームワークが証明書パス・ビルダーを呼び出します。Webサービスを使用している場合は、CLVフレームワークが信頼性のあるCAのサーバーのリストをプロバイダに渡します。アプリケーション・コードは、信頼性のあるCAのリストをプロバイダに渡します。
証明書チェーンを検索および検証したら、CLVフレームワークがセキュリティ・レルムに構成されている証明書パス検証プロバイダを構成された順に呼び出します。
証明書パス・ビルダーと、構成されているすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。
CLVフレームワークが、リクエスト側に証明書チェーンを返します。
処理を続行します。
次に、証明書チェーンの検証プロセスを示します。
SSLプロトコル、WebLogic Webサービス、またはアプリケーション・コードから、証明書チェーンと証明書パス・セレクタ(目的の証明書、サブジェクトDN、発行者DNとシリアル番号、およびサブジェクト・キー識別子のいずれか)がCLVフレームワークに渡されます。
CLVフレームワークによって、証明書チェーンの呼出しが順序付けされており、チェーン内の各証明書が次の証明書を署名していることが確認されます。
証明書チェーンを検証したら、CLVフレームワークがセキュリティ・レルムに構成されている証明書パス検証プロバイダを構成された順に呼び出します。
構成されているすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。エラーが発生した場合は検証が停止します。
CLVフレームワークが、リクエスト側に証明書チェーンを返します。
処理を続行します。
SAMLおよびWindows統合ログイン機能は、WebLogic ServerアプリケーションにWebベースのシングル・サインオン(SSO)機能を提供します。以下の節では、シングル・サインオンの間に行われるWebLogicコンテナ、セキュリティ・プロバイダ、WebLogic Securityフレームワークの間の対話について説明します。
次の節では、SAML 1.1サービスで構成した場合のWebLogic Serverインスタンスの動作について説明します。
SAMLソースとして動作するとは、以下の動作を意味します。
有効なSAMLアサーションを生成します。このアサーションではソース・ドメインがユーザーを認証したことをアサートし、SAMLソース・サイトでユーザーを認識するための名前を提供します。必要に応じて、ユーザーがメンバーになっているローカル(ソース・サイト)グループの名前も提供されます。
SAML ITSおよびSAMLアサーション検索サービス(ARS)を提供します。
WebLogic Serverは、SAML ITSおよびARSとして動作できます。これらのサービスは、管理コンソールの「サーバー」>「構成」>「フェデレーテッド・サービス」ページの構成設定に基づいてデプロイされるサーブレットによって提供されます。
SAML ITSサービスでは、V1 SAMLプロバイダのPOSTとアーティファクト・プロファイルのぞれぞれに別のURLが必要です。V2 SAMLプロバイダの場合はPOSTとアーティファクト・プロファイルに別個のURLを用意する必要はありません。
以下の節では、POSTプロファイルおよびアーティファクト・プロファイルで、WebLogic ServerをSAMLソースとして使用する方法について説明します。
POSTプロファイルの仕組みは次のとおりです。
ユーザーが、SAMLソース・サイトのWebサイト(たとえばhttp://www.weblogic.com/samlits/its
)にアクセスします。
SAML ITSサーブレットでSAML資格証明マッピング・プロバイダが呼び出され、bearerアサーションがリクエストされます。
SAML資格証明マッピング・プロバイダからアサーションが返されます。SAML資格証明マッピング・プロバイダからは、SAML宛先サイトのURLと適切なPOSTフォームへのパスも返されます。
SAML ITSサーブレットで、生成されたアサーションを含む署名済みSAMLレスポンスが生成され、これが署名されてbased64でエンコードされた上で、HTMLフォーム(デフォルトまたはカスタム)に組み込まれます。
SAML ITSサーブレットから、ユーザーのブラウザにフォームが返されます。
ユーザーのブラウザから、宛先サイトのACSにフォームがPOSTされます。
アサーションの検証が正常に終了すると、ユーザーがログインしてターゲットにリダイレクトされます。
アーティファクト・プロファイルの仕組みは次のとおりです。
ユーザーが、SAMLソース・サイトのWebサイト(www.weblogic.com
)にアクセスします。
SAMLサイト間転送サービス(ITS)サーブレットから、必要なアサーション・タイプ(アーティファクト)を渡してSAML資格証明マッピング・プロバイダが呼び出され、アサーションがリクエストされます。
SAML資格証明マッピング・プロバイダからアサーションが返されます。SAML資格証明マッピング・プロバイダからは、宛先アサーション・コンシューマ・サービス(ACS)のURLとアサーションIDも返されます。
SAML ITSサーブレットは、アサーションIDとローカル・ソース・サイトのソースIDを基にアーティファクトを生成します。(この値は、フェデレーション・サービスのソース・サイト・ページで構成されるソース・サイトURLから計算されます。)
SAML ITSサーブレットが、アーティファクトを問合せパラメータとして渡して、ユーザーをSAML宛先サイトのアサーション・コンシューマ・サービス(ACS)にリダイレクトします。
ACSが問合せパラメータからアーティファクトを取得し、アーティファクトをデコードしてソースIDを取得します。次に、このソースIDを使用して、SAMLソース・サイトのアサーション検索サービス(ARS)のURLをルックアップします。続いて、SAMLソース・サイトのARSのURLにリクエストを送信して、アーティファクトに対応するアサーションをリクエストします。
SAMLアサーション検索サービス(ARS)が、受信したアサーション・リクエストに応答します。その際、アーティファクトを使用して対応するアサーションをアサーション・ストア内で検索し、見つかった場合はSAML宛先サイトへアサーションを返します。
アサーションの検証が正常に終了すると、ユーザーがログインしてターゲットにリダイレクトされます。
セキュリティ・レルムで認証メカニズムとしてSAMLが構成されており、認証されていないWebブラウザまたはHTTPクライアントが保護されているWebLogicリソースにアクセスしようとすると、WebLogic ServerがSAML宛先サイトとして動作します。
SAML宛先サイトは、サーブレット認証フィルタ(SAML認証フィルタ)として実装され、その構成に基づいてSAML IDアサーション・プロバイダによってデプロイされます。SAML宛先サイトは、構成されている1つまたは複数のURLで受信したアサーションをリスニングします。これらのURLは、アサーション・コンシューマ・サービス(ACS)を提供します。また、SAML宛先サイトは、認証されていないユーザーをリモートSAMLソース・サイトにリダイレクトして、アクセスしようとした特定のURLに基づいて認証を行えるように構成することができます。
以下の節では、POSTプロファイルおよびアーティファクト・プロファイルで、WebLogic ServerをSAML宛先として使用する方法について説明します。
一般的なSSOのシナリオにおけるPOSTプロファイルの仕組みは次のとおりです。
ユーザーが、SAMLソース・サイトのWebサイト(たとえばhttp://www.weblogic.com/samlits/its
)にアクセスします。
SAMLソース・サイトでユーザーが認証されアサーションが生成されて、署名済みSAMLレスポンス内にアサーションが格納されたPOSTフォームがユーザーのブラウザに返されます。
ユーザーのブラウザから、POSTフォームがSAML宛先サイトのACSにポストされます。ACSで、着信したリクエストのフォーム・パラメータとしてアサーション側ID (APID)が検索され、そのIDを使用して構成がルックアップされてから、他の処理が実行されます。
SAML宛先サイトでは、SAMLソース・サイトからPOSTフォームを受け取ると、POSTフォームに組み込まれたSAMLレスポンスを抽出し、レスポンスへの署名に使用する証明書の信頼を検証します。構成によっては、必要に応じて受信者チェックが実行されます。
SAMLアサーション・フィルタでは、このアサーションが以前に使用されていないかどうかも確認されます。使用済みチェックが構成されていると、フィルタではアサーションがすでに使用されたかどうかがチェックされます。そうである場合、フィルタはエラーを返します。そうでない場合は、フィルタは後でチェックできるようにアサーションを保持します。
次のいずれかが発生します。
使用済みチェックまたは他の有効性/信頼性チェックに失敗した場合は、ログインが失敗し、WebLogic Serverが403 Forbidden
エラーを返します。
使用済みチェックおよび他の有効性/信頼性チェックが成功した場合は、ユーザーがログインします(assertIdentity()
呼出しによって)。SAML認証フィルタでユーザーのセッションが作成され、認証済みとなったユーザーがリクエストされたターゲットURLにリダイレクトされます。
アーティファクト・プロファイルの仕組みは次のとおりです。
ユーザーが、SAMLソース・サイトのWebサイト(たとえばhttp://www.weblogic.com/samlits/its
)にアクセスします。
リクエストがSAML ITSサービスにリダイレクトされます。
SAMLソース・サイトでユーザーが認証されます。
ユーザーが認証されると、SAML ITSでアサーションが生成され、続いてbase-64でエンコードされたアーティファクトが生成されます。このアーティファクトには、SAML ITSのアサーションIDとソースIDが含まれます。
SAML ITSにより、アーティファクトがリダイレクトURLの問合せパラメータとして渡され、ユーザーがSAML宛先サイトのアサーション・コンシューマ・サービス(ACS)にリダイレクトされます。ACSで、着信したリクエストの問合せパラメータとしてアサーション側ID (APID)が検索され、そのIDを使用して構成がルックアップされてから、他の処理が実行されます。ACSでは、この問合せパラメータを検索してアーティファクトを取得します。
SAML認証フィルタでアーティファクトがbase64でデコードされ、SAMLソース・サイトのソースIDとアサーションIDが特定されます。ソースIDは、そのソース・サイトのアサーション検索URLのルックアップに使用されます。続いてフィルタでは、アーティファクトの送信と対応するアサーションのリクエストを行うSOAPリクエストが、SAMLソース・サイトのアサーション検索サービス(ARS)に対して発行しされます。
SAMLソース・サイトからアサーションが返されます。
SAML認証フィルタでPrincipalValidatorを呼び出してユーザーのIDがアサートされます。
次のいずれかが発生します。
有効性/信頼性チェックに失敗した場合は、ログインが失敗し、WebLogic Serverから403 Forbidden
エラーが返されます。
有効性/信頼性チェックが成功した場合は、ユーザーがログインします(assertIdentity()
呼出しによって)。SAML認証フィルタでユーザーのセッションが作成され、認証済みとなったユーザーがリクエストされたターゲットURLにリダイレクトされます。
WebLogic ServerでサポートされるSAML 2.0 Webシングル・サインオン(SSO)プロファイルは、HTTPリダイレクト、HTTP POST、およびHTTPアーティファクト・バインディングとともに認証リクエスト・プロトコルを実装します。次の節では、このプロファイルを開始できる以下の2つの方法の実行フローについて説明します。ここでは、WebLogic Serverで提供されるSAML 2.0サービスとWebLogic Securityサービス間の対話を示します。
一般的なサービス・プロバイダ開始のSSOシナリオでは、認証されていないユーザーがサービス・プロバイダ・サイトの保護されているリソースにアクセスしようとします。これに応じて、サービス・プロバイダは、適切なIDプロバイダ・パートナを識別し、そのパートナに認証リクエストをリダイレクトすることによってWeb SSOセッションを開始します。次に、IDプロバイダは通常、ログインWebアプリケーションを使用してユーザーを認証し、ユーザーID情報を含むSAMLアサーションを生成して、そのアサーションを認証レスポンスの形式でサービス・プロバイダに返します。
サービス・プロバイダは、認証レスポンスを受信すると、そのレスポンスに含まれているアサーションからID情報を抽出し、そのID情報をローカル・セキュリティ・レルムのサブジェクトにマッピングしてユーザーIDを検証します。ユーザーIDが正常にマッピングされると、サービス・プロバイダは保護されたリソースへのユーザーのアクセスを認可します。
図5-9に、一般的なサービス・プロバイダ開始のWebシングル・サインオン・セッションの実行フローを示します。
実行フローを示す図5-9に記載されている番号の説明は以下のとおりです。
ユーザーがブラウザから、サービス・プロバイダによってホストされているWebLogicコンテナ上の保護されたリソースにアクセスしようとします。
WebLogicコンテナはWebLogic Securityサービスを呼び出し、ユーザーが認証されているかどうかを判別します。
ユーザーは認証されていないため、サービス・プロバイダは、認証されていないユーザーの情報を含む認証リクエストを生成し、IDプロバイダのシングル・サインオン・サービスのエンド・ポイントを使用して、IDプロバイダに送信します。
サービス・プロバイダは、認証リクエストの転送において次のバインディングのいずれかを使用するように構成できます。
HTTP POST - HTTP POSTバインディングを使用すると、サービス・プロバイダは認証リクエストを含むHTTP POSTメッセージをユーザーのブラウザに送信します。その後、HTTP POSTメッセージはIDプロバイダのシングル・サインオン・サービスに送信されます。
HTTPアーティファクト - サービス・プロバイダはSAMLアーティファクトを含むHTTPリダイレクト・メッセージをユーザーのブラウザに送信します。SAMLアーティファクトには、サービス・プロバイダのアーティファクト解決サービス(ARS)によって保持される認証リクエスト・メッセージへのポインタが含まれます。IDプロバイダはHTTPリダイレクト・メッセージを受信すると、サービス・プロバイダのARSにアーティファクト解決リクエストを送信して、認証リクエスト・メッセージを取得します。
HTTPリダイレクト - サービス・プロバイダはHTTPリダイレクト・メッセージをユーザーのブラウザに送信します。ブラウザは、HTTP GETメッセージをIDプロバイダのシングル・サインオン・サービスに送信します。
ユーザーに対して、そのユーザーを認証可能なIDプロバイダによってホストされるログインWebアプリケーションが提供されます。IDプロバイダはユーザーに対しユーザーの資格証明のチャレンジを要求します。
ユーザーは、IDプロバイダにユーザー名とパスワードを送信し、認証処理を完了します。
IDプロバイダによってホストされるシングル・サインオン・サービスは、ユーザーのアサーションを生成し、サービス・プロバイダのアサーション・コンシューマ・サービス(ACS)に認証レスポンスを返します。
IDプロバイダは、次のバインディングを使用するように構成できます。
HTTP POST - IDプロバイダはアサーションを含めた認証レスポンスをユーザーのブラウザに送信します。認証レスポンスは、HTTP POSTメッセージを使用してサービス・プロバイダに転送されます。
HTTPアーティファクト - IDプロバイダはSAMLアーティファクトを含む認証レスポンスをユーザーのブラウザに送信します。SAMLアーティファクトには、IDプロバイダのアーティファクト解決サービス(ARS)によって処理されるアサーションへのポインタが含まれます。認証レスポンスは、HTTPリダイレクト・メッセージを使用してサービス・プロバイダに転送されます。サービス・プロバイダは、そのレスポンスを受信すると、アーティファクト解決リクエストをIDプロバイダのARSに送信してアサーションを取得します。
ACSはアサーションを検証し、そのアサーションからID情報を抽出して、ローカル・セキュリティ・レルムのサブジェクトにそのIDをマッピングします。
ACSはHTTPリダイレクト・メッセージをブラウザに送信し、セッションIDを含むCookieを渡して、リクエストされたリソースにブラウザがアクセスできるようにします。
WebLogic Securityサービスは、認可チェックを実行して、リクエストされたリソースにブラウザがアクセス可能かどうかを判別します。認可チェックに成功すると、リソースへのアクセスが許可されます。
WebLogic Serverは、IDプロバイダによってWebシングル・サインオン・セッションが開始されるシナリオもサポートしています。このシナリオでは、ユーザーはIDプロバイダによって認証され、サービス・プロバイダによってホストされるリソースに対するリクエストを発行します。IDプロバイダは、サービス・プロバイダが要求していない認証レスポンスをサービス・プロバイダに送信することによってSSOセッションを開始します。
サービス・プロバイダは、認証レスポンスを受信すると、アサーションからユーザーIDを抽出し、そのIDをローカル・サブジェクトにマッピングして、リクエストされたリソースに対する認可チェックを実行します。認可チェックに成功すると、アクセスが許可されます。
図5-10に、一般的なIDプロバイダ開始のSSOセッションの実行フローを示します。
実行フローを示す図5-10に記載されている番号の説明は以下のとおりです。
ユーザーに対して、そのユーザーを認証するIDプロバイダによってホストされるログインWebアプリケーションが提供されます。IDプロバイダはユーザーに対しユーザーの資格証明のチャレンジを要求します。
ユーザーは、IDプロバイダにユーザー名とパスワードを送信し、認証処理を完了します。
ユーザーは、サービス・プロバイダによってホストされるリソースに対するリクエストを発行します。
IDプロバイダによってホストされるシングル・サインオン・サービスは、サービス・プロバイダが要求していない認証レスポンスをサービス・プロバイダのアサーション・コンシューマ・サービス(ACS)に送信します。
IDプロバイダはSSOセッションの開始方法に関係なく、「サービス・プロバイダ開始のシングル・サインオン」で説明したのと同じバインディングを使用します。
ACSはアサーションを検証し、ID情報を抽出して、ローカル・セキュリティ・レルムのサブジェクトにそのIDをマッピングします。ACSはHTTPリダイレクト・メッセージをブラウザに送信し、セッションIDを含むCookieを渡して、リクエストされたリソースにブラウザがアクセスできるようにします。
WebLogic Securityサービスは、認可チェックを実行して、リクエストされたリソースにブラウザがアクセス可能かどうかを判別します。認可チェックに成功すると、リソースへのアクセスが許可されます。
このプロセスの仕組みは次のとおりです。
ネゴシエーションIDアサーション・プロバイダは、WWW-Authenticate
およびAuthorization
HTTPヘッダーをサポートするように構成されています。このネゴシエーションIDアサーション・プロバイダが、サーブレット認証フィルタを使用して、ネゴシエーション・プロトコルの認可されていないレスポンスに対して適切なWWW-Authenticateヘッダーを生成し、後続のリクエストでAuthorizationヘッダーを処理します。
ユーザーがWindows 2000または2003ドメインにログインします。このユーザーは、ドメインからKerberos資格証明を取得します。
ユーザーが、SPNEGOプロトコルをサポートするブラウザ(Internet Explorer、Mozillaなど)を使用して、アプリケーション・サーバーで実行されているWebアプリケーションにアクセスしようとします。アプリケーション・サーバーを実行するプラットフォームは、UNIXでもWindows 2000/2003でも構いません。
ブラウザが、アプリケーション・サーバーにGET
リクエストを送信します。
アプリケーション・サーバーが、認可されていないレスポンスを適切なWWW-Authenticate
ヘッダーとともに送り返します。
サーブレット・コンテナが、サーブレット認証フィルタの構成済みチェーンをWebLogic Securityフレームワークから取得します。
サーブレット・コンテナが、サーブレット認証フィルタのチェーンを呼び出します。ネゴシエーション・サーブレット認証フィルタは、ネゴシエーション認証スキームのWWW-Authenticate
リクエスト・ヘッダーを追加し、WebLogic Securityフレームワークに働きかけて初期ネゴシエーション・チャレンジを取得します。次のメッセージが送り返されます。
401 Unauthorize
WWW-Authenticate: Negotiate
ブラウザは、WWW-Authenticate
ヘッダーを受信し、ネゴシエーション認証スキームをサポートできるかどうかを判別します。そして、サポートするGSSメカニズム・トークン・タイプを含むSPNEGOトークンを作成します。このトークンをBase64でエンコードし、元のGETメッセージのAuthorizationヘッダーを使用してアプリケーション・サーバーに返信します。次に例を示します。
GET... Authorization: Negotiate <Base64 encoded SPNEGO token>
リクエストはまだ認可されていないため、サーブレット・コンテナがサーブレット認証フィルタを呼び出します。ネゴシエーション・サーブレット認証フィルタは、認可リクエスト・ヘッダーを処理してWebLogic Securityフレームワークを呼び出します。フレームワークは、トークンをネゴシエーションIDアサーション・プロバイダに渡します。
ネゴシエーションIDアサーション・プロバイダが、GSSコンテキストを使用して開始プリンシパルの名前を取得します。この名前はユーザー名にマップされ、コールバック・ハンドラによってWebLogic Securityフレームワークに返信されます。
WebLogic Securityフレームワークは、そのユーザーが所属するグループも判別します。
これで認証が完了し、GETリクエストが処理されます。
WebLogic WebサービスとWebLogic Securityフレームワークは、SAML 1.1および2.0アサーションの生成、消費、および検証をサポートするように拡張されています。SAMLアサーションを使用する場合は、WebサービスがSAMLアサーションとそれに付随する証明データをWebLogic Securityフレームワークに渡します。SAMLアサーションが有効で信頼されれば、フレームワークが認証されたサブジェクトと信頼性のあるプリンシパルをWebサービスに返します。WebLogic WebサービスとWebLogic Securityフレームワークでは、次のSAMLアサーションがサポートされます。
Sender-Vouches - サブジェクトとは異なるアサーション側がサブジェクトの検証を保証します。受信側がアサーション側との信頼関係を確立している必要があります。
Holder-of-Key -「holder-of-key」サブジェクト確認が指定されたSAMLトークンは、リクエスト・メッセージの整合性を確保するために、受信側で信頼されていない可能性のあるX.509証明書をサブジェクトで使用できるようにすることを目的としたものです。
理論的には、アサーション側によってX.509のパブリック証明書(または他のキー情報)がSAMLアサーションに挿入されます(厳密には、アサーション・パーティによりキーがサブジェクトにバインドされます)。この組み込まれた証明書を保護するには、SAMLアサーション自体がアサーティング・エンティティによって署名されている必要があります。WebLogic Serverの場合、SAMLアサーションはWebサービス・クライアントによって署名され、署名にはWebサービス・クライアントの秘密鍵が使用されます。つまり、アサーションの署名はSAML権限の署名であり、アサーションに含まれる証明書やアサーションにより特定される証明書に基づくものではありません。
Bearer - アサーションのサブジェクトはアサーションのベアラーであり、アサーションの<SubjectConfirmationData>
要素に含まれている属性を使用した確認に対するオプションの制約に従います。
以下の節では、これらのアサーションを処理する方法について説明します。
すべてのSender-Vouchesアサーションは基本的に同じで、信頼の確立方法(トランスポートにSSLを使用するかどうか、SAMLアサーションとメッセージ本文が署名されるかどうか)だけが異なります。
Sender-Vouchesアサーションは、次の方法で使用します。
ユーザーがWebLogic Webサービスを呼び出します。
WebサービスがユーザーからのSAMLアサーションをリクエストします。
ユーザーがSAMLアサーションを生成してWebサービスに返します。
Webサービスが、適切なSAMLアサーションを生成するSAML資格証明マッピング・プロバイダを呼び出します。
次のいずれかが発生します。なお、以下に示すのはもっとも起こりやすい状況であり、これ以外の状況にもなり得ることに留意してください。
Webサービスが、SOAPメッセージ内の非SSLトランスポートを使用して、署名されていないアサーションを宛先に送信します。このタイプのアサーションでは、証明データがSOAPメッセージに含まれていないため、アサーションは信頼できず、アサーションが信頼性のあるパーティから送られたと見なすこともできません。
Webサービスが、SSLプロトコルを使用して、SOAPメッセージ内の署名されていないアサーションを宛先に送信します。このタイプのアサーションでは、クライアント証明書を使用して信頼を確立します。
Webサービスがアサーションに署名し、SOAPメッセージ内の非SSLトランスポートを使用して宛先に送信します。このタイプのアサーションでは、署名が信頼のための証明データを提供しますが、接続が失われていないと見なすことはできません。一方、署名されたアサーションの変更については検出できます。これは、どのような変更があっても署名の信頼性が失われるためです。
Webサービスがアサーションに署名し、SSLプロトコルを使用してSOAPメッセージ内の署名されたアサーションを宛先に送信します。このタイプのアサーションでは、署名またはクライアント証明書によって信頼が確立されます。
SAML IDアサーション・プロバイダでアサーションが消費されて検証され、アサーションを信頼するかどうかが決定されます。
アサーションが信頼されると、SAML IDアサーション・プロバイダがユーザー・プリンシパルと(可能であれば)グループ・プリンシパルを含むサブジェクトを作成し、そのサブジェクトをWebサービスに返します。
Webサービスがユーザーにレスポンスを返します。
Holder-of-Keyアサーションでは、ユーザーを信頼するかどうかを確認する上で、Webサービス・クライアントがWebサービス・サーバーに依存します。
Holder-of-Keyアサーションは、次の方法で使用します。
ユーザーが、未確認のメカニズムでWebサービス・クライアントの認証を受けます。Webサービス・クライアントはローカルでもリモートでもよく、WebLogicサーバー・インスタンスでなくても構いません。
Webサービス・クライアントがユーザーを信頼し、ユーザーの証明書を含むSAMLアサーションを生成して、その秘密鍵でSAMLアサーションに署名します。Webサービス・クライアントが、SAMLアサーションをユーザーに返します。
ユーザーが、SAMLアサーション情報をSOAPメッセージのwsse:Security
ヘッダーに挿入します。メッセージ本文は、ユーザーの秘密鍵で署名されます。
ユーザーがWebLogic Webサービスを呼び出します。
Webサービスが、SOAPメッセージをWebサービス・サーバー(この場合はWebLogic Serverインスタンス)に送信します。Webサービス・サーバーは、SAMLアサーションとSOAPメッセージを信頼するかどうかに基づいて信頼の決定を下します。
Webサービス・サーバーでアサーションが受信され、アサーションはSAML IDアサーション・プロバイダに渡されます。SAML IDアサーション・プロバイダでは、アサーションの署名とそれに使用されている証明書の信頼性を検証します。
これが成功すると、Webサービス・サーバーではholder-of-keyアサーションのキーが実際にそのアサーションのサブジェクトに属していると見なせます。その結果、Webサービスでそのキーを使用して、SOAPメッセージの署名を検証できるようになります。これによって、SOAPメッセージがキーの保持者により生成され、送信されたことが認められます。X.509証明書自体の信頼性の検証はWebサービス・サーバーに任されます。
Webサービス・サーバーによって、SAMLアサーション用のプリンシパルを含むサブジェクトがWebサービス・クライアントに返されます。
Webサービス・クライアントがユーザーにレスポンスを返します。
このアサーションでは、必要に応じてSSLプロトコルを使用できます。SSLプロトコルを使用する場合は、クライアント証明書も証明データとして使用できます。
WebLogic Serverのこのリリースでのセキュリティは、一連のセキュリティ・サービス・プロバイダ・インタフェース(SSPI)に基づいています。開発者およびサード・パーティ・ベンダーは、SSPIを使用してWebLogic Server環境向けのセキュリティ・プロバイダを開発できます。SSPIは、認証、IDアサーション、認可、監査、裁決、ロール・マッピング、資格証明マッピング、および証明書の検索と検証に利用可能です。
注意: キーストア・プロバイダ用のSSPIはこのリリースのWebLogic Serverでは非推奨となっています。かわりにJavaキーストア(JKS)を使用してください。 |
SSPIを使用すると、カスタム・セキュリティ・プロバイダでWebLogic Serverリソースを保護することができます。SSPIを使用してカスタム・セキュリティ・プロバイダを開発することも、サード・パーティ・ベンダーからカスタム・セキュリティ・プロバイダを購入することもできます。
カスタム・セキュリティ・プロバイダの開発に役立つように、Oracle Technology Network (OTN)のhttps://www.samplecode.oracle.com/tracker/tracking/linkid/prpl1004?id=S224
でカスタム・セキュリティ・プロバイダのサンプルも入手できます。
カスタム・セキュリティ・プロバイダの開発の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。
この節では、お使いのWebLogic Server製品に付属しているセキュリティ・プロバイダについて説明します。セキュリティ・プロバイダは、WebLogic Serverのセキュリティ・レルムに「プラグイン」してアプリケーションにセキュリティ・サービスを提供するためのモジュールです。セキュリティ・プロバイダは、アプリケーションのかわりにWebLogic Securityフレームワークに働きかけを行います。
WebLogic Server製品に付属しているセキュリティ・プロバイダがセキュリティ要件を完全に満たしていない場合には、カスタム・セキュリティ・プロバイダで補足するか、あるいはカスタム・セキュリティ・プロバイダに置き換えることができます。カスタム・セキュリティ・プロバイダは以下のようにして開発します。
weblogic.security.spi
パッケージから適切なセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装してセキュリティ・プロバイダの実行時クラスを作成します。
MBean定義ファイル(MDF)を作成し、WebLogic MBeanMakerユーティリティを使用してMBeanタイプを生成します。MBeanタイプは、セキュリティ・プロバイダの構成と管理に使用します。
詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。
図5-11に、WebLogicセキュリティ・レルムにおいて必須および省略可能なセキュリティ・プロバイダを示します。
以下の節では、セキュリティ・プロバイダについて説明します。
WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogic認証プロバイダが含まれています。WebLogic認証プロバイダは、ユーザー名とパスワードの委託認証とWebLogic Serverセキュリティのダイジェスト認証をサポートします。ユーザーとグループの情報の格納には、組込みLDAPサーバーを利用します。このプロバイダを使用すると、ユーザーとグループ・メンバーシップを編集、表示、および管理できます。
このプロバイダでは、ユーザーに割り当てることができる一連の属性(従業員番号、部署番号など)も提供されます。
注意: WebLogic認証プロバイダをWebLogic認可プロバイダと組み合せれば、WebLogic Serverリリース6.xで利用できたファイル・レルムの機能のかわりになります。 |
WebLogic Serverでは、デフォルトのセキュリティ・レルムにおいて、以下の認証プロバイダをWebLogic認証プロバイダのかわりとして使用したり、WebLogic認証プロバイダと併用したりできます。
外部LDAPストア(Open LDAP、iPlanet、Microsoft Active Directory、Oracle Internet Directory、Oracle Virtual Directory、Novell NDS)にアクセスする一連のLDAP認証プロバイダ。
認証を行うために、データベースに格納されているユーザー、パスワード、グループ、およびグループ・メンバーシップ情報にアクセスする一連のデータベース管理システム(DBMS)プロバイダ。必要に応じて、WebLogic Serverを使用してユーザー、パスワード、グループ、およびグループ・メンバーシップ情報を管理できます。DBMS認証プロバイダは、RDBMSセキュリティ・レルムからのアップグレード・パスです。
以下のDBMS認証プロバイダを使用できます。
SQL認証プロバイダ - ユーザー、パスワード、グループ、およびグループ・メンバーシップ情報の表示や編集をサポートする管理可能な認証プロバイダ。
読取り専用SQL認証プロバイダ - WebLogic Server管理コンソールを使用したデータベース内のユーザーの認証およびデータベースのコンテンツの表示をサポートする認証プロバイダ。この認証プロバイダは特定のSQL文のセットを必要とするため、すべてのニーズには対応できない可能性があります。
カスタムDBMS認証プロバイダ - 認証をサポートするだけの実行時認証プロバイダ。このプロバイダでは、データベースに問い合わせて認証情報を取得するためのコードをユーザーが記述する必要があります。DBMS認証プロバイダを特殊なデータベース・ニーズに適合させるための柔軟な認証プロバイダです。
認証を行うためにWindows NTユーザーおよびグループを使用するWindows NT認証プロバイダ。Windows NT認証プロバイダは、Window NTセキュリティ・レルムのアップグレード・パスです。WebLogic Server管理コンソールでは、Windows NTのユーザーおよびグループを表示することはできますが、管理することはできません。
X509証明書に関連付けられたユーザーのLDAPオブジェクトをルックアップし、LDAPオブジェクトの証明書が提示された証明書と一致することを確認し、認証を目的としてLDAPオブジェクトからユーザーの名前を取得するLDAP X509 IDアサーション・プロバイダ。
注意: デフォルトでは、これらの認証プロバイダは使用可能ですが、WebLogicデフォルト・セキュリティ・レルムには構成されていません。 |
WebLogic Serverには、パスワード検証プロバイダが付属しており、このプロバイダが次に示す1つ以上の認証プロバイダで構成されていると、パスワード構成ルール・セットを管理および適用することができます。
WebLogic認証プロバイダ
SQL認証プロバイダ
LDAP認証プロバイダ
Active Directory認証プロバイダ
iPlanet認証プロバイダ
Novell認証プロバイダ
Open LDAP認証プロバイダ
認証プロバイダでパスワード検証プロバイダが構成されている場合、認証プロバイダは、パスワードが作成または更新されると、パスワード検証プロバイダを呼び出します。呼び出されたパスワード検証プロバイダは、そのパスワードが構成可能な構成ルール・セットに基づく条件を満たすかどうかを検証します。
WebLogic IDアサーション・プロバイダでは、X.509証明書を使用した証明書認証およびCSIv2 (CORBA Common Secure Interoperability version 2) IDアサーションがサポートされています。WebLogic IDアサーション・プロバイダはトークン・タイプを検証し、X.509デジタル証明書とX.501識別名をWebLogicユーザーにマップします。また、CSIv2 IDアサーションに使用する信頼性のあるクライアント・プリンシパルのリストも指定します。ワイルドカード文字(*)を使用すると、すべてのプリンシパルに信頼性があると指定できます。クライアントが信頼性のあるクライアント・プリンシパルのリストにない場合は、CSIv2 IDアサーションが失敗し、呼出しが拒否されます。
WebLogic IDアサーション・プロバイダでは、以下のトークン・タイプがサポートされています。
AU_TYPE
- WebLogic AuthenticatedUser
がトークンとして使用される場合に使用します。
X509_TYPE
- X.509クライアント証明書がトークンとして使用される場合に使用します。
CSI_PRINCIPAL_TYPE
- CSIv2プリンシパル名IDがトークンとして使用される場合に使用します。
CSI_ANONYMOUS_TYPE
- CSIv2匿名IDがトークンとして使用される場合に使用します。
CSI_X509_CERTCHAIN_TYPE
- CSIv2 X509証明書チェーンIDがトークンとして使用される場合に使用します。
CSI_DISTINGUISHED_NAME_TYPE
- CSIv2識別名IDがトークンとして使用される場合に使用します。
WSSE_PASSWORD_DIGEST
- パスワード・タイプwsse:PasswordDigest
のwsse:UsernameToken
がトークンとして使用される場合に使用します。
SAML IDアサーション・プロバイダV2は、SAML 1.1アサーションを検証し、発行者が信頼されていることを確認します。信頼されていれば、アサーションに含まれる認証文に基づき、IDがアサートされます。
プロバイダの構成には、SAMLソース・サイトおよび宛先サイトのSSOサービス(ITS、ACS、ARSなど)を構成してサーバーで実行できるようにするための設定が含まれています。
SAML IDアサーション・プロバイダでは、以下のSAMLサブジェクト確認メソッドがサポートされています。
artifact
bearer
sender-vouches
holder-of-key
SAML 2.0 IDアサーション・プロバイダは、SAML 1.1用のSAML IDアサーション・プロバイダV2と同様に、SAML 2.0アサーションを検証し、発行者が信頼されていることを確認します。信頼されていれば、アサーションに含まれる認証文に基づき、IDがアサートされます。
プロバイダの構成には、SAML 2.0サービス・プロバイダ・サービス(アサーション・コンシューマ・サービスやアーティファクト解決サービスなど)を構成してサーバーで実行できるようにするための設定が含まれています。
SAML 2.0 IDアサーション・プロバイダでは、以下のSAMLサブジェクト確認メソッドがサポートされています。
bearer
sender-vouches
holder-of-key
ネゴシエーションIDアサーション・プロバイダは、SPNEGOプロトコルをサポートするMicrosoftクライアントでのSSOに使用します。具体的には、SPNEGOトークンをデコードしてKerberosトークンを入手し、このKerberosトークンを検証してWebLogicユーザーにマップします。ネゴシエーションIDアサーション・プロバイダは、Kerberosを介したGSSのセキュリティ・コンテキストの受け入れにJava GSS (Generic Security Service) API (Application Programming Interface)を利用します。Java GSS APIの詳細は、http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html
を参照してください。
ネゴシエーションIDアサーション・プロバイダは、WebLogicサーブレット・コンテナと対話します。このコンテナが、WWW-Authenticate
ヘッダーおよびWWW-Authorization
ヘッダーを処理して、適切なNegotiateヘッダーを追加します。
デフォルトでは、ネゴシエーションIDアサーション・プロバイダは使用可能ですが、WebLogicデフォルト・セキュリティ・レルムには構成されていません。ネゴシエーションIDアサーション・プロバイダは、WebLogic IDアサーション・プロバイダのかわりとして使用したり、WebLogic IDアサーション・プロバイダと併用したりできます。
WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogicプリンシパル検証プロバイダが含まれています。このプロバイダは、WebLogic Serverプリンシパルの署名と検証を行います。言い換えると、WebLogic ServerユーザーまたはWebLogic Serverグループを表すプリンシパルに対して署名と検証を行います。
注意: weblogic.securityパッケージのWLSPrincipalsクラスを使用すると、プリンシパル(ユーザーまたはグループ)がWebLogic Serverに対して特別な意味を持っているかどうか(それが定義済のWebLogic ServerユーザーまたはWebLogic Serverグループであるかどうか)が分かります。さらに、WebLogic Serverユーザーまたはグループを表すプリンシパルは、weblogic.security.spi パッケージのWLSUser インタフェースとWLSGroup インタフェースを実装する必要があります。 |
WebLogicプリンシパル検証プロバイダには、WLSUserImpl
およびWLSGroupImpl
という名前のWLSUser
インタフェースおよびWLSGroup
インタフェースの実装が含まれています。これらは、weblogic.security.principal
パッケージに定義されています。また、PrincipalValidatorImpl
という名前のPrincipalValidator
SSPIの実装も含まれています。PrincipalValidator
SSPIの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「PrincipalValidator SSPIの実装」を参照してください。
IDアサーション・プロバイダが特定のタイプのトークンをサポートするのと同じように、プリンシパル検証プロバイダは特定のタイプのプリンシパルに対する署名と信頼性の確認を行います。そのため、WebLogicプリンシパル検証プロバイダを使用して、WebLogic ServerユーザーまたはWebLogic Serverグループを表すプリンシパルに対して署名と検証を行うことができます。
バージョン9.1からのWebLogic Serverには、OASISのeXtensible Access Control Markup Language (XACML) 2.0標準をサポートする認可プロバイダが付属しています。このWebLogicプロバイダでは、標準XACML 2.0のあらゆる関数、属性、およびスキーマ要素で表されるポリシーのインポート、エクスポート、永続化、および実行が可能です。
WebLogic Server 9.1以降で新しく作成されたドメインでは、デフォルトでXACML認可プロバイダが使用されるようになっています。既存のドメインをWebLogic Server 9.1以降のリリースにアップグレードした場合、サード・パーティ製パートナ・プロバイダやオリジナルのWebLogic Server専用プロバイダなどの、現行で指定されている認可プロバイダが引続き使用されます。WebLogic Server管理コンソールを使用して認可プロバイダを新しく追加する場合、新しいプロバイダをDefaultAuthorizerプロバイダまたはXACMLプロバイダとして追加できます。
カスタムXACMLプロバイダはこのリリースではサポートされていません。
また、WebLogic Serverバージョン9.1には「デフォルト」のWebLogic認可プロバイダも用意されています。このプロバイダによって、9.1より前のバージョンのWebLogic Serverに対するデフォルトの認可が適用されています。ポリシー・ベースの認可エンジンを使用して、WebLogic認可プロバイダからアクセス決定が返され、特定のユーザーが保護対象のWebLogicリソースへのアクセスを許可されているかどうかが判断されます。また、WebLogic認可プロバイダは、システム内のセキュリティ・ポリシーのデプロイメントとアンデプロイメントもサポートしています。
WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogic裁決プロバイダが含まれています。このプロバイダは通常、複数の認可プロバイダのアクセス決定から異なる結果が返された場合に裁決を行い、WebLogicリソースへのアクセスを許可するかどうかを最終的に判定します。ただし、デフォルトのセキュリティ・レルムには認可プロバイダが1つしかなく、生成されるアクセス決定は1つのみなので、WebLogic裁決プロバイダは使用されません。
注意: 互換性レルムには認可プロバイダが2つあるので、そのレルムではWebLogic裁決プロバイダが使用されます。 |
WebLogic裁決プロバイダには、動作を制御する「完全一致の許可が必要」という属性があります。「完全一致の許可が必要」属性は、デフォルトではTRUE
に設定されており、WebLogic裁決プロバイダはその設定に従って次のように動作します。
すべての認可プロバイダのアクセス決定がPERMIT
を返した場合、最終的な判定としてTRUE
を返します(つまりWebLogicリソースへのアクセスは許可されます)。
一部の認可プロバイダのアクセス決定がPERMIT
を返し、その他がABSTAIN
を返した場合、FALSE
を返します(つまりWebLogicリソースへのアクセスは拒否されます)。
いずれかの認可プロバイダのアクセス決定がABSTAIN
またはDENY
を返した場合、最終的な判定としてFALSE
を返します(つまりWebLogicリソースへのアクセスは拒否されます)。
「完全一致の許可が必要」属性をFALSE
に変更した場合、WebLogic裁決プロバイダは次のように動作します。
すべての認可プロバイダのアクセス決定がPERMIT
を返した場合、最終的な判定としてTRUE
を返します(つまりWebLogicリソースへのアクセスは許可されます)。
一部の認可プロバイダのアクセス決定がPERMIT
を返し、その他がABSTAIN
を返した場合、最終的な判定としてTRUE
を返します(つまりWebLogicリソースへのアクセスは許可されます)。
いずれかの認可プロバイダのアクセス決定がDENY
を返した場合、最終的な判定としてFALSE
を返します(つまりWebLogicリソースへのアクセスは拒否されます)。
注意: 「完全一致の許可が必要」属性は、WebLogic裁決プロバイダを構成するときに設定します。裁決プロバイダの構成の詳細は、『Oracle WebLogic Serverの保護』の「WebLogic裁決プロバイダの構成」を参照してください。 |
バージョン9.1からのWebLogic Serverには、OASISのeXtensible Access Control Markup Language (XACML) 2.0標準をサポートするロール・マッピング・プロバイダが付属しています。このWebLogicプロバイダでは、標準XACML 2.0のあらゆる関数、属性、およびスキーマ要素で表されるポリシーのインポート、エクスポート、永続化、および実行が可能です。
WebLogic Server 9.1以降で新しく作成されたドメインでは、デフォルトでXACMLロール・マッピング・プロバイダが使用されるようになっています。既存のドメインをWebLogic Server 9.1以降のリリースにアップグレードした場合、サード・パーティ製パートナ・プロバイダやオリジナルのWebLogic Server専用プロバイダなどの、現行で指定されているロール・マッピング・プロバイダが引続き使用されます。WebLogic Server管理コンソールを使用してロール・マッピング・プロバイダを新しく追加する場合、新しいプロバイダをDefaultRoleMapperプロバイダまたはXACMLプロバイダとして追加できます。
カスタムXACMLプロバイダはこのリリースではサポートされていません。
また、WebLogic Serverバージョン9.1には「デフォルト」のWebLogicロール・マッピング・プロバイダも用意されています。このプロバイダによって、9.1より前のバージョンのWebLogic Serverに対するデフォルトのロール・マッピングが適用されています。このプロバイダは、デフォルト・ユーザーとWebLogicリソースのそれぞれについて、保護されている特定のWebLogicリソースに関する特定のユーザー(サブジェクト)の動的ロールを決定します。また、WebLogicロール・マッピング・プロバイダは、システム内のロールのデプロイメントとアンデプロイメントをサポートしています。WebLogicロール・マッピング・プロバイダは、WebLogic認可プロバイダと同じセキュリティ・ポリシー・エンジンを使用します。
WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogic監査プロバイダが含まれています。このプロバイダは、WebLogic Securityフレームワークで内部的に決定された、複数のセキュリティ・リクエストの情報を記録します。また、WebLogic監査プロバイダはこれらのセキュリティ・リクエストに関連付けられているイベント・データとリクエストの結果も記録します。
WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogic資格証明マッピング・プロバイダが含まれています。WebLogic資格証明マッピング・プロバイダを使用して、WebLogic Serverユーザーを、エンタープライズ情報システム(EIS) (たとえば、Oracle、SQL Serverなどのリレーショナル・データベース)にアクセスするためにリソース・アダプタで使用すべき適切な資格証明に関連付ける(つまりマップする)ことができます。プロバイダは、ユーザーの認証資格証明(ユーザー名とパスワード)をレガシー・アプリケーションで必要になる認証資格証明にマップするので、レガシー・アプリケーションは必要な資格証明情報を取得できます。たとえば、EISはメインフレーム・トランザクション処理システムでも、データベース・システムでも、Javaプログラミング言語で記述されていないレガシー・アプリケーションでもかまいません。
WebLogic Serverのユーザーおよびグループと他のシステムのユーザー名/パスワードとの間のマッピングであれば、WebLogic資格証明マッピング・プロバイダで十分です。
SAML資格証明マッピング・プロバイダV2では、依存側または宛先サイトの構成に基づく認証されたサブジェクトに対するSAML 1.1アサーションを生成します。アサーションには認証文と、必要に応じてWebLogic Serverのグループ情報を含む属性文が含まれます。リクエストされたターゲットが、構成されておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザー情報およびグループ・メンバーシップは、(そのように構成された場合) AttributeStatement内に置かれます。
管理コンソールの「フェデレーション・サービス」構成ページに、SAMLのソース・サイトおよび宛先サイトのSSOサービス(ITS、ACS、ARSなど)を構成し、サーバーで実行するために有効化する設定があります。
SAML資格マッピング・プロバイダは、以下のSAMLサブジェクト確認メソッドをサポートしています。
artifact
bearer
sender-vouches
holder-of-key
SAML 2.0資格証明マッピング・プロバイダは、IDプロバイダ・サービスとサービス・プロバイダ・パートナの構成に基づく認証されたサブジェクトに対するSAML 2.0アサーションを生成します。アサーションには認証文と、必要に応じてWebLogic Serverのグループ情報を含む属性文が含まれます。リクエストされたターゲットが、構成されておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザー情報およびグループ・メンバーシップは、(そのように構成された場合) AttributeStatement内に置かれます。
管理コンソールのSAML 2.0用の「フェデレーション・サービス」構成ページに、SAML 2.0のソース・サイトおよび宛先サイトのサービス(シングル・サインオン、アーティファクト解決サービスなど)を構成し、サーバーで実行するために有効化する設定があります。
SAML資格マッピング・プロバイダは、以下のSAMLサブジェクト確認メソッドをサポートしています。
bearer
sender-vouches
holder-of-key
PKI (公開鍵インフラストラクチャ)資格証明マッピング・プロバイダは、WebLogic Serverのサブジェクト(開始者)とターゲット・リソース(および必要であれば資格証明アクション)を、ターゲット・リソースを使用する際にアプリケーションで使用する公開鍵と秘密鍵のペアまたは公開証明書にマップします。このプロバイダを使用して、公開鍵と秘密鍵のペアまたは公開証明書に別名をマップすることもできます。PKI資格証明マッピング・プロバイダは、サブジェクトとリソース名(または別名)を使用して対応する資格証明をキーストアから検索します。
WebLogic証明書パス・プロバイダは、証明書パス・ビルダーと証明書パス検証プロバイダの両方です。証明書パス・プロバイダは、証明書のパスを完了させ、特定のサーバー・インスタンスのために構成された信頼性のあるCAを使用して証明書を検証します。完了できない証明書チェーンは無効になります。
また、WebLogic証明書パス・プロバイダは、チェーン内の署名をチェックして、チェーンが期限切れでないことを確認し、チェーン内のいずれかの証明書が、サーバー用に構成された信頼性のあるCAによって発行されたものであることを確認します。いずれかのチェックが失敗した場合、そのチェーンは有効ではありません。
最後に、プロバイダは、各証明書の基本的な制約(証明書が他の証明書を発行できるかどうか)をチェックし、証明書がチェーン内の適切な場所にあることを確認します。
WebLogic証明書パス・プロバイダは、セキュリティ・レルム内の証明書パス・ビルダーまたは証明書パス検証プロバイダとして使用できます。
証明書レジストリを使用すると、システム管理者はサーバーへのアクセスが許可されている信頼性のあるCA証明書のリストを明示的に構成できます。証明書レジストリは、失効チェックを実行するための、費用のかからないメカニズムを提供します。管理者は、証明書レジストリから削除することによって、証明書を無効にします。このレジストリは、組込みLDAPサーバーに格納されます。
証明書レジストリは、サーバー単位ではなくドメイン単位で構成します。
証明書レジストリは、証明書パス・ビルダーと証明書パス検証プロバイダの両方です。どちらの場合でも、証明書レジストリは、チェーンの目的の証明書がレジストリに格納されていることを検証します。
バージョン管理可能なアプリケーションは、アプリケーション・アーカイブ(EARファイル)のマニフェスト内で指定されているアプリケーション・アーカイブのバージョンを持つアプリケーションです。バージョン管理可能なアプリケーションはside-by-sideでデプロイでき、同時にアクティブにすることが可能です。バージョン管理可能なアプリケーションを使用すると、アプリケーションの複数のバージョンを利用できます。各バージョンには、個別のセキュリティ制約を設定できます。
バージョン管理可能なアプリケーションのプロバイダSSPIを使用すると、バージョンが作成および削除されたときに、アプリケーションのバージョン管理をサポートするすべてのセキュリティ・プロバイダに通知できます。また、バージョンが1つしかないアプリケーションが削除された場合にも、アプリケーションのバージョン管理をサポートするすべてのセキュリティ・プロバイダに通知できます。
WebLogicキーストア・プロバイダでは、Java Software Development Kit (SDK)の形で提供されるキーストアの参照実装を使用します。そこでは標準のJavaキーストア(JKS)キーストア・タイプが利用されますが、これはキーストアをファイル(マシンごとに1つ)として実装したものです。各秘密鍵はそれぞれのパスワードで保護されます。WebLogicキーストア・プロバイダに関連付けられているキーストア・ファイルは2つあります。
一方のキーストア・ファイルには信頼性のある認証局(CA)証明書が記載されています。WebLogic Serverには信頼性のある認証局キーストア・ファイルが付属しており、WebLogic Serverはデフォルトではそれを使用して、SSLで使用される信頼性のあるCA証明書を見つけ、クライアント証明書が正しいかどうかを確認します。
もう一方のキーストア・ファイルには、サーバーの秘密鍵が記載されています。WebLogic Serverはこのファイルから秘密鍵を取得してSSLを初期化します。SDKのkeytool
ユーティリティかWebLogic ServerのImportPrivateKey
ユーティリティを利用すれば、このファイルに秘密鍵を追加できます。なお、WebLogic Serverでは、このキーストア・ファイルから秘密鍵と証明書を取得できます。
注意: WebLogicキーストア・プロバイダはこのリリースのWebLogic Serverでは非推奨となっていますが、引続きサポートされています。カスタム・キーストア・プロバイダの開発はサポートされていません。かわりにJavaキーストア(JKS)を使用してください。WebLogicキーストア・プロバイダによってサポートされていたすべての機能は、Javaキーストアを使用することで利用できます。WebLogicキーストア・プロバイダは、下位互換性を保持するためにのみサポートされています。WebLogicキーストア・プロバイダは、WebLogic Server 7.0構成と下位互換性を保持する必要がある場合にのみ使用することをお薦めします。 WebLogicキーストア・プロバイダは、WebLogic Server 7.0構成と下位互換性を保持する必要がある場合にのみ使用することをお薦めします。 |
WebLogicレルム・アダプタ・プロバイダは、既存のバージョン6.xセキュリティ・レルムをWebLogic Serverのこのリリースのセキュリティ機能と併用できるようにすることで、バージョン6.x WebLogicセキュリティ・レルムとの下位互換性を提供するものです。WebLogicレルム・アダプタ・プロバイダは、WebLogic Server 6.xで使用されるレルムAPI (weblogic.security.acl
)をWebLogic Serverのこのリリースで使用されるAPIにマップします。以下のWebLogicレルム・アダプタ・プロバイダが提供されています。
認証(IDアサーション・プロバイダを含む)
レルム・アダプタ認証プロバイダを利用すれば、バージョン6.xのセキュリティ・レルムとそれらのデータ・ストアをWebLogic ServerのWebLogicセキュリティ・プロバイダと併用できるようになります。さらに、weblogic.security.acl.CertAuthenticator
クラスの実装をWebLogic Serverで使用することも可能になります。レルム・アダプタ認証プロバイダには、X.509トークンに基づいたIDアサーションを提供するコンポーネントが含まれています。
認可
互換性セキュリティでは、WebLogic認可プロバイダとレルム・アダプタ認可プロバイダの2種類の認可プロバイダが使用されます。WebLogic認可プロバイダは新しいセキュリティ・ポリシーに使用されます。レルム・アダプタ認可プロバイダはWebLogic Server 6.1のアクセス制御リスト(ACL)をマッピングするために使用されます。
監査
レルム・アダプタ監査プロバイダを利用すれば、互換性セキュリティを使用するWebLogic Serverデプロイメントでweblogic.security.audit
インタフェースの実装を使用できるようになります。
裁決
レルム・アダプタ裁決プロバイダを使用すれば、互換性セキュリティを使用するセキュリティ・レルムでWebLogic認可プロバイダとレルム・アダプタ認可プロバイダを併用できるようになります。
これらのセキュリティ・プロバイダはWebLogic Server管理コンソールを使って構成されますが、既存の6.xセキュリティ・レルムではWebLogic Server 6.1に存在するのと同じMBeanとユーザー・インタフェースを引続き使用することになります。
注意: WebLogicレルム・アダプタ・プロバイダは非推奨になったため、このリリースのWebLogic Serverで使用できるセキュリティ・モデルにアップグレードする間だけ使用してください。 |