SAML の使用シナリオ
SAML 機能を、4 つの基本的な使用シナリオにより説明します。 最初の 3 つのシナリオは、ポリシー・セットを使用して構成された Web サービス・シングル・サインオンを例示します。4 つ目のシナリオでは、SAML API およびトラスト・クライアント API を使用して作成できるカスタムの SAML シングル・サインオンについて説明します。これらのシナリオは、SAML ビルディング・ブロックおよび API を使用して、セキュリティー・トークン・サービス (STS) への認証、SAML トークンの要求、および SAML トークン の実装を行うことによって、ビジネス・サービスへのアクセスを取得する方法を示します。
概要
SAML 対応の WebSphere® Application Server は、SAML トークンを使用したシングル・サインオンおよび ID 統合ビジネス・ソリューションを作成するために、ビルディング・ブロックと API を提供します。SAML ポリシー・セットは、SAML トークンの要求、SOAP メッセージでの SAML トークンの伝搬、および SAML トークンの検証と認証を、プログラミングを一切行うことなく行なえるように Web サービス・アプリケーションを構成するためのビルディング・ブロックです。
SAML API および WS-Trust クライアント API を使用すると、SAML トークンの作成、SAML トークンの解析と検証、および Web サービス SOAP メッセージ以外のプロトコルから受信した SAML トークンの認証をプログラムで行なうことができます。具体的には、SAML API を使用して、カスタムの SAML トークン属性の処理、個別設定されたアプリケーション・インターフェースの作成、および請求ベースの許可を行います。WS-Trust クライアント API を使用して、SAML トークンやその他のタイプのトークンを STS に要求し、STS を使用したセキュリティー・トークンの検証および交換を行います。
WebSphere Application Server 製品には、SAML やその他のタイプのセキュリティー・トークンを発行するための STS は含まれていません。 ただし、SAML 対応の WebSphere Application Server は、Tivoli® Federated Identity Manager やその他サード・パーティーの STS 実装と相互運用できます。
シナリオ 1: Web サービスのシングル・サインオン (SSO)
このシングル・サインオン (SSO) 使用シナリオでは、ユーザーがベアラー確認メソッドを使用して STS に対して認証を行い、SAML トークンを要求します。その後にユーザーは、SAML トークンを使用してビジネス・サービス・プロバイダーにアクセスします。 ビジネス・サービス・プロバイダーは、プロバイダーと発行元 STS の信頼関係に基づいて、SAML トークンを検証し、ユーザーの ID と属性を表明します。受信された SAML トークンは、そのトークン署名証明書がビジネス・サービス・プロバイダーによって信頼され、かつトークンの有効期限がビジネス・サービス・プロバイダーの現地時間に構成可能なクロック・スキューを加算した時間よりも短い場合に、有効と見なされます。
ビジネス・サービス・プロバイダーは、サービスのポリシー構成に基づき、SAML トークンを使用してユーザーの代わりにダウンストリーム・サービスにアクセスできます。ポリシー構成を使用することで、ビジネス・サービス・プロバイダーはオリジナルの SAML トークンを伝搬するか、またはオリジナルのユーザー属性に基づいて自己発行 SAML を生成できます。このシナリオでポリシー・セットとバインディングを構成する方法について詳しくは、SAML ベアラー・トークン用のクライアント・バインディングとプロバイダー・バインディングの構成に関する情報を参照してください。
SAML ベアラー・トークンを使用したシングル・サインオンは、SAML が業界標準のセキュリティー・トークンであり、複数のベンダー製品でサポートされていることから、他の SSO テクノロジーに比べて有利です。さらにWebSphere Application Server の SAML 機能実装は、Tivoli Federated Identity Manager、DataPower®、およびその他のベンダー製品と相互運用できます。

