独自のシングル・サインオン・トークンのインプリメントを作成することができます。シングル・サインオン・トークンの
インプリメンテーションは、ログイン・サブジェクトで設定され、HTTP Cookie として HTTP 応答に追加されます。
このタスクについて
Cookie 名は SingleSignonToken.getName アプリケーション・プログラミング・インターフェース (API) および SingleSignonToken.getVersion API が連結されたものです。区切り文字はありません。シングル・サインオン・トークンを
サブジェクトに追加するとき、
サブジェクトが他の Web 要求に使用される場合は、水平かつダウンストリームに伝搬します。
伝搬ログインから受け取る場合、カスタム・シングル・サインオン・トークンをデシリアライズする必要があります。
以下のタスクの 1 つを行う場合は、独自のインプリメンテーションを書き込むことを考慮してください。
- 独自のインプリメンテーション内で属性を分離します。
- カスタム・シリアライゼーションを使用して情報をシリアライズします。HTTP 応答であり、
インターネットで使用可能なため、情報を暗号化します。
ターゲットでバイトをデシリアライズまたは暗号化解除し、
その情報をサブジェクトに追加する必要があります。
- getUniqueID API を使用するサブジェクトの全体的な固有性に影響を与えます。
カスタム・シングル・サインオン・トークンをインプリメントするには、
以下のステップを実行します。
プロシージャー
- SingleSignonToken インターフェースのカスタム・インプリメンテーションを書き込みます。
SingleSignonToken インターフェースをインプリメントするさまざまな方法がたくさんあります。
ただし、SingleSignonToken インターフェースおよびトークン・インターフェースが必要とするメソッドは完全にインプリメントされていることを確認してください。
このインターフェースをインプリメントした後、profile_root/classes ディレクトリーにこれを配置することができます。profile_root 変数は、
プロファイル作成で profilePath パラメーターに指定されたディレクトリーおよびプロファイルの名前です。クラスについて詳しくは、プロファイルでのカスタム・クラス用クラス・サブディレクトリーの作成
を参照してください。
ヒント: 伝搬フレームワークによって定義されるすべてのトークン・タイプは、同様なインターフェースを持ちます。
基本的に、トークン・タイプは、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 Cookies にはサイズの制限があるため、このトークンに多くのデータを追加しないでください。
- 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 ログイン・モジュールの後に追加します。
既存のログイン構成にカスタム・ログイン・モジュールを追加する方法について詳しくは、システム・ログイン構成用のカスタム・ログイン・モジュール開発
を参照してください。
結果
これらのステップが完了すると、カスタム・シングル・サインオン・トークンがインプリメントされます。