第3章 Red Hat JBoss Enterprise Application Platform における SSO のその他のユースケース

JBoss EAP は、初期状態の機能の他に、その他の SSO のユースケースもサポートします。これらのユースケースには、ブラウザーベースの SSO、デスクトップベースの SSO、およびセキュアトークンサービスを介した SSO に対する SAML が含まれます。

3.1. SAML を使用したブラウザーベースの SSO

ブラウザーベースの SSO の場合、サービスプロバイダーと呼ばれる 1 つ以上の web アプリケーションがハブアンドスポーク型アーキテクチャーの集中管理されたアイデンティティープロバイダーに接続されます。アイデンティティープロバイダー (IDP) は、サービスプロバイダー (スポーク) へのアイデンティティーおよびロール情報の中央のソース (ハブ) として動作します。認証されていないユーザーがサービスプロバイダーの 1 つにアクセスしようとすると、そのユーザーは IDP へリダイレクトされ、認証を行います。IDP がユーザーを認証すると、プリンシパルのロールを指定する SAML トークンを発行し、要求されたサービスプロバイダーにリダイレクトします。SAML トークンは関連するすべてのサービスプロバイダーで使用され、ユーザーのアイデンティティーとアクセス権が判断されます。SSO を使用してサービスプロバイダーで開始されるこのような方法は、サービスプロバイダー開始フロー (Service provider-initiated flow) と呼ばれます。

JBoss EAP は多くの SSO システムと同様に IDP と SP を使用します。これらのコンポーネントは JBoss EAP インスタンス内で実行でき、JBoss EAP の security サブシステムとともに動作します。FORM ベースのウェブアプリケーションセキュリティーである SAML v2、HTTP/POST および HTTP/リダイレクトバインディングも SSO の実行に使用されます。

アイデンティティープロバイダーを作成するには、LDAP やデータベースなどの認証および承認メカニズムを定義する JBoss EAP インスタンスでセキュリティードメイン (例: idp-domain) を作成し、アイデンティティーストアとします。idp-domain とともに IDP の実行に必要な追加のモジュール (org.picketlink) を使用するよう、web アプリケーション (例: IDP.war) が設定され、同じ JBoss EAP インスタンスにデプロイされます。 IDP.war はアイデンティティープロバイダーとなります。サービスプロバイダーを作成するため、SAML2LoginModule を認証方法として使用するセキュリティードメイン (例: sp-domain) が作成されます。web アプリケーション (例: SP.war) は追加のモジュール ( org.picketlink) を使用するよう設定され、sp-domain を使用するサービスプロバイダーバルブが含まれます。SP.war は sp-domain が設定された JBoss EAP インスタンスにデプロイされ、サービスプロバイダーとなります。このプロセスは、SP2.war や SP3.war などのように 1 つ以上の SP に対してレプリケートでき、1 つ以上の JBoss EAP インスタンス全体でレプリケートできます。

3.1.1. アイデンティティープロバイダー開始フロー (Identity Provider Initiated Flow)

ほとんどの SSO のシナリオでは、SP は有効なアサーションで SAML 応答を SP に送信する IDP に認証リクエストを送信して、フローを開始します。これは SP 開始フロー (SP-initiated flow) と呼ばれます。SAML 2.0 仕様は、IDP 開始フロー (IDP-initiated flow) または未承諾応答フロー (Unsolicited Response flow) と呼ばれる別のフローを定義します。このフローの場合、サービスプロバイダーは認証フローを開始せずに IDP から SAML 応答を受信します。このフローは IDP 側で開始されます。ユーザーは認証されると、リストから特定の SP を選択でき、SP の URL へリダイレクトされます。このフローを有効にするのに特別な設定は必要ありません。

手順

  1. ユーザーが IDP にアクセスします。
  2. IDP はSAML 要求や応答がないことを確認し、SAML を使用した IDP 開始フローを想定します。
  3. IDP はユーザーの認証を行います。
  4. 認証後、IDP は、すべての SP アプリケーションにリンクするページをユーザーが取得する、ホストされたセクションを表示します。
  5. ユーザーは SP アプリケーションを選択します。
  6. IDP は、クエリーパラメーターの SAML 応答に SAML アサーションを持つ SP へユーザーをリダイレクトします。
  7. SP は SAML アサーションをチェックし、アクセスを提供します。

3.1.2. グローバルログアウト