SAML プロバイダーのサンプル・バインディングに呼び出し元バインディングを追加して、呼び出し元の ID を表す受信済み SAML トークンを選択できます。デフォルトの system.wss.caller JAAS ログイン構成を使用すると、Web Services Security ランタイム環境は SAML NameId を使用してクライアント ID を表し、さらに構成済みのユーザー・レジストリーからユーザー・セキュリティー名とグループ・メンバーシップを検索します。
このシナリオが正常に実行されると、WS-Security ランタイム環境で SAML トークンが保存され、同じビジネス・サービス・プロバイダーへのアクセスにこのトークンが再利用されます (トークンが引き続き有効である場合)。このトークンは、トークン有効期限が構成可能なキャッシュ期間よりも短い場合に有効となります。ビジネス・サービス・プロバイダーが、受信した SAML トークンを検証して認証すると、JAAS サブジェクトが、対応する SAML トークンとともに認証キャッシュに保存されます。 ホストするアプリケーション・サーバーでは、SAML トークンがトークン有効期限に関係なく有効なままとなります。つまり、SAML トークンは認証キャッシュ内にある限り、アプリケーション・サーバー・プロセスで有効であり続けるため、WS-Security ランタイム環境は同じプロセス内で SAML トークンの有効期限を検査しません。
SAML トークンの有効期限は、ビジネス・サービス・プロバイダーが SAML トークンを使用してダウンストリーム・サービスを呼び出すときに検査されます。SAML トークンの有効期限が、現行時刻にキャッシュ期間を加えた値以上である場合、アウトバウンド要求は失敗します。この制限は、ポリシー構成でオリジナルの SAML トークンの使用が必要とされている場合にも適用されます。 ただし、ポリシー構成が自己発行 SAML トークンを代用する場合、例えば、ビジネス・サービス・プロバイダーが元の SAML トークンの複写を作成して署名した場合、この制限は適用されません。
シナリオ 2: holder-of-key 検証による Web サービス・シングル・サインオン (SSO)
holder-of-key 検証を伴うシングル・サインオンの使用シナリオは、前述の SSO 使用シナリオと似ています。 holder-of-key 検証を伴う SSO のシナリオでは、ベアラー確認メソッドではなく holder-of-key (HoK) 確認メソッドが指定された SAML トークンを使用します。 SAML HoK トークンには鍵が含まれており、クライアントはこれを使用して鍵自体の所有権とトークンの所有権を証明します。この組み込み鍵は、共有鍵 (対称鍵とも呼ばれます)、または公開鍵 (非対称鍵とも呼ばれます) を使用する X.509 証明書のいずれかです。共有鍵の場合は、ターゲットのビジネス・サービス・プロバイダーの公開鍵を使用して鍵が暗号化されるため、目的のビジネス・サービスのみが SOAP メッセージを使用できます。
クライアントが HoK 共有鍵を含む SAML トークンを STS に要求すると、STS は SAML トークン内の鍵を暗号化し、同じ鍵のコピーを WS-Trust 応答で要求元のクライアントに送信します。この処理を行わないとクライアントが SAML トークン内の暗号化された鍵を読み取ることができないため、この処理が必要となります。SAML トークンの所有権を証明するために、クライアントはこの共有鍵を使用して SOAP 要求メッセージに署名し、それらのメッセージを暗号化します。ビジネス・サービスでは、暗号化された共有鍵を抽出し、それを使用してデジタル署名を検証することによって、HoK トークン所有権を検証する必要があります。

1 ユーザーが SPNEGO を使用して Web ブラウザーにログオンし、認証されます。JAAS サブジェクトが作成されます。
2 SPNEGO トークンからのクレデンシャルを使用し、WS-Trust を使用して SAML トークンが要求されます。このトークンは、トラスト・サーバーの秘密鍵で署名されます。
3 SAML トークンの署名が信頼関係に基づいて検証されます。セキュリティー・クレデンシャルは、SAML トークンの属性を使用して作成されます。SAML トークンから得た暗号鍵が、SOAP メッセージの暗号化解除に使用されます。
図に示されているように、ブラウザー・クライアントは Kerberos クレデンシャル (SPNEGO トークンで表されます) を使用して Web アプリケーションにアクセスします。Kerberos クレデンシャルを委任できると仮定すると、Web アプリケーションは、委任されたクライアントの Kerberos クレデンシャルを使用して、クライアントに代わって STS に SAML トークンを要求できます。例えば、Web アプリケーションは、クライアントに代わって、鍵配布センター (KDC) からクライアント承認要求 (APREQ) Kerberos トークンを取得します。この Web アプリケーションは、クライアント APREQ トークンを使用して STS に対する認証を行い、クライアントに代わって STS にクライアント SAML トークンを要求します。
この例では、SAML トークンは、対称鍵を使用する holder-of-key 確認メソッドを必要とします。Web アプリケーションは、同じくクライアントの代わりに SAML トークンを使用してダウンストリームのビジネス・サービスにアクセスします。したがって、SAML トークンがクライアントをダウンストリーム・サービスに対して認証するとともに、デジタル署名および暗号化を使用して要求メッセージを保護します。HoK トークン用のバインディングをセットアップする方法について詳しくは、SAML holder-of-key 対称鍵トークン用のクライアント・バインディングとプロバイダー・バインディングの構成に関する情報を参照してください。
このシナリオが正常に実行されたら、その後、ターゲットのビジネス・サービスは、このシナリオで説明されたのと同じ手順で、SAML トークンを使用して他のダウンストリームのビジネス・サービスにアクセスできます (ただし、対象となるダウンストリームのサービスが埋め込み鍵を抽出できることが条件です)。あるいは、秘密鍵の配布を避けるため、自己発行 SAML トークンを使用してダウンストリームのサービスにアクセスするようにビジネス・サービスを構成することもできます。
シナリオ 3: Web サービスの統合 ID 管理
統合 ID 管理の使用シナリオでは、ブラウザー・クライアントが企業のポータル Web アプリケーションにアクセスします。このシナリオでは、ユーザー名やパスワードなどの基本的なユーザー認証データを使用して STS に SAML トークンが要求され、その SAML トークンを使用してセキュリティー・ドメイン間でビジネス・サービスへのアクセスが行われます受信側のビジネス・サービス・プロバイダーは、プロバイダーと発行側 STS との信頼関係に基づいて SAML トークンを検証します。このプロバイダーはまた、ユーザーの ID と属性を表明します。これは、ターゲット・ビジネス・サービスのユーザー・ディレクトリー内にユーザーが前もって定義されている必要がないことを意味します。このシナリオの利点は、多数のビジネス・パートナーから提供されるビジネス・サービスをより管理しやすい方法で統合できると同時に、ユーザーを 1 つのユーザー・ディレクトリー・サービスに統合する必要がないことです。

