認証
Liberty セキュリティーの認証では、ユーザーの ID を確認します。
保護された Web リソースにアクセスするには、ユーザーは、ユーザー ID とパスワードなどのクレデンシャル・データを提供する必要があります。認証プロセスでは、このユーザー・クレデンシャル情報を (このデータの収集に関する Web アプリケーションでの構成設定に基づいて) 収集し、構成されているレジストリーと照合してそれを検証します。 クレデンシャル情報が検証されると、そのユーザーに対して JAAS サブジェクトが作成されます。サブジェクトには、ユーザーの追加情報 (所属グループ、そのユーザー用に作成されたトークンなど) が含まれています。 このサブジェクト内の情報は、その後、ユーザーがリソースにアクセスできるかどうかを判別するために許可プロセスで使用されます。
次の図は、Web リソースの標準的な認証プロセスのフローを示しています。

認証プロセスでは、ユーザーからクレデンシャル・データを収集し、 キャッシュを検査してそのユーザーのサブジェクトが存在するかどうかを確認して、 なければ JAAS サービスを呼び出して認証を実行し、サブジェクトを作成します。 JAAS サービスは、ログイン・モジュールのセットを呼び出して認証を処理します。 クレデンシャル・データに応じて、1 つ以上のログイン・モジュールが、サブジェクトを作成します。 その後、ログイン・モジュールは、構成されているレジストリーを呼び出して、クレデンシャル情報を検証します。 検証が成功したら、認証プロセスはそのユーザーの関連情報 (所属グループ、シングル・サインオン (SSO) 機能用の SSO トークンなど) の収集と作成を行い、 サブジェクトに関連クレデンシャルとしてそれらを格納します。 このプロセスの間にカスタム・ログイン・モジュールをプラグインして、サブジェクトに保存される情報をカスタマイズすることも可能です。
ユーザー・レジストリー
ユーザーの認証データを検証する際、 ログイン・モジュールは、構成されているユーザー・レジストリーを呼び出してユーザー情報を検証します。 Liberty では、単純な構成ベースのユーザー・レジストリーと、より堅固な LDAP ベースのレジストリーの両方がサポートされています。詳しくは、『Liberty のユーザー・レジストリーの構成』を参照してください。
LDAP レジストリーを使用する場合は、複数のリポジトリーを統合して、2 つ以上のレジストリーで LDAP 操作を実行することも可能です。 Liberty ユーザーは、LDAP レジストリー・フェデレーション・フィーチャーを server.xml ファイルで直接構成することも、開発者ツールの「LDAP レジストリーのフェデレーション」セクションで構成することもできます。 統合リポジトリーの構成後は、実行するどの操作に対しても、統合リポジトリーの集約された結果を得ることができます。 例えば、test で始まる検索操作をすべてのユーザー名に対して実行する場合、 一連の LDAP レジストリー全体で検索を実行して集約された検索結果を取得することができ、呼び出し側のプログラムにその結果が返されます。
認証キャッシュ
サブジェクトの作成は比較的コストが高いため、Liberty は、ユーザーの認証が成功した後にサブジェクトを保管する認証キャッシュを用意しています。キャッシュのデフォルトの有効期限は 10 分です。ユーザーが 10 分以内に再びログインしないと、サブジェクトは削除され、 そのユーザーのサブジェクトを作成するために認証プロセスが再度行われます。 ログイン・モジュールの追加や LTPA 鍵の変更など、サブジェクトの作成に影響する構成の変更が行われると、認証キャッシュはクリアされます。 サブジェクトがキャッシュに入れられていて、レジストリー内の情報が変更された場合は、レジストリー内の情報を使用してキャッシュが更新されます。キャッシュのタイムアウト期間とキャッシュ・サイズは構成可能で、キャッシングを有効または無効にすることもできます。 詳細については、『Liberty での認証キャッシュの構成』を参照してください。
JAAS 構成
- system.WEB_INBOUND
- サーブレットや JSP などの Web リソースにアクセスする際に使用されます。
- WSLogin
- プログラマチック・ログインの使用時にアプリケーションによって使用されます。また、アプリケーション・クライアント・コンテナーで実行されているアプリケーションによっても使用されますが、ClientContainerJAAS 構成とは異なり、クライアント・アプリケーション・モジュールのデプロイメント記述子に指定されている CallbackHandler ハンドラーを認識しません。
- system.DEFAULT
- JAAS 構成が指定されていない場合にログインで使用されます。
- system.DESERIALIZE_CONTEXT
- セキュリティー・コンテキストのデシリアライズ時に使用されます。この JAAS 構成は、セキュリティー・コンテキストのシリアライズ時にスレッドでアクティブであったサブジェクトを再作成するための認証を処理します。 server.xml ファイルの JAAS 構成項目を編集することで、この JAAS 構成を指定し、独自のカスタム JAAS ログイン・モジュールを追加できます。これにより、伝搬されるサブジェクトにカスタム情報が確実に含まれるようになります。
- ClientContainer
- アプリケーション・クライアント・コンテナーで実行されているアプリケーションによって使用されます。 この JAAS ログイン構成は、クライアント・アプリケーション・モジュールのデプロイメント記述子に指定された CallbackHandler ハンドラーを (指定されていれば) 認識します。
カスタム・ログイン・モジュールでカスタマイズする場合を除き、 明示的な構成は必要ありません。要件に応じて、特定のログイン構成をカスタマイズすることができます。 例えば、すべての Web リソース・ログインをカスタマイズする場合には、カスタム・ログイン・モジュールを system.WEB_INBOUND 構成にのみ追加してください。『Liberty の JAAS カスタム・ログイン・モジュールの構成』を参照してください。
JAAS ログイン・モジュール
JAAS 構成は、サブジェクトを作成するためにログイン・モジュールのセットを使用します。Liberty には、ログイン構成ごとにログイン・モジュールのセットが用意されています。認証データに応じて、特定のログイン・モジュールがサブジェクトを作成します。 認証データは、JAAS 仕様の規定に従い、コールバック・ハンドラーを使用してログイン・モジュールに渡されます。例えば、認証にユーザー ID とパスワードのコールバック・ハンドラーが使用されている場合、 userNameAndPassword ログイン・モジュールが認証を処理します。 認証データとして SingleSignonToken クレデンシャルが提示された場合には、token ログイン・モジュールのみが認証を処理します。
- userNameAndPassword
- 認証データとしてユーザー名とパスワードが使用された場合に、認証を処理します。
- certificate
- 相互 SSL 認証データとして X509 証明書が使用された場合に、認証を処理します。
- token
- 認証データとして SSO トークンが提示された場合に、認証を処理します。 認証プロセスの間に SSO トークンが作成され、Cookie で HTTP クライアント (ブラウザー) に送り返されます。シングル・サインオンが有効な場合、それ以降の要求では、ブラウザーがこの Cookie を送り返し、サーバーは、Cookie からトークンを抽出してユーザーを認証します。
- hashtable
- 認証データが事前定義のハッシュ・テーブルにより送信される場合に使用します。ハッシュ・テーブル・ログインについて詳しくは、ハッシュ・テーブル・ログイン・モジュールを参照してください。認証が ID のみを使用して実行される場合にも、セキュリティー・ランタイムによってこのログイン・モジュールが使用されます (例えば、runAs の場合)。
- proxy
- これは、WSLogin のデフォルト・ログイン・モジュールです。 『プロキシー・ログイン・モジュール』を参照してください。
ログイン・モジュールは、 構成された順序で呼び出されます。デフォルトの順序は hashtable、userNameAndPassword、certificate、token です。 カスタム・ログイン・モジュールを使用してログイン・プロセスをカスタマイズする必要がある場合には、 カスタム・ログイン・モジュールを提供し、必要な順序で構成します。 一般的には、カスタム・ログイン・モジュールは、最初に呼び出されるように、ログイン・モジュール・リストの先頭に配置します。 カスタム・ログイン・モジュールを使用する場合には、 必要な順序でのカスタム・ログイン・モジュールのほかに、ログイン・モジュールのすべての情報を構成に指定する必要があります。
ログイン・モジュールが認証を処理できると判断すると、 まず、渡された認証データが有効であるかを確認します。 例えば、ユーザー名とパスワードの認証の場合には、 構成されたユーザー・レジストリーを呼び出して認証情報を検証します。 トークンの認証の場合、検証が成功するためにはトークンが暗号化解除されて有効でなければなりません。
認証データが検証されると、 ログイン・モジュールは、ユーザーの追加データ (グループや SSO トークンなど) を使用してクレデンシャルを作成します。 カスタム・ログイン・モジュールでは、独自のクレデンシャルを作成することで、サブジェクトに追加データを加えることができます。 Liberty の許可が機能するには、サブジェクトには、WSCredential、WSPrincipal、および SingleSignonToken のクレデンシャルが含まれている必要があります。WSCredential クレデンシャルには、セキュリティー・ランタイム環境で必要な追加情報に加えて、グループ情報が含まれます。
コールバック・ハンドラー
Liberty では、JAAS 認証プロセスの間にログイン・モジュールにデータを提供するための各種コールバック・ハンドラーがサポートされています。コールバック・ハンドラーの情報を使用して、そのコールバック・ハンドラー自体を認証できます。 例えば、コールバック・ハンドラーが HttpServletRequest オブジェクト内の情報にアクセスする必要がある場合には、 その特定のコールバック・ハンドラーを使用してこれを行います。
- com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl
- com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory
『システム・ログイン構成用の JAAS カスタム・ログイン・モジュールの開発』を参照してください。
クレデンシャルおよびトークン
『loginModule のセクション』で説明したように、クレデンシャルはサブジェクト作成プロセスの中で作成されます。 Liberty は WSCredential、SingleSignonToken、および WSPrincipal の各クレデンシャルを作成します。SingleSignonToken クレデンシャルには、SSO が機能するために Cookie でブラウザーに返送されたトークンが含まれます。このトークンには、ユーザー情報と有効期限が含まれています。これには、最初のサーバー起動時に生成された Lightweight Third Party Authentication (LTPA) 鍵を使用して署名と暗号化が行われています。 デフォルトの有効期限は 2 時間で、これは絶対時間です (ユーザー・アクティビティーには基づきません)。 2 時間が経過すると、トークンの有効期限が切れるため、ユーザーは、そのリソースにアクセスするために再度ログインする必要があります。
LTPA
LTPA は、分散した複数のアプリケーション・サーバー環境を対象としています。 Liberty では、LTPA は分散環境の SSO とセキュリティーを暗号化によりサポートします。このサポートにより、LTPA で、 認証関連のデータを暗号化およびデジタル署名して安全に伝送し、 後で署名を暗号化解除して検証することが可能になります。
アプリケーション・サーバーは、LTPA プロトコルを使用して安全に通信することができます。 プロトコルには、SSO フィーチャーも提供されます。これにより、ユーザーは、ドメイン・ネーム・システム (DNS) に接続する際に認証するだけで済みます。その後、ユーザーは、プロンプトを出されることなく、同じドメイン内の他の Liberty サーバーのリソースにアクセスできます。DNS ドメインの各システムにあるレルム名は大/小文字が区別され、完全に一致している必要があります。
LTPA プロトコルは、暗号鍵を使用して、サーバー間で受け渡しされるユーザー・データを暗号化したり、暗号化を解除したりします。 これらの鍵は、1 つのサーバー内のリソースが別のサーバー内のリソースにアクセスする際に、 関連のあるサーバーがすべて同じユーザー・レジストリーを使用していることを前提として、 それぞれ異なるサーバーの間で共有される必要があります。サーバーに関係なくユーザーとグループを同じものにできるように、LTPA では、構成済みのユーザー・レジストリーが、集中共有リポジトリーでなければなりません。
LTPA を使用すると、 ユーザー情報と有効期限を含むトークンが作成され、鍵によって署名されます。 LTPA トークンは時間に依存します。 関与するすべてのサーバーで、時間と日付を同期する必要があります。 同期させないと、LTPA トークンは期限前に失効し、認証または検証で障害が発生します。 デフォルトでは協定世界時 (UTC) が使用され、他のすべてのサーバーも同じ UTC 時刻にする必要があります。 複数のサーバーで UTC 時刻を同じにする方法については、オペレーティング・システムの資料を参照してください。
SSO が有効な場合、LTPA トークンは、Web リソースの Cookie により他のサーバーに渡されます。
受信サーバーが発信サーバーと同じ鍵を使用する場合は、 トークンを暗号化解除してユーザー情報を取得することができます。 次にこの情報を検証して、トークンが期限切れでないことと、 トークン内のユーザー情報がそのレジストリー内で有効であることを確認します。 検証が正常に終了したら、受信サーバー内のリソースに、許可検査後にアクセスすることができます。
各サーバーには、有効なクレデンシャルが必要です。 クレデンシャルの有効期限が切れた場合、サーバーは認証のためにユーザー・レジストリーに通信する必要があります。 LTPA トークンをキャッシュに維持する時間を延長すると、セキュリティー・ポリシーの定義で考慮するセキュリティー・リスクが若干高まることになります。
異なる Liberty サーバー間で鍵の共有が必要な場合は、サーバー間でそれらの鍵をコピーしてください。セキュリティー上の目的で、鍵はランダム生成鍵で暗号化され、鍵を保護するためにユーザー定義のパスワードが使用されます。 鍵を別のサーバーにインポートする場合は、これと同じパスワードが必要になります。 パスワードは、鍵を保護するためにのみ使用され、鍵の生成には使用されません。
セキュリティーが有効な場合、LTPA は、Liberty サーバーの始動時にデフォルトで構成されます。LTPA のサポートについて詳しくは、Liberty での LTPA の構成を参照してください。
OpenID
OpenID は、ユーザーが複数のアカウントや資格情報セットを管理することなく、複数のエンティティーに対して自身を認証できるようにするオープン・スタンダードです。Liberty は、リライング・パーティーとして機能することによって、OpenID Authentication 2.0 規格をサポートしています。この規格では、リライング・パーティーは OpenID プロバイダーからの認証確認を必要とします。ユーザーは、リライング・パーティーに資格情報を提供せずに、OpenID プロバイダーにリダイレクトされ、そのプロバイダーに資格情報を送信します。OpenID プロバイダーは、リライング・パーティーで認証結果を確認し、多くの場合、ユーザーが承認済みの個人情報 (ユーザーの名前や E メール・アドレスなど) のサブセットに加えて、ユーザーが所有する固有 ID を返します。リライング・パーティーは、その後、この情報を使用して認証を完了できるため、ユーザーの資格情報を取り扱う必要がありません。さらに、1 つの OpenID プロバイダーでは単一のアカウントを使用して、リライング・パーティーとして機能する任意のエンティティーを使用して自身を認証することができるため、エンティティーごとに固有のアカウントを管理したり作成したりする必要性がなくなります。
OpenID について詳しくは、 OpenIDを参照してください。Liberty サーバーでの OpenID の構成については、Liberty での OpenID リライング・パーティーの構成を参照してください。
OpenID Connect
OpenID Connect は、シンプルな ID プロトコルであり、OAuth 2.0 プロトコルに構築されたオープン・スタンダードです。OpenID Connect によって、クライアント・アプリケーションは、OpenID Connect プロバイダーが実行する認証を利用してユーザーの ID を検証できます。
クライアント・アプリケーションは、OpenID Connect プロバイダーから相互運用可能な REST のような方法で、エンド・ユーザーに関する基本プロファイル情報を取得することもできます。OpenID Connect サポートは、OpenID Connect 規格 v1.0 に基づいています。
OpenID Connect について詳しくは、『OpenID Connect 』を参照してください。Liberty サーバーでの OpenID Connect クライアント (つまりリライング・パーティー) の構成については、Liberty での OpenID Connect クライアントの構成を参照してください。Liberty サーバーでの OpenID Connect プロバイダーの構成については、Liberty での OpenID Connect プロバイダーの構成を参照してください。
SPNEGO
Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) により、ユーザーが Microsoft ドメイン・コントローラーに 1 回ログインすると、再度プロンプトを出されることなく、Liberty サーバー上の保護アプリケーションにアクセスできるようになります。
SPNEGO Web 認証が有効になっている場合に、ブラウザー・クライアントが Liberty サーバー上の保護リソースにアクセスすると、SPNEGO が、HTTP 要求で指定された保護リソースへのアクセスの認証を処理します。ブラウザー・クライアントが SPNEGO トークンを作成し、そのトークンを HTTP 要求の一部として Liberty サーバーに送信します。WebSphere Application Server が SPNEGO トークンを検証し、そのトークンからユーザー ID を取得します。この ID は、ユーザーとアプリケーション・サーバー間でセキュア・コンテキストを確立するために使用されます。
SPNEGO について詳しくは、SPNEGO Web 認証を使用した HTTP 要求のシングル・サインオンを参照してください。Liberty サーバーでの SPNEGO の構成について詳しくは、Liberty での SPNEGO 認証の構成を参照してください。
SPNEGO のための Kerberos 制約付き委任
Kerberos 制約付き委任フィーチャーは、.NET サーバーやその他の Liberty サーバーなど、SPNEGO 認証をサポートするバックエンド・サービス用のアウトバウンド SPNEGO トークンの作成に使用される 2 つの API を提供します。
- S4U2self
Liberty サーバーがユーザーの代わりにそれ自体へのサービス・チケットを取得できるようにします。これは、Liberty でサポートされる任意の形式の認証で使用できます。 S4U2self は、「Kerberos プロトコル遷移」拡張機能です。
- S4U2proxy
Liberty サーバーがユーザーの代わりにトラステッド・サービスへのサービス・チケットを取得できるようにします。これらのサービス・チケットは、 Liberty サービスへのユーザーのサービス・チケットを使用して取得されます。サービスは、Kerberos 鍵配布センター (KDC) 管理者によって制約されます。 S4U2proxy は、「Kerberos 制約付き委任」拡張機能です。
シングル・サインオン (SSO)
SSO により、ユーザーが 1 つの場所 (例えば、1 つのサーバー) にログインすると、プロンプトを再度表示されることなく、他のサーバーのアプリケーションにアクセスできるようになります。SSO が機能するためには、異なる Liberty サーバー間で LTPA 鍵を交換すること、ユーザー・レジストリーが同じであること、トークンが期限切れでないことが必要です。LTPA 鍵を交換するには、ltpa.keys ファイルをサーバー間でコピーし、新しい LTPA 鍵を使用するためにサーバーを再始動します。 SSO ドメインに参加するすべてのサーバーで使用するレジストリーは、同じでなければなりません。
1 つの Liberty サーバーでユーザーが認証されると、認証プロセスでこのユーザー用に作成された SSO トークンが Cookie に書き込まれ、ブラウザーなどの HTTP クライアントに送信されます。そのクライアントから、別のサーバー上だが、最初のサーバー内の SSO 構成の中で構成された DNS ドメインと同じ DNS ドメイン内にある別のアプリケーション・セットにアクセスするように求める別の要求があると、要求と一緒に Cookie が送信されます。受信サーバーは、Cookie 内のトークンを使用してユーザーの認証を試行します。 両方の条件が満たされると、受信サーバーはトークンを検証し、ユーザーに再度ログインするように求めるプロンプトを出さずに、そのユーザーに基づくサブジェクトをこのサーバーに作成します。トークンを検証できない (例えば、LTPA 鍵が不一致のためにトークンの暗号化解除および検証ができない) 場合、ユーザーはクレデンシャル情報の再入力を求められます。
Form-login 属性を使用するように構成されているアプリケーションには、そのサーバー用に SSO が構成されている必要があります。 ユーザーが form-login に対して認証されると、トークンがブラウザーに送り返され、 リソースにアクセスする際のユーザーの許可に使用されます。
『Liberty での LTPA Cookie を使用した SSO 構成のカスタマイズ』を参照してください。
SAML Web ブラウザー SSO
SAML Web ブラウザー SSO により、Web アプリケーションは、構成されているユーザー・レジストリーではなく SAML ID プロバイダーにユーザー認証を委任できるようになります。
Liberty サーバーでの SAML Web ブラウザー SSO の構成について詳しくは、SAML 2.0 Web ブラウザー・シングル・サインオンを参照してください。
プラグ可能認証
- カスタム・ログイン・モジュールの提供。 認証プロセスのほとんどは JAAS ログイン・モジュールに基づいて構築されています。そのため、Liberty で提供されているログイン・モジュールの前、後、または間にカスタム・ログイン・モジュールをプラグインできます。『Liberty の JAAS カスタム・ログイン・モジュールの構成』を参照してください。
- すべての Web リソース・ベース認証を処理するトラスト・アソシエーション・インターセプター (TAI) の実装。 『Liberty のカスタム TAI の開発』を参照してください。
JAAS ログイン・モジュールおよび TAI について詳しくは、『Advanced authentication in WebSphere Application Server』を参照してください。
ID アサーション
要求側エンティティーに ID を証明するように求める認証に加えて、Liberty では、ID アサーションもサポートされます。これは、緩和された形式の認証であり、ID の証明を要求せず、表明された ID を証明するエンティティーとの信頼関係に基づいて ID を受け入れます。
- ハッシュ・テーブル・ログインの使用。『システム・ログイン構成用の JAAS カスタム・ログイン・モジュールの開発』を参照してください。
- IdentityAssertionLoginModule の使用。アプリケーションまたはシステム・プロバイダーに、信頼性検証付きの ID の表明を
許可することができます。IdentityAssertionLoginModule を使用するには、JAAS ログイン・フレームワークを使用します。このフレームワークでは、信頼性検証が 1 つのカスタム・ログイン・モジュールで実行され、クレデンシャルの作成が IdentityAssertionLoginModule で実行されます。この 2 つのログイン・モジュールを使用して、ID の表明に使用できる JAAS ログイン構成を作成できます。
以下の 2 つのカスタム・ログイン・モジュールが必要です。『JAAS を使用した ID アサーションを実行するためのアプリケーション・ログインのカスタマイズ』を参照してください。
- ユーザーが実装したログイン・モジュール (信頼性検証)
- ユーザーが実装したログイン・モジュールは、信頼性検証でユーザーが必要とするものすべてを実行します。
信頼性が検証されたら、
クレデンシャル作成ログイン・モジュールがその情報を使用できるように、ログイン・モジュールの共有状態の中のマップに、
信頼性検証の状況とログイン ID を書き込む必要があります。
このマップは以下のプロパティーに保管します。
このプロパティーは、以下のプロパティーから成ります。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
このプロパティーは、信頼できる場合は true に設定され、信頼できない場合は false に設定されます。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
このプロパティーには、ID のプリンシパルが含まれます。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
このプロパティーには、ID の証明書が含まれます。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
- ID アサーション・ログイン・モジュール (クレデンシャル作成)
- 以下のモジュールがクレデンシャルを作成します。
このモジュールは、ログイン・コンテキストの共有状態の信頼性状態情報に依存します。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule
ID アサーション・ログイン・モジュールは、共有状態のプロパティーで信頼性の情報を探します。
このプロパティーには、信頼性の状況とログイン用の ID が含まれ、以下のプロパティーが含まれている必要があります。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
このプロパティーは、信頼できる場合は true に設定され、信頼できない場合は false に設定されます。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
プリンシパルが使用される場合、このプロパティーには、ログイン用の ID のプリンシパルが含まれます。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
証明書が使用される場合、このプロパティーには、ログイン用の ID が含まれた証明書チェーンの配列が含まれます。com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
状態、信頼性、または ID 情報が欠落している場合、WSLoginFailedException メッセージが戻されます。次に、ログイン・モジュールが ID を使用してログインし、サブジェクトには新しい ID が入ります。
RunAs() 認証
- 呼び出し元 ID を伝搬します。これがデフォルト動作です。
- RunAs 仕様を使用して指定可能な RunAs ID に委任します。
サーバーは、最初のユーザーを認証した後、RunAs ユーザーを認証します。この認証が失敗すると、サーバーは呼び出し元 ID の伝搬に戻ります。
RunAs 仕様を使用するためには、アプリケーションのデプロイメント記述子に run-as エレメントまたは @RunAs アノテーションが含まれるように更新する必要があります。 このエレメントには、委任先のセキュリティー・ロールを設定します。
『Liberty での RunAs 認証の構成』を参照してください。
プロキシー・ログイン・モジュール
プロキシー・ログイン・モジュール・クラスは、アプリケーション・サーバー・ログイン・モジュールをロードし、 すべての操作を実際のログイン・モジュール実装に委任します。 実際のログイン・モジュール実装は、オプション構成における代行オプションとして指定されます。 アプリケーション・クラス・ローダーからはアプリケーション・サーバー製品の共有ライブラリー・クラス・ローダーが可視でないため、プロキシー・ログイン・モジュールが必要です。 JAAS ログイン・コンテキスト・エントリー WSLogin で LoginContext クラスの Login() メソッドを使用したアプリケーション・プログラマチック・ログインで、 プロキシー・ログイン・モジュールはすべての作業を JAAS ログイン・コンテキスト・エントリー system.DEFAULT に委任します。
証明書ログイン
証明書ログイン・フィーチャーにより、ユーザー ID とパスワードを指定する代わりに、クライアント・サイドの X509 証明書を使用して、サーブレットなどの Web 要求を認証できるようになります。
証明書認証は、ユーザー・レジストリー内のユーザーを Web 要求のクライアント証明書内の識別名に関連付けることで行われます。 信頼性は、クライアント証明書をサーバーから信頼させることによって確立されます。 例えば、クライアント証明書の署名者が、サーバーのトラストストア内になければなりません。 この仕組みにより、信頼性を確立するためにユーザーがパスワードを指定する必要がなくなります。
『Liberty での通信の保護』を参照してください。
ハッシュ・テーブル・ログイン・モジュール
ユーザー・レジストリーから必要な属性を検索し、ハッシュ・テーブルに属性を入れて、ハッシュ・テーブルを共有状態に追加します。このログイン・モジュールで ID が切り替えられた場合、ハッシュ・テーブルを共有状態に追加する必要があります。ID が切り替えられていないが、requiresLogin コードの値が true の場合、属性のハッシュ・テーブルを作成することができます。この状態でハッシュ・テーブルを作成する必要はありません。Liberty がユーザーに代わってログインを処理するためです。ただし、特殊なケースでは属性を収集するハッシュ・テーブルの作成を検討することがあります。例えば、独自の特殊なユーザー・レジストリーを使用している場合、UserRegistry 実装を作成し、ハッシュ・テーブルを使用して、サーバーにユーザー属性を収集させることが、単純なソリューションである可能性があります。
次の規則によって、ハッシュ・テーブル・ログインの実行方法が詳細にわたって定義されます。Subject (公開クレデンシャルまたはプライベート・クレデンシャルのセット) または共有状態 HashMap のいずれかで java.util.Hashtable オブジェクトを使用する必要があります。com.ibm.wsspi.security.token.AttributeNameConstants クラスは、ユーザー情報を含む鍵を定義します。Hashtable オブジェクトが、ハッシュ・テーブル・ログイン・モジュールの前にリストされるカスタム・ログイン・モジュールを使用して、ログイン・コンテキストの共有状態に置かれている場合、java.util.Hashtable オブジェクトの値は共有状態 hashMap 内で以下の鍵を使用して検索されます。
- プロパティー
- com.ibm.wsspi.security.cred.propertiesObject
- プロパティーへの参照
- AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
- 説明
- この鍵が、ログイン・コンテキストの共有状態に必要なプロパティーを含むハッシュ・テーブル・オブジェクトを検索します。
- 予想される結果
- java.util.Hashtable オブジェクト。
java.util.Hashtable オブジェクトが Subject 内または共有状態領域で検出された場合、次のプロパティーがハッシュ・テーブルにあることを確認してください。
- com.ibm.wsspi.security.cred.uniqueId
- プロパティーへの参照
- AttributeNameConstants.WSCREDENTIAL_UNIQUEID
- 戻り値
- java.util.String
- 説明
- プロパティーの値はユーザー固有の表記でなければなりません。Liberty のデフォルトの実装では、このプロパティーは、アプリケーション許可構成に保管される情報を示します。情報は、デプロイされてユーザーからロールへのマッピングが実行された後、アプリケーションのデプロイメント記述子にあります。ユーザーからロールへのマッピングが Liberty のユーザー・レジストリー実装の検索によって実行される場合は、予想されるフォーマットの例を参照してください。
- 予想されるフォーマットの例
- com.ibm.wsspi.security.cred.uniqueId プロパティーが必要です。
表 1. uniqueId のフォーマットの例. 次の表に、予想されるフォーマットの例を示します。 ユーザー・レジストリー フォーマット (UniqueUserId) 値 LDAP ldapRegistryRealm/cn=kevin,o=mycompany,c=use 基本 basicRegistryRealm/kelvin
- com.ibm.wsspi.security.cred.securityName
- プロパティーへの参照
- AttributeNameConstants.WSCREDENTIAL_SECURITYNAME
- 戻り値
- java.util.String
- 説明
- このプロパティーは認証ユーザーの securityName を検索します。この名前は一般的に表示名またはショート・ネームと呼ばれます。Liberty は、getRemoteUser、getUserPrincipal、および getCallerPrincipal アプリケーション・プログラミング・インターフェース (API) で securityName 属性を使用します。securityName 値のデフォルト実装との互換性を保証するには、public String getUserSecurityName(String uniqueUserId) UserRegistry メソッドを呼び出します。
- 予想されるフォーマットの例
- com.ibm.wsspi.security.cred.securityname プロパティーが必要です。
表 2. securityName のフォーマットの例. 次の表に、予想されるフォーマットの例を示します。 ユーザー・レジストリー フォーマット (securityName) 値 LDAP kevin 基本 kevin
- com.ibm.wsspi.security.cred.group
- プロパティーへの参照
- AttributeNameConstants.WSCREDENTIAL_GROUP
- 戻り値
- java.util.ArrayList
- 説明
- この鍵は、このユーザーが属するグループの配列リストを検索します。このグループは realm_name/user_name というフォーマットで指定されます。これらのグループのフォーマットは重要です。Liberty の許可エンジンが、これらのグループを使用して、デプロイメント記述子でグループからロールへのマッピングを行うためです。提供されるフォーマットは、Liberty のデフォルトの実装で要求されるフォーマットと一致している必要があります。サード・パーティーの許可プロバイダーを使用している場合、サード・パーティー・プロバイダーで要求されるフォーマットを使用する必要があります。固有のグループ ID 値のデフォルト実装との互換性を保証するには、public List getUniqueGroupIds(String uniqueUserId) UserRegistry メソッドを呼び出します。
- 予想されるフォーマットの例
- com.ibm.wsspi.security.cred.group プロパティーが必要です。 ユーザーは関連グループでなくてもかまいません。
表 3. グループのフォーマットの例. 次の表に、インバウンド ID マッピングを構成する場合のフォーマット例を示します。 ユーザー・レジストリー フォーマット (グループ) 値 LDAP ldapRegistryRealm/cn=group1,o=Groups,c=US 基本 basicRegistryRealm/group1
com.ibm.wsspi.security.cred.realm
- プロパティーへの参照
- AttributeNameConstants.WSCREDENTIAL_REALM
- 戻り値
- java.util.String
- 説明
- この鍵プロパティーは、LTPA Cookie に保管されるユーザー・レジストリー・レルム名を指定することができます。
- この鍵プロパティーは必須ではありません。
- com.ibm.wsspi.security.cred.cacheKey
- プロパティーへの参照
- AttributeNameConstants.WSCREDENTIAL_CACHE_KEY
- 戻り値
- java.lang.Object
- 説明
- この鍵プロパティーは、ユーザー固有の情報や、固有性に影響を与える可能性があるユーザー動的属性を含めた、ログインの固有のプロパティーを示すオブジェクトを指定することができます。 例えば、ユーザーがアクセス制御に影響を与える可能性があるロケーション A からログインする場合、 受け取った Subject が現在のロケーションの正しい Subject となるように、キャッシュ・キーは、ロケーション A を含む必要があります。
- この com.ibm.wsspi.security.cred.cacheKey プロパティーは必要ではありません。このプロパティーが指定されない場合、キャッシュ検索は WSCREDENTIAL_UNIQUEID に指定される値です。この情報が java.util.Hashtable オブジェクトにある場合、少なくとも LTPA については、Liberty が、通常のログイン・プロセスを行う Subject に類似した Subject を作成します。新規 Subject には、 Hashtable オブジェクトで検出される情報が完全に取り込まれている WSCredential オブジェクトおよび WSPrincipal オブジェクトが含まれます。