Oracle® Fusion Middleware Oracle WebLogic Server Security について 11g リリース 1 (10.3.1) B55519-01 |
|
![]() 戻る |
![]() 次へ |
この節では、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 インタフェースの実装を使用するかのいずれかの方法があります。 |
図 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 リソース、リソース コンテナ、およびアプリケーション コードについての認可判定が行われます。たとえば、エンタープライズ 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 つが対話します。
次に、証明書チェーンの作成プロセスを示します。
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 として動作できます。これらのサービスはサーブレットにより提供されます。サーブレットは Administration Console の [サーバ|コンフィグレーション|フェデレーション サービス] ページのコンフィグレーション設定に基づいてデプロイされます。
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 を基にアーティファクトが生成されます (この値は [フェデレーション サービス|SAML 1.1 ソース サイト] ページでコンフィグレーションされている [ソース サイト 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 を含むクッキーを渡して、リクエストされたリソースにブラウザがアクセスできるようにします。
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 を含むクッキーを渡して、リクエストされたリソースにブラウザがアクセスできるようにします。
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 Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発』を参照してください。
この節では、お使いの WebLogic Server 製品に付属しているセキュリティ プロバイダについて説明します。セキュリティ プロバイダは、WebLogic Server のセキュリティ レルムに「プラグイン」してアプリケーションにセキュリティ サービスを提供するためのモジュールです。セキュリティ プロバイダは、アプリケーションの代わりに WebLogic Security フレームワークに働きかけを行います。
WebLogic Server 製品に付属しているセキュリティ プロバイダがセキュリティ要件を完全に満たしていない場合には、カスタム セキュリティ プロバイダで補足するか、あるいはカスタム セキュリティ プロバイダに置き換えることができます。カスタム セキュリティ プロバイダは以下のようにして開発します。
weblogic.security.spi
パッケージから適切なセキュリティ サービス プロバイダ インタフェース (SSPI) を実装してセキュリティ プロバイダの実行時クラスを作成する。
MBean 定義ファイル (MDF) を作成し、WebLogic MBeanMaker ユーティリティを使用して MBean タイプを生成する。MBean タイプは、セキュリティ プロバイダのコンフィグレーションと管理に使用します。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発』を参照してください。
図 5-11 に、WebLogic セキュリティ レルムにおいて必須および省略可能なセキュリティ プロバイダを示します。
以下の節では、セキュリティ プロバイダについて説明します。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic 認証プロバイダが含まれています。WebLogic 認証プロバイダは、ユーザ名とパスワードの委託認証と WebLogic Server セキュリティのダイジェスト認証をサポートします。ユーザとグループの情報の格納には、組み込み LDAP サーバを利用します。このプロバイダを使用すると、ユーザとグループ メンバシップを編集、表示、および管理できます。
注意 : WebLogic 認証プロバイダを WebLogic 認可プロバイダと組み合わせれば、WebLogic Server リリース 6.x で利用できたファイル レルムの機能の代わりになります。 |
WebLogic Server では、デフォルトのセキュリティ レルムにおいて、以下の認証プロバイダを WebLogic 認証プロバイダの代わりとして使用したり、WebLogic 認証プロバイダと併用したりできます。
Open LDAP、Netscape iPlanet、Microsoft Active Directory、および Novell NDS といった外部 LDAP ストアにアクセスする一連の LDAP 認証プロバイダ。
認証を行うために、データベースに格納されているユーザ、パスワード、グループ、およびグループ メンバシップ情報にアクセスする一連のデータベース管理システム (DBMS) プロバイダ。必要に応じて、WebLogic Server を使用してユーザ、パスワード、グループ、およびグループ メンバシップ情報を管理できます。DBMS 認証プロバイダは、RDBMS セキュリティ レルムからのアップグレード パスです。
以下の DBMS 認証プロバイダを使用できます。
SQL 認証プロバイダ - ユーザ、パスワード、グループ、およびグループ メンバシップ情報の表示や編集をサポートする管理可能な認証プロバイダ。
読み込み専用 SQL 認証プロバイダ - WebLogic Server Administration Console を使用したデータベース内のユーザの認証およびデータベースのコンテンツの表示をサポートする認証プロバイダ。この認証プロバイダは特定の SQL 文のセットを必要とするため、すべてのニーズには対応できない可能性があります。
カスタム DBMS 認証プロバイダ - 認証をサポートするだけの実行時認証プロバイダ。このプロバイダでは、データベースに問い合わせて認証情報を取得するためのコードをユーザが記述する必要があります。DBMS 認証プロバイダを特殊なデータベース ニーズに適合させるための柔軟な認証プロバイダです。
認証を行うために Windows NT ユーザおよびグループを使用する Windows NT 認証プロバイダ。Windows NT 認証プロバイダは、Window NT セキュリティ レルムのアップグレード パスです。WebLogic Server Administration Console では、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://java.sun.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 Fusion Middleware 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 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 裁決プロバイダはその設定に従って次のように動作します。
すべての認可プロバイダのアクセス決定が PERMIT
を返した場合、最終的な判定として TRUE
を返す (つまり WebLogic リソースへのアクセスは許可されます)。
一部の認可プロバイダのアクセス決定が PERMIT
を返し、その他が ABSTAIN
を返した場合、FALSE
を返す (つまり WebLogic リソースへのアクセスは拒否されます)。
いずれかの認可プロバイダのアクセス決定が ABSTAIN
または DENY
を返した場合、最終的な判定として FALSE
を返す (つまり WebLogic リソースへのアクセスは拒否されます)。
[完全一致の許可が必要] 属性を FALSE
に変更した場合、WebLogic 裁決プロバイダは次のように動作します。
すべての認可プロバイダのアクセス決定が PERMIT
を返した場合、最終的な判定として TRUE
を返す (つまり WebLogic リソースへのアクセスは許可されます)。
一部の認可プロバイダのアクセス決定が PERMIT
を返し、その他が ABSTAIN
を返した場合、最終的な判定として TRUE
を返す (つまり WebLogic リソースへのアクセスは許可されます)。
いずれかの認可プロバイダのアクセス決定が DENY
を返した場合、最終的な判定として FALSE
を返す (つまり WebLogic リソースへのアクセスは拒否されます)。
注意 : [完全一致の許可が必要] 属性は、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 サブジェクト確認メソッドをサポートしています。
artifact
bearer
sender-vouches
holder-of-key
SAML 2.0 資格マッピング プロバイダは、ID プロバイダ サービスとサービス プロバイダ パートナのコンフィグレーションに基づく認証されたサブジェクトに対する SAML 2.0 アサーションを生成します。アサーションには認証文と、必要に応じて WebLogic Server のグループ情報を含む属性文が含まれます。要求された対象が、コンフィグレーションされておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザ情報およびグループ メンバシップは、(そのようにコンフィグレーションされた場合) AttributeStatement 内に置かれます。
Administration Console の 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 キーストア プロバイダでは、Sun Microsystems から Java Software Development Kit (SDK) の形で提供されるキーストアの参照実装を使用します。そこでは標準の Java キーストア (JKS) キーストア タイプが利用されますが、これはキーストアをファイル (マシンごとに 1 つ) として実装したものです。各プライベート キーはそれぞれのパスワードで保護されます。WebLogic キーストア プロバイダに関連付けられているキーストア ファイルは 2 つあります。
一方のキーストア ファイルには信頼性のある認証局 (CA) 証明書が記載されている。WebLogic Server には信頼性のある認証局キーストア ファイルが付属しており、WebLogic Server はデフォルトではそれを使用して、SSL で使用される信頼性のある CA 証明書を見つけ、クライアント証明書が正しいかどうかを確認します。
もう一方のキーストア ファイルには、サーバのプライベート キーが記載されている。WebLogic Server はこのファイルからプライベート キーを取得して SSL を初期化します。Sun Microsystems SDK の keytool
ユーティリティか WebLogic Server の ImportPrivateKey
ユーティリティを利用すれば、このファイルにプライベート キーを追加することができます。なお、WebLogic Server では、このキーストア ファイルからプライベート キーと証明書を取得できます。
注意 : WebLogic キーストア プロバイダはこのリリースの WebLogic Server では非推奨となっていますが、引き続きサポートされています。カスタム キーストア プロバイダの開発はサポートされていません。代わりに Java キーストア (JKS) を使用してください。WebLogic キーストア プロバイダによってサポートされていたすべての機能は、Java キーストアを使用することで利用できます。WebLogic キーストア プロバイダは、下位互換性を保持するためにのみサポートされています。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 Administration Console を使ってコンフィグレーションされますが、既存の 6.x セキュリティ レルムでは WebLogic Server 6.1 に存在するのと同じ MBean とユーザ インタフェースを引き続き使用することになります。
注意 : WebLogic レルム アダプタ プロバイダは非推奨になったため、このリリースの WebLogic Server で使用できるセキュリティ モデルにアップグレードする間だけ使用してください。 |