1 ユーザーはユーザー名とパスワードを使用して企業ポータルにログオンし、認証されます。JAAS サブジェクトが作成されます。
2 ユーザー名とパスワードが使用されて、STS への認証と、ユーザーを表す SAML トークンの要求が行われます。
3 SAML トークンの署名が信頼関係に基づいて検証されます。SAML トークンから得た属性を使用してセキュリティー・クレデンシャルが作成されます。SAML トークンから得た暗号鍵が、SOAP メッセージの暗号化解除に使用されます。
デフォルトのシステム・ログイン構成 wss.caller によって、SAML トークンで表されるユーザー ID が、構成済みのユーザー・ディレクトリー内のユーザー ID にマップされます。他のセキュリティー・ドメインの SAML トークン・ユーザー ID をアプリケーション・サーバーに表明するためには、wss.caller ログイン構成にカスタム・ログイン・モジュールを追加する必要があります。このカスタム・ログイン・モジュールは、SAML トークンのユーザー ID とその他の属性を抽出し、アプリケーション・サーバーで使用されるアサーション・プロパティーを作成します。これらのプロパティーのうち、アプリケーション・サーバーに必要なものは、ユーザー名とユーザー ID の 2 つです。この 2 つのプロパティーは ID アサーションで提供されるため、アプリケーション・サーバーはローカル・ユーザー・ディレクトリーに照らしてユーザー名を検証する必要がありません。
さらに、ユーザー・グループ・メンバーシップに関する情報をアプリケーション・サーバーに提供することも可能です。この情報は、ユーザーのアプリケーション・サーバー・セキュリティー・クレデンシャルを表す WSCredential オブジェクトを作成するために使用されます。ユーザー・プロパティーは、JAAS LoginContext 共有状態を使用して、アプリケーション・サーバー WSWSSLoginModule に渡されます。これらのプロパティーについて詳しくは、インバウンド ID マッピングの構成に関する情報を参照してください。
シナリオ 4: カスタム・シングル・サインオン (SSO) ソリューション
カスタムのシングル・サインオン (SSO) 使用シナリオは、SAML トークン・ライブラリー API、WS-Trust クライアント API、およびその他のアプリケーション・サーバー API と SPI を使用して、特定のビジネス・コンピューティング環境に合わせてカスタマイズした SSO ソリューションを構築します。このシナリオの図は、ユーザーが認証され、企業のサーバーとの信頼関係がある ID プロバイダーから SAML トークンが発行される例を示しています。このシナリオでは、ある企業が、ユーザーに追加の認証を求めることなく、信頼関係に基づいて、保護された Web アプリケーションへのアクセスをユーザーに許可したいと考えています。
Web ブラウザーなどの Web アプリケーション・クライアントは、Web サービス・プロトコルではなく HTTPS プロトコルを使用して、アプリケーション・サーバーに SAML トークンを渡します。企業では、このような要求をインターセプトして転送するために、アプリケーション・サーバーのトラスト・アソシエーション・インターセプター (TAI) API を実装する SAML TAI を構築します。SAML TAI は、SAML トークン・ライブラリー API を使用して、SAML トークンの検証と認証を行います。また、SAML TAI は、WS-Trust クライアント API を使用して外部 STS に対して SAML トークンを検証し、認証することもできます。TAI インターフェースについて詳しくは、トラスト・アソシエーションのカスタム・インターセプターの開発に関する情報を参照してください。カスタム SAML TAI は WebSphere Application Server には付属していません。

1 ユーザーは、ユーザー名とパスワードを使用して、ID プロバイダーにログオンします。ID プロバイダーはユーザーに SAML トークンを発行します。
2 SAML TAI は、SAMLTokenFactory API を使用して SAML トークンを検証して認証し、ユーザー・クレデンシャルを作成します。また、SAML TAI は、WS-Trust クライアント API を使用して外部 STS で SAML トークンを検証することもできます。
SAML API について詳しくは、WS-Trust クライアント API および SAML トークン・ライブラリー API に関する情報を参照してください。
より複雑なソリューション: 複数のセキュリティー・ドメイン
この資料の前のセクションでは、4 つの基本的な使用シナリオについて説明しました。 ただし、複数のセキュリティー・ドメイン境界をまたいで SAML トークンを表明することもできます。このソリューションについて詳しくは、複数の WebSphere Application Server セキュリティー・ドメインにわたる SAML アサーションに関する資料を参照してください。