1 つの SP で開始されるグローバルログアウトは、IDP およびすべての SP からユーザーをログアウトします。グローバルログアウトの実行後に、SP または IDP のセキュアな部分にアクセスするユーザーは再認証が必要になります。

3.2. デスクトップベースの SSO

デスクトップベースの SSO では、デスクトップ全体でプリンシパルを共有することができ、通常は Active Directory または Kerberos サーバーと、SP である web アプリケーションによって管理されます。この場合、デスクトップ IDP は web アプリケーションの IDP となります。

一般的なセットアップでは、ユーザーは Active Directory ドメインによって管理されるデスクトップへログインします。JBoss Negotiation で設定され、JBoss EAP でホストされる web ブラウザーを介してユーザーは web アプリケーションにアクセスします。web ブラウザーはサインオン情報をユーザーのローカルマシンから web アプリケーションへ転送します。JBoss EAP は、Active Directory または Kerberos サーバーでバックグラウンドの GSS メッセージを使用し、ユーザーを検証します。これにより、ユーザーは web アプリケーションへのシームレスな SSO を実現することができます。

デスクトップベースの SSO を web アプリケーションの IDP としてセットアップするため、IDP サーバーに接続するセキュリティードメインが作成されます。NegotiationAuthenticator は指定の web アプリケーションのバルブとして追加され、JBoss Negotiation は SP コンテナーのクラスパスに追加されます。この代わりに、デスクトップベースの SSO プロバイダーをアイデンティティーストアとして使用して IDP をブラウザーベースの SSO の場合と同様にセットアップすることもできます。

3.3. STS を使用した SSO

JBoss EAP は、STS に接続するためのログインモジュールを複数提供します。STS (PicketLinkSTS) として実行することも可能です。PicketLinkSTS は他のセキュリティートークンサービスへ複数のインターフェースを定義し、拡張ポイントを提供します。設定を使用して実装をプラグインでき、設定を介してデフォルト値を一部のプロパティーに指定できます。PicketLinkSTS はセキュリティートークンを生成および管理しますが、特定タイプのトークンを発行しません。この代わりに、PicketLinkSTS は複数のトークンプロバイダーをプラグインできる汎用のインターフェースを定義します。そのため、各トークンタイプのトークンプロバイダーが存在する場合、PicketLinkSTS がさまざまなタイプのトークンに対応するよう設定することができます。また、セキュリティートークンのリクエストと応答の形式も指定します。

以下の手順は、JBoss EAP のSTS を使用した場合にセキュリティートークンリクエストが処理される順序を表します。

  1. クライアントはセキュリティートークンリクエストを PicketLinkSTS に送信します。
  2. PicketLinkSTS はリクエストメッセージを解析し、JAXB オブジェクトモデルを生成します。
  3. PicketLinkSTS は設定ファイルを読み取り、必要な場合は STSConfiguration オブジェクトを作成します。設定から WSTrustRequestHandler への参照を取得し、リクエストの処理をハンドラーインスタンスに委譲します。
  4. リクエストがトークンのライフタイム値を指定しない場合など、リクエストハンドラーは必要であれば STSConfiguration を使用してデフォルト値を設定します。
  5. WSTrustRequestHandler は WSTrustRequestContext を作成し、PicketLinkSTS から受信した JAXB リクエストオブジェクトと呼び出し元プリンシパルを設定します。
  6. WSTrustRequestHandler は STSConfiguration を使用して、リクエストされたトークンタイプを基にリクエストを処理するために使用する必要がある SecurityTokenProvider を取得します。これにはプロバイダーが関係し、構築された WSTrustRequestContext をパラメーターとして渡します。
  7. SecurityTokenProvider インスタンスはトークンリクエストを処理し、発行されたトークンをリクエストコンテキストに格納します。
  8. WSTrustRequestHandler はコンテキストからトークンを取得し、必要な場合は暗号化して、セキュリティートークンが含まれる WS-Trust 応答オブジェクトを構築します。
  9. PicketLinkSTS はリクエストハンドラーによって生成された応答を書き取り、クライアントへ返します。

STS ログインモジュール (STSIssuingLoginModule、STSValidatingLoginModule、 SAML2STSLoginModule など) は、通常はユーザーの認証に STS を使用するよう、セキュリティーセットアップの一部として設定されます。STS はログインモジュールと同じコンテナーに配置するか、web サービス呼び出しや別の技術を使ってリモートでアクセスすることができます。