|
|
この節では、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 インタフェースの実装を使用するかのいずれかの方法があります。詳細については、『WebLogic セキュリティ プロバイダの開発』の「カスタム 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 フレームワークを通してリソース コンテナに転送します。
WebLogic Security フレームワークは、認可判定の一環として、セキュリティ レルム用にコンフィグレーションされている各ロール マッピング プロバイダを呼び出します。関連情報については、「認可プロセス」を参照してください。
動的なロール関連付けを作成する場合のロール マッピング プロバイダと WebLogic Security フレームワークとの対話を図 5-6 に示します。
ユーザまたはシステム プロセスが WebLogic リソースを要求し、特定の操作を実行しようとすると、ロール マッピング プロセスが開始されます。要求された WebLogic リソースのタイプを処理するリソース コンテナが要求を受け取ります。たとえば EJB コンテナは EJB リソースに対する要求を受け取ります。リソース コンテナは、WebLogic Security フレームワークを呼び出して、リクエストのサブジェクト、要求されている WebLogic リソースなどの情報を含むリクエスト パラメータを渡します。WebLogic Security フレームワークは、適用するロールのリストを取得するために、コンフィグレーション済みの各ロール マッピング プロバイダを呼び出します。要求側に特定のロールの資格があるとセキュリティ ポリシーに指定されている場合には、そのロールがサブジェクトに適用されるロールのリストに追加されます。このプロセスは、WebLogic リソースまたはリソース コンテナに適用されるセキュリティ ポリシーがすべて評価されるまで続行されます。ロールのリストは WebLogic Security フレームワークに返され、アクセス決定などの操作の一環として使用できるようになります。
ロール マッピング プロバイダによる動的ロール関連付けの結果、一連のロールが一度にサブジェクト内のプリンシパルに割り当てられます。その後、これらのロールを用いて、保護対象 WebLogic リソース、リソース コンテナ、およびアプリケーション コードについての認可判定が行われます。たとえば、エンタープライズ JavaBean (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)、サーブレット、エンタープライズ JavaBean (EJB)、リソース アダプタなどのアプリケーション コンポーネントが、エンタープライズ情報システム (EIS) (たとえば、Oracle、SQL Server などのリレーショナル データベース) にアクセスするために、適切なリソース コンテナを通じて WebLogic Security フレームワークを呼び出すと、資格マッピング プロセスが開始されます。呼び出しの中で、アプリケーション コンポーネントは、サブジェクト (「誰が」要求しているのか)、WebLogic リソース (「何を」要求しているのか)、および WebLogic リソースにアクセスするために必要な資格のタイプについての情報を渡します。WebLogic Security フレームワークは、資格に対するアプリケーション コンポーネントのリクエストを、アプリケーション コンポーネントが必要としている資格のタイプを処理するコンフィグレーション済み資格マッピング プロバイダに送信します。資格マッピング プロバイダは、そのデータベースを照会して、アプリケーション コンポーネントが要求しているものに一致する資格群を取得し、WebLogic Security フレームワークに資格を返します。WebLogic Security フレームワークは、リソース コンテナを通じて要求側のアプリケーション コンポーネントに資格を返します。アプリケーション コンポーネントは、資格を使用して外部システムにアクセスします。
証明書の検索と検証のプロセスでは、証明書パス ビルダ、証明書パス検証プロバイダ、証明書検索および検証 (CLV) フレームワークの 3 つが対話します。
証明書パス ビルダと、コンフィグレーションされているすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。
コンフィグレーションされているすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。エラーが発生した場合は検証が停止します。
SAML および Windows 統合ログイン機能は、WebLogic Server アプリケーションに Web ベースのシングル サインオン (SSO) 機能を提供します。以下の節では、シングル サインオンの間に行われる WebLogic コンテナ、セキュリティ プロバイダ、WebLogic Security フレームワークの間の対話について説明します。
次の節では、SAML 1.1 サービスでコンフィグレーションした場合の WebLogic Server インスタンスの動作について説明します。
SAML ソースとして動作するとは、以下の動作を意味します。
WebLogic Server は、SAML ITS および ARS として動作できます。これらのサービスはサーブレットにより提供されます。サーブレットは Administration Console の [サーバ｜コンフィグレーション｜フェデレーション サービス] ページのコンフィグレーション設定に基づいてデプロイされます。
SAML ITS サービスでは、V1 SAML プロバイダの POST とアーティファクト プロファイルのぞれぞれに別の URL が必要です。V2 SAML プロバイダの場合は POST とアーティファクト プロファイルに別個の URL を用意する必要はありません。
以下の節では、POST プロファイルおよびアーティファクト プロファイルで、WebLogic Server を SAML ソースとして使用する方法について説明します。
http://www.weblogic.com/samlits/its) にアクセスします。www.weblogic.com) にアクセスします。
セキュリティ レルムで認証メカニズムとして 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 プロファイルの仕組みは次のとおりです。
http://www.weblogic.com/samlits/its) にアクセスします。http://www.weblogic.com/samlits/its) にアクセスします。
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 に記載されている番号の説明は以下のとおりです。
サービス プロバイダは、認証リクエストの転送において次のバインディングのいずれかを使用するようにコンフィグレーションできます。
ID プロバイダは、次のバインディングを使用するようにコンフィグレーションできます。
ACS はアサーションを検証し、そのアサーションから ID 情報を抽出して、ローカル セキュリティ レルムのサブジェクトにその ID をマッピングします。
WebLogic Security サービスは、認可チェックを実行して、リクエストされたリソースにブラウザがアクセス可能かどうかを判別します。認可チェックに成功すると、リソースへのアクセスが許可されます。
WebLogic Server は、ID プロバイダによって Web シングル サインオン セッションが開始されるシナリオもサポートしています。このシナリオでは、ユーザは ID プロバイダによって認証され、サービス プロバイダによってホストされるリソースに対するリクエストを発行します。ID プロバイダは、サービス プロバイダが要求していない認証応答をサービス プロバイダに送信することによって SSO セッションを開始します。
サービス プロバイダは、認証応答を受信すると、アサーションからユーザ ID を抽出し、その ID をローカル サブジェクトにマッピングして、リクエストされたリソースに対する認可チェックを実行します。認可チェックに成功すると、アクセスが許可されます。
図 5-10 に、一般的な ID プロバイダ開始の SSO セッションの実行フローを示します。
実行フローを示す図 5-10 に記載されている番号の説明は以下のとおりです。
ユーザは、サービス プロバイダによってホストされるリソースに対するリクエストを発行します。
ID プロバイダは SSO セッションの開始方法に関係なく、「サービス プロバイダ開始のシングル サインオン」の手順 6 で説明したのと同じバインディングを使用します。
WWW-Authenticate および Authorization HTTP ヘッダをサポートするようにコンフィグレーションされています。このネゴシエート ID アサーション プロバイダが、サーブレット認証フィルタを使用して、ネゴシエート プロトコルの認可されていない応答に対して適切な WWW-Authenticate ヘッダを生成し、後続のリクエストで Authorization ヘッダを処理します。GET リクエストを送信します。WWW-Authenticate ヘッダとともに送り返します。WWW-Authenticate リクエスト ヘッダを追加し、WebLogic Security フレームワークに働きかけて初期ネゴシエート チャレンジを取得します。次のメッセージが送り返されます。
401 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate ヘッダを受信し、ネゴシエート認証スキームをサポートできるかどうかを判別します。そして、サポートする GSS メカニズム トークン タイプを含む SPNEGO トークンを作成します。このトークンを Base64 でエンコードし、元の GET メッセージの Authorization ヘッダを使用してアプリケーション サーバに返信します。次に例を示します。
GET...
Authorization: Negotiate <Base64 encoded SPNEGO token>
WebLogic Security フレームワークは、そのユーザが所属するグループも判別します。
WebLogic Web サービスと WebLogic Security フレームワークは、SAML 1.1 および 2.0 アサーションの生成、消費、および検証をサポートするように拡張されています。SAML アサーションを使用する場合は、Web サービスが SAML アサーションとそれに付随する証明データを WebLogic Security フレームワークに渡します。SAML アサーションが有効で信頼されれば、フレームワークが認証されたサブジェクトと信頼性のあるプリンシパルを Web サービスに返します。WebLogic Web サービスと WebLogic Security フレームワークでは、以下の SAML アサーションがサポートされます。
理論的には、アサーション側によって X.509 のパブリック証明書 (または他のキー情報) が SAML アサーションに挿入されます (厳密には、アサーション パーティによりキーがサブジェクトにバインドされます)。この組み込まれた証明書を保護するには、SAML アサーション自体がアサーティング エンティティによって署名されている必要があります。WebLogic Server の場合、SAML アサーションは Web サービス クライアントによって署名され、署名には Web サービス クライアントのプライベート キーが使用されます。つまり、アサーションの署名は SAML 権限の署名であり、アサーションに含まれる証明書やアサーションにより特定される証明書に基づくものではありません。
<SubjectConfirmationData> 要素に含まれている属性を使用して確認を行うためのオプション制約が適用される。
以下の節では、これらのアサーションを処理する方法について説明します。
すべての Sender-Vouches アサーションは基本的に同じで、信頼の確立方法 (転送に SSL を使用するかどうか、SAML アサーションとメッセージ本文が署名されるかどうか) だけが異なります。
Sender-Vouches アサーションは、次の方法で使用します。
Holder-of-Key アサーションでは、ユーザを信頼するかどうかを確認する上で、Web サービス クライアントが Web サービス サーバに依存します。
Holder-of-Key アサーションは、次の方法で使用します。
wsse:Security ヘッダに挿入します。メッセージ本文は、ユーザのプライベート キーで署名されます。
これが成功すると、Web サービス サーバでは holder-of-key アサーションのキーが実際にそのアサーションのサブジェクトに属していると見なせます。その結果、Web サービスでそのキーを使用して、SOAP メッセージの署名を検証できるようになります。これによって、SOAP メッセージがキーの保持者により生成され、送信されたことが認められます。X.509 証明書自体の信頼性の検証は Web サービス サーバに任されます。
Web サービス サーバによって、SAML アサーション用のプリンシパルを含むサブジェクトが Web サービス クライアントに返されます。
このアサーションでは、必要に応じて SSL プロトコルを使用できます。SSL プロトコルを使用する場合は、クライアント証明書も証明データとして使用できます。
WebLogic Server のこのリリースでのセキュリティは、一連のセキュリティ サービス プロバイダ インタフェース (SSPI) に基づいています。開発者およびサード パーティ ベンダは、SSPI を使用して WebLogic Server 環境向けのセキュリティ プロバイダを開発できます。SSPI は、認証、ID アサーション、認可、監査、裁決、ロール マッピング、資格マッピング、および証明書の検索と検証に利用可能です。
| 注意 : | キーストア プロバイダ用の SSPI はこのリリースの WebLogic Server では非推奨となっています。代わりに Java キーストア (JKS) を使用してください。Java キーストアの使い方については、『WebLogic Server のセキュリティ』の「プロダクション用のキーストアのコンフィグレーション」を参照してください。 |
SSPI を使用すると、カスタム セキュリティ プロバイダで WebLogic Server リソースを保護することができます。SSPI を使用してカスタム セキュリティ プロバイダを開発することも、サード パーティ ベンダからカスタム セキュリティ プロバイダを購入することもできます。
カスタム セキュリティ プロバイダの開発の詳細については、『WebLogic セキュリティ プロバイダの開発』を参照してください。
この節では、お使いの WebLogic Server 製品に付属しているセキュリティ プロバイダについて説明します。セキュリティ プロバイダは、WebLogic Server のセキュリティ レルムに「プラグイン」してアプリケーションにセキュリティ サービスを提供するためのモジュールです。セキュリティ プロバイダは、アプリケーションの代わりに WebLogic Security フレームワークに働きかけを行います。
WebLogic Server 製品に付属しているセキュリティ プロバイダがセキュリティ要件を完全に満たしていない場合には、カスタム セキュリティ プロバイダで補足するか、あるいはカスタム セキュリティ プロバイダに置き換えることができます。カスタム セキュリティ プロバイダは以下のようにして開発します。
詳細については、『WebLogic セキュリティ プロバイダの開発』を参照してください。
図 5-11 に、WebLogic セキュリティ レルムにおいて必須および省略可能なセキュリティ プロバイダを示します。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic 認証プロバイダが含まれています。WebLogic 認証プロバイダは、ユーザ名とパスワードの委託認証と WebLogic Server セキュリティのダイジェスト認証をサポートします。ユーザとグループの情報の格納には、組み込み LDAP サーバを利用します。このプロバイダを使用すると、ユーザとグループ メンバシップを編集、表示、および管理できます。
| 注意 : | WebLogic 認証プロバイダを WebLogic 認可プロバイダと組み合わせれば、WebLogic Server リリース 6.x で利用できたファイル レルムの機能の代わりになります。 |
WebLogic Server では、デフォルトのセキュリティ レルムにおいて、以下の認証プロバイダを WebLogic 認証プロバイダの代わりとして使用したり、WebLogic 認証プロバイダと併用したりできます。
| 注意 : | デフォルトでは、これらの認証プロバイダは使用可能ですが、WebLogic デフォルト セキュリティ レルムにはコンフィグレーションされていません。 |
WebLogic Server には、パスワード検証プロバイダが付属しており、このプロバイダが次に示す 1 つ以上の認証プロバイダでコンフィグレーションされていると、パスワード構成ルール セットを管理および適用することができます。
認証プロバイダでパスワード検証プロバイダがコンフィグレーションされている場合、認証プロバイダは、パスワードが作成または更新されると、パスワード検証プロバイダを呼び出します。呼び出されたパスワード検証プロバイダは、そのパスワードがコンフィグレーション可能な構成ルール セットに基づく条件を満たすかどうかを検証します。
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 サブジェクト確認メソッドがサポートされています。
SAML 2.0 ID アサーション プロバイダは、SAML 1.1 用の SAML ID アサーション プロバイダ V2 と同様に、SAML 2.0 アサーションを検証し、発行者が信頼されていることを確認します。信頼されていれば、アサーションに含まれる認証文に基づき、ID が断定されます。
プロバイダのコンフィグレーションには、SAML 2.0 サービス プロバイダ サービス (アサーション コンシューマ サービスやアーティファクト解決サービスなど) をコンフィグレーションしてサーバで実行できるようにするための設定が含まれています。
SAML 2.0 ID アサーション プロバイダでは、以下の SAML サブジェクト確認メソッドがサポートされています。
ネゴシエート ID アサーション プロバイダは、SPNEGO プロトコルをサポートする Microsoft クライアントでの SSO に使用します。具体的には、SPNEGO トークンをデコードして Kerberos トークンを入手し、この Kerberos トークンを検証して WebLogic ユーザにマップします。ネゴシエート ID アサーション プロバイダは、Kerberos を介した GSS のセキュリティ コンテキストの受け入れに Java GSS (Generic Security Service) API (Application Programming Interface) を利用します。Java GSS API の詳細については、http://java.sun.com/j2se/1.5.0/docs/guide/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 の詳細については、『WebLogic セキュリティ プロバイダの開発』の「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 Administration Console を使用して認可プロバイダを新しく追加する場合、新しいプロバイダを 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 裁決プロバイダはその設定に従って次のように動作します。
[完全一致の許可が必要] 属性を FALSE に変更した場合、WebLogic 裁決プロバイダは次のように動作します。
| 注意 : | [完全一致の許可が必要] 属性は、WebLogic 裁決プロバイダをコンフィグレーションするときに設定します。裁決プロバイダのコンフィグレーションの詳細については、『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 Administration Console を使用してロール マッピング プロバイダを新しく追加する場合、新しいプロバイダを 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 内に置かれます。
Administration Console の [フェデレーション サービス] コンフィグレーション ページに、SAML のソース サイトおよび送り先サイトの SSO サービス (ITS、ACS、ARS など) をコンフィグレーションし、サーバで実行するために有効化する設定があります。
SAML 資格マッピング プロバイダは、以下の SAML サブジェクト確認メソッドをサポートしています。
SAML 2.0 資格マッピング プロバイダは、ID プロバイダ サービスとサービス プロバイダ パートナのコンフィグレーションに基づく認証されたサブジェクトに対する SAML 2.0 アサーションを生成します。アサーションには認証文と、必要に応じて WebLogic Server のグループ情報を含む属性文が含まれます。要求された対象が、コンフィグレーションされておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザ情報およびグループ メンバシップは、(そのようにコンフィグレーションされた場合) AttributeStatement 内に置かれます。
Administration Console の SAML 2.0 用の [フェデレーション サービス] コンフィグレーション ページに、SAML 2.0 のソース サイトおよび送り先サイトのサービス (シングル サインオン、アーティファクト解決サービスなど) をコンフィグレーションし、サーバで実行するために有効化する設定があります。
SAML 資格マッピング プロバイダは、以下の SAML サブジェクト確認メソッドをサポートしています。
PKI (公開鍵インフラストラクチャ) 資格マッピング プロバイダは、WebLogic Server のサブジェクト (開始者) と対象リソース (および必要であれば資格アクション) を、対象リソースを使用する際にアプリケーションで使用するパブリック キーとプライベート キーのペアまたは公開証明書にマップします。このプロバイダを使用して、パブリック キーとプライベート キーのペアまたは公開証明書にエリアスをマップすることもできます。PKI 資格マッピング プロバイダは、サブジェクトとリソース名 (またはエリアス) を使用して対応する資格をキーストアから検索します。
WebLogic 証明書パス プロバイダは、証明書パス ビルダと証明書パス検証プロバイダの両方です。証明書パス プロバイダは、証明書のパスを完了させ、特定のサーバ インスタンスのためにコンフィグレーションされた信頼性のある CA を使用して証明書を検証します。完了できない証明書チェーンは無効になります。
また、WebLogic 証明書パス プロバイダは、チェーン内の署名をチェックして、チェーンが期限切れでないことを確認し、チェーン内のいずれかの証明書が、サーバ用にコンフィグレーションされた信頼性のある CA によって発行されたものであることを確認します。いずれかのチェックが失敗した場合、そのチェーンは有効ではありません。
最後に、プロバイダは、各証明書の基本的な制約 (証明書が他の証明書を発行できるかどうか) をチェックし、証明書がチェーン内の適切な場所にあることを確認します。
WebLogic 証明書パス プロバイダは、セキュリティ レルム内の証明書パス ビルダまたは証明書パス検証プロバイダとして使用できます。
証明書レジストリを使用すると、システム管理者はサーバへのアクセスが許可されている信頼性のある CA 証明書のリストを明示的にコンフィグレーションできます。証明書レジストリは、失効チェックを実行するための、費用のかからないメカニズムを提供します。管理者は、証明書レジストリから削除することによって、証明書を無効にします。このレジストリは、組み込み LDAP サーバに格納されます。
証明書レジストリは、サーバ単位ではなくドメイン単位でコンフィグレーションします。
証明書レジストリは、証明書パス ビルダと証明書パス検証プロバイダの両方です。どちらの場合でも、証明書レジストリは、チェーンの目的の証明書がレジストリに格納されていることを検証します。
バージョン管理可能なアプリケーションは、アプリケーション アーカイブ (EAR ファイル) のマニフェスト内で指定されているアプリケーション アーカイブのバージョンを持つアプリケーションです。バージョン管理可能なアプリケーションは side-by-side でデプロイでき、同時にアクティブにすることが可能です。バージョン管理可能なアプリケーションを使用すると、アプリケーションの複数のバージョンを利用できます。各バージョンには、個別のセキュリティ制約を設定できます。
バージョン管理可能なアプリケーションのプロバイダ SSPI を使用すると、バージョンが作成および削除されたときに、アプリケーションのバージョン管理をサポートするすべてのセキュリティ プロバイダに通知できます。また、バージョンが 1 つしかないアプリケーションが削除された場合にも、アプリケーションのバージョン管理をサポートするすべてのセキュリティ プロバイダに通知できます。
WebLogic キーストア プロバイダでは、Sun Microsystems から Java Software Development Kit (SDK) の形で提供されるキーストアの参照実装を使用します。そこでは標準の Java キーストア (JKS) キーストア タイプが利用されますが、これはキーストアをファイル (マシンごとに 1 つ) として実装したものです。各プライベート キーはそれぞれのパスワードで保護されます。WebLogic キーストア プロバイダに関連付けられているキーストア ファイルは 2 つあります。
keytool ユーティリティか WebLogic Server の ImportPrivateKey ユーティリティを利用すれば、このファイルにプライベート キーを追加することができます。なお、WebLogic Server では、このキーストア ファイルからプライベート キーと証明書を取得できます。| 注意 : | WebLogic キーストア プロバイダはこのリリースの WebLogic Server では非推奨となっていますが、引き続きサポートされています。カスタム キーストア プロバイダの開発はサポートされていません。代わりに Java キーストア (JKS) を使用してください。WebLogic キーストア プロバイダによってサポートされていたすべての機能は、Java キーストアを使用することで利用できます。WebLogic キーストア プロバイダは、下位互換性を保持するためにのみサポートされています。WebLogic キーストア プロバイダは、WebLogic Server 7.0 コンフィグレーションと下位互換性を保持する必要がある場合にのみ使用することをお勧めします。Java キーストアの使い方については、『WebLogic Server のセキュリティ』の「プロダクション用のキーストアのコンフィグレーション」を参照してください。 |
WebLogic レルム アダプタ プロバイダは、既存のバージョン 6.x セキュリティ レルムを WebLogic Server のこのリリースのセキュリティ機能と併用できるようにすることで、バージョン 6.x WebLogic セキュリティ レルムとの下位互換性を提供するものです。WebLogic レルム アダプタ プロバイダは、WebLogic Server 6.x で使用されるレルム API (weblogic.security.acl) を WebLogic Server のこのリリースで使用される API にマップします。以下の WebLogic レルム アダプタ プロバイダが提供されています。
レルム アダプタ認証プロバイダを利用すれば、バージョン 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 Administration Console を使ってコンフィグレーションされますが、既存の 6.x セキュリティ レルムでは WebLogic Server 6.1 に存在するのと同じ MBean とユーザ インタフェースを引き続き使用することになります。
| 注意 : | WebLogic レルム アダプタ プロバイダは非推奨になったため、このリリースの WebLogic Server で使用できるセキュリティ モデルにアップグレードする間だけ使用してください。 |
  
|