独自のシングル・サインオン・トークンの実装を作成することができます。シングル・サインオン・トークンの
実装は、ログイン・サブジェクトで設定され、HTTP Cookie として HTTP 応答に追加されます。
このタスクについて
Cookie 名は SingleSignonToken.getName アプリケーション・プログラミング・インターフェース (API) および SingleSignonToken.getVersion API が連結されたものです。区切り文字はありません。シングル・サインオン・トークンをサブジェクトに追加するとき、サブジェクトが他の Web 要求に使用される場合は、水平かつダウンストリームに伝搬します。伝搬ログインから受け取る場合、カスタム・シングル・サインオン・トークンをデシリアライズする必要があります。
以下のいずれかのタスクを行う場合は、独自の実装を書き込むことを考慮してください。
- 独自の実装内で属性を分離します。
- カスタム・シリアライゼーションを使用して情報をシリアライズします。HTTP 応答であり、
インターネットで使用可能なため、情報を暗号化します。
ターゲットでバイトをデシリアライズまたは暗号化解除し、
その情報をサブジェクトに追加する必要があります。
- getUniqueID API を使用することによって、サブジェクトの全体的な固有性に影響を与えます。
カスタム・シングル・サインオン・トークンを実装するには、
以下のステップを実行します。
- SingleSignonToken インターフェースのカスタム・実装を書き込みます。
SingleSignonToken インターフェースを実装するさまざまな方法がたくさんあります。
ただし、SingleSignonToken インターフェースおよびトークン・インターフェースが必要とするメソッドは完全に実装されていることを確認してください。
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
このインターフェースを実装した後、app_server_root/classes ディレクトリーにこれを配置することができます。その代わりに、専用ディレクトリーにクラスを配置することもできます。ただし、WebSphere Application Server クラス・ローダーがクラスを見つけることができ、クラスに適切な許可が与えられるようにしてください。
server.policy ファイルにこのクラスを含む Java™ archive (JAR) ファイルまたはディレクトリーを追加して、
クラスがサーバー・コードに必要な許可を持つようにします。
このインターフェースを実装した後、profile_root/classes ディレクトリーにこれを配置することができます。クラスについて詳しくは、プロファイルでのカスタム・クラス用クラス・サブディレクトリーの作成を参照してください。
ヒント: 伝搬フレームワークによって定義されるすべてのトークン・タイプは、同様なインターフェースを持ちます。
基本的に、トークン・タイプは、com.ibm.wsspi.security.token.Token インターフェースを実装する
マーカー・インターフェースです。
このインターフェースはほとんどのメソッドを定義します。
複数のトークン・タイプを実装する場合は、com.ibm.wsspi.security.token.Token インターフェースを実装する抽象クラスを作成することを考慮してください。
すべてのトークン実装 (シングル・サインオン・トークンを含む) は、抽象クラスを拡張する可能性があり、その後作業のほとんどが完了します。
シングル・サインオン・トークンのインプリメンテーションについては、例: com.ibm.wsspi.security.token.SingleSignonToken 実装を参照してください。
- WebSphere Application Server ログイン時に、カスタム・シングル・サインオン・トークンを追加および受け取ります。 このタスクは通常、
カスタム・ログイン・モジュールをさまざまなアプリケーションおよびシステム・ログイン構成に追加することによって行われます。
ただし、情報をデシリアライズするために、
以降のステップで説明されているとおりに、カスタム・ログイン・モジュールに接続する必要があります。
オブジェクトがログイン・モジュールでインスタンス化されると、commit メソッド中にそれをサブジェクトに追加することができます。
例: カスタムのシングル・サインオン・トークン・ログイン・モジュール のコード・サンプルは、ログインが初期ログインであるか伝搬ログインであるかを判別する方法を示します。その違いは、WSTokenHolderCallback コールバックが伝搬データを含んでいるかどうかです。
コールバックが伝搬データを含んでいない場合、新規カスタム・シングル・サインオン・トークンの実装を初期化し、それをサブジェクトに設定します。また、http 要求オブジェクトがコールバックで使用可能な場合、HTTP Cookie を HTTP 要求から探します。
水平伝搬ログインおよび HTTP 要求の両方からカスタム・シングル・サインオン・トークンを取得することができます。
ただし、情報はフロントエンド・アプリケーション・サーバーに到着するため、たとえそのサーバーが伝搬をサポートしていなくとも、両方の場所でトークンを使用可能にすることをお勧めします。
ログイン・モジュールのコミット・フェーズでシングル・サインオン・トークンを読み取り専用にすることができます。
そのトークンを読み取り専用にする場合は、追加の属性はアプリケーション内に追加できません。
制約事項: - HTTP Cookie にはサイズの制限があります。サイズ制限については、ご使用のブラウザーのドキュメンテーションに記載されています。
- WebSphere Application
Server ランタイムは、生成しない Cookie を処理しないため、この Cookie はランタイムによって使用されません。
- SingleSignonToken オブジェクトは、サブジェクトの中にあるとき、getUniqueID メソッドに何かを戻す場合にサブジェクトのキャッシュ検索に影響を与えます。
- ログイン中 HTTP 要求のオブジェクトから、またはアプリケーションから HTTP Cookie を取得します。 例: HTTP Cookie 検索 にあるサンプル・コードは、
HTTP 要求から HTTP Cookie を検索する方法、元のバイトに戻るように Cookie をデコードする方法、
バイトからカスタム SingleSignonToken オブジェクトを作成する方法を示します。
- カスタム伝搬トークンのシリアライズ版を受け取るために既に com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule を含んでいる WebSphere Application Server システム・ログイン構成に、カスタム・ログイン・モジュールを追加します。 このログイン・モジュールが com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule ログイン・モジュールが追加した sharedState 状態の情報に依存しているため、このログイン・モジュールを com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule ログイン・モジュールの後に追加します。
既存のログイン構成へのカスタム・ログイン・モジュールの追加については、『JAAS のシステム・ログイン構成用のカスタム・ログイン・モジュールの開発』を参照してください。