SAML v2 での SSO の設定方法
SAML v2 での SSO の設定方法
概要
第1章 SAMLv2 DeeperDive を使用した SSO
SSO と SAML の基本については、Red Hat JBoss Enterprise Application Platform の セキュリティーアーキテクチャー で説明しています。このセクションでは、SAML v2 および SSO に関連するコンポーネントの詳細を説明します。
1.1. SAML v2とは
SAML (Security Assertion Markup Language) は、通常はアイデンティティープロバイダーとサービスプロバイダーである 2 者が認証および承認情報を交換できるようにするデータ形式とプロトコルです。この情報は、アサーションを含む SAML トークンの形式で交換され、サービスプロバイダーによる認証の影響を受けるよう ID プロバイダーによって発行されます。複数のサービスプロバイダーと共にアイデンティティープロバイダーから発行される SAML トークンをサブジェクトが使用および再利用する機能により、SAML v2 はブラウザーベースの SSO を容易にします。
1.1.1. ブロックの構築
SAML に留意すべき最も重要な概念は、エンティティー間でセキュリティーアサーションを渡すことだけです。SAML には、このタスクを実行するために使用するコンポーネントが複数含まれています。
1.1.1.1. エンティティー
エンティティーは、アサーションの作成および受け渡しに関与するすべての当事者です。SAML には、サブジェクト、ID プロバイダー、および サービスプロバイダー の 3 つの異なるエンティティーの概念があります。
subject は principal とも呼ばれ、SAML によってセキュア化された service provider のリソースへのアクセスを要求します。
service provider (SP) には、ID プロバイダー から必要な subject のアイデンティティーのアサーションとして検証が必要です。
アイデンティープロバイダー (IDP) は、サービスプロバイダー による認証および承認の決定に使用できる、subject に関するトークンの形式で、アサーションのセットを提供します。
つまり subject は発行されたアサーションを取得し 、アイデンティープロバイダー はこれらのアサーションを発行して、サービスプロバイダー はこれらのアサーションを使用して subject を認証および承認します。
1.1.1.2. セキュリティアサーション
セキュリティーアサーションは、サブジェクトに関するアイデンティティープロバイダーが発行する一連のステートメントです。サービスプロバイダーはこれらのアサーションを使用して、サブジェクトに関するアクセス制御の決定を行います。ステートメントは以下の形式を取ることができます。
- 認証
- Authentication アサーションは、特定の時点で指定されたメソッドを使用してサブジェクトが正常に認証されたことをアサートします。認証済みのサブジェクトに関する他の情報が含まれる認証コンテキストも authentication ステートメントで指定できます。
- 属性
- Attribute アサーションは、サブジェクトに特定の属性があることをアサートします。
- Authorization Decision
- Authorization Decision アサーションはリソース上のサブジェクトの承認要求に対して応答 (承認または拒否) をアサートします。
例:
このユーザーは、ユーザー名とパスワードを使用して 9:30 に Sarah としてログインしました。Sarah はマネージャーグループのメンバーです。Sarah は、従業員情報リソースへのアクセスを許可されています。
- This user logged in as Sarah at 9:30 using a username and password というステートメントは Authentication アサーションです。
- Sarah is a member of the Managers group というステートメントは、Attribute アサーションです。
- Sarah is accepted to access the Employee Information resource ステートメントは Authorization Decision アサーションです。
アサーションは SAML トークンとしてパケージ化され、SAML プロトコルを使用してトランスポートされます。
1.1.1.3. プロトコル
SAML プロトコルは、通常リクエストと応答の形式でアサーションがパッケージ化される方法と、これを処理する正しい方法のルールを記述します。これらのルールの後に、リクエストと応答のプロデューサーとコンシューマーの両方を追加する必要があります。リクエストは、認証、属性、または承認の決定について、特定の既知のアサーションまたはクエリーアイデンティティープロバイダーを要求することができます。セキュリティーアサーションを含むリクエストおよび応答メッセージは XML でフォーマットされ、指定されたスキーマに従います。
1.1.1.4. バインディング
SAML バインディングは、SAML プロトコルをトランスポートおよびメッセージングに使用される他の標準プロトコルにマップする方法を指定します。例には以下が含まれます。
- HTTP リダイレクトにマップする SAML バインディング。
- HTTP POST にマップする SAML バインディング。
- SAML 要求/応答を SOAP リクエストおよび応答にマップする SAML バインディング。
1.1.1.5. プロファイル
SAML プロファイルは、アサーション、プロトコル、バインディングを使用して、Web Browser SSO、Single Logout、および Assertion Query などの特定のユースケースに対応します。
1.2. SAML v2 が SSO と機能する仕組み
SAML v2 でのブラウザーベースの SSO の基本は、Red Hat JBoss Enterprise Application Platform 6 Security Architecture ガイドの SAML を使用したブラウザーベースの SSO および SAML でブラウザーベースの SSO を使用する複数の Red Hat JBoss Enterprise Application Platform インスタンスと複数のアプリケーション セクションで説明されています。このセクションでは、SAML v2 を使用したブラウザーベースの SSO に関連する SAML プロファイルおよびバインディングについての詳細情報を提供します。
1.2.1. Web Browser SSO プロファイル
Web ブラウザー SSO プロファイルは、ID プロバイダー (IDP)、サービスプロバイダー (SP)、およびプリンシパル (ブラウザーエージェントの形式) がブラウザーベースの SSO を処理する方法を指定します。SP および IDP には、Web Browser SSO プロファイルで使用できるバインディングが複数あり、多数のフローが可能です。また、このプロファイルは IDP または SP のいずれかから開始されるメッセージフローをサポートします。このプロファイルは、SAML アサーションを SP にプッシュする IDP、または IDP からアサーションをプルする SP もサポートします。SP または IDP のいずれかから開始されたフローは、Red Hat JBoss Enterprise Application Platform 6 のセキュリティーアーキテクチャー ドキュメントで概説されています。IDP からプッシュされた SAML アサーションは HTTP POST メッセージまたは HTTP リダイレクトを使用します。SP がプルする SAML アサーションでは、アーティファクトを受信側に送信し、次にアサーションを取得するために逆参照されます。
Web ブラウザーの SSO プロファイルの基本的なフローは以下のとおりです。
- SP へのプリンシパル HTTP 要求: プリンシパルは最初に、HTTP ユーザーエージェント (ブラウザーなど) を介して SP で保護されたリソースにアクセスしようとします。プリンシパルが有効なセキュリティーコンテキストで SAML トークンをすでに発行している場合、SP はプリンシパルを許可または拒否します (最後の手順)。そうでなければ、SP は認証要求の IDP の場所を特定します。
- SP が IDP を決定: SP は、IDP と SP の推奨バインディングをサポートするエンドポイントを見つけます。これにより、SP が認証要求を IDP に送信できます。このプロセスの具体的な方法は、実装ごとに異なる場合があります。
-
プリンシパルを介して SP から IDP に発行される認証要求:SP が IDP の場所とエンドポイントを決定すると、SP はユーザーエージェント (プリンシパル) によって IDP に配信される認証要求 (
<AuthnRequest>
メッセージ) を発行します。HTTP Redirect、HTTP POST、または HTTP Artifact SAML バインディングを使用すると、ユーザーエージェントを使用してメッセージを IDP に転送することができます。 - IDP がプリンシパルを識別: プリンシパルによって認証要求が IDP に配信されると、プリンシパルは IDP によって識別されます。識別方法は Web ブラウザーの SSO プロファイルによって明確に定義されていません。これは、FORM を使用した認証、既存のセッション情報、kerberos 認証など、数多くの方法で実現できます。
-
IDPが SP への要求を発行: プリンシパルが特定されると、IDP は
<response>
メッセージの形式で応答を発行し、ユーザーエージェントを使用してプリンシパルによるアクセスを許可または拒否するために SP に返送します。このメッセージは、少なくとも単一の認証アサーションを含み、エラーを示すのにも使用できます。HTTP POST または HTTP Artifacts はこのメッセージの転送に使用できますが、ほとんどのユーザーエージェントの URL 長制約により HTTP Redirect を使用することはできません。ユーザーエージェントが、SP ではなく IDP に直接アクセスしようとするなど、IDP ベースのフローを開始した場合は、このステップでプロセスが開始されます。成功すると、HTTP POST または HTTP アーティファクトが IDP に事前設定されたロケーションに送信されます。 - SP はプリンシパルへのアクセスを許可 (または拒否): SP が応答を受信すると、セキュリティーコンテキストを作成して要求されたリソースへのアクセスをプリンシパルに付与したり、アクセスを拒否したり、独自のエラー処理を行ったりする場合があります。
JBoss EAP 6 は SAML アーティファクトバインディングをサポートしません。
HTTP Redirect バインディングは、HTTP GET 要求と URL クエリーパラメーターを使用してプロトコルメッセージを送信します。この方法で送信されたメッセージは、受信側によって送信およびデコードされる前に URL と Base-64 エンコードされます。HTTP POST バインディングは、フォームデータを使用してメッセージを送信し、メッセージに対して base-64 エンコード/エンコードも送信します。SP および IDP の両方がリダイレクトまたは POST バインディングを使用してメッセージを送受信できます。特定のシナリオでの URL の長さの制限により、通常 HTTP Redirect は短いメッセージを渡す際に使用され、HTTP POST は長いメッセージを渡す際に使用されます。
1.2.2. Global Logout Profile
Global Logout Profile を使用すると、IDP と SP のセットで認証されたプリンシパルをログアウトでき、そのアサーションを、関連する 1 つ以上の IDP と SP に伝播できます。
プリンシパルが IDP で認証されると、プリンシパルと IDP が認証セッションを確立します。IDP は、その認証に基づいて、さまざまな SP に対してアサーションを発行したり、公開したりすることがあります。プリンシパルが SP 内のセキュアなリソースにアクセスしようとすると、SP は IDP から発行されたアサーションに基づいて、プリンシパルで追加のセッションを確立することを選択する可能性があるため、IDP に依存します。
セッションまたはセッションのセットが作成されると、さまざまな方法でプリンシパルがセッションから個別にログアウトされたり、グローバルログアウトプロファイルを使用してすべてのセッションやすべての SP および IDP から一度にログアウトしたりできます。Global Logout Profile は、フローにおいて HTTP Redirect、HTTP POST、または HTTP Artifact バインディングを使用できます。また、本書では扱われない特定のケースで SOAP バインディングを使用することもできます。
Single Logout Profile は、Global Logout Profile の同意語として使用できます。
JBoss EAP 6 は SAML アーティファクトバインディングをサポートしません。
Web ブラウザーの SSO プロファイルフローと同様に、グローバルログアウトプロファイルフローは IDP または SP のいずれかで開始できます。
Global Logout Profile の基本的なフローは次のとおりです。
-
セッションの参加者によって IDP に発行されたログアウト: サービスプロバイダーやその他パーティーなどのセッションの参加者は、独自のセッションをプリンシパルとともに終了させ、
<LogoutRequest>
メッセージの形式で、ログアウト要求を、プリンシパルのセキュリティーアサーションを最初に発行した IDP に送信します。この要求は IDP と依拠当事者 (relyiing party) 間で直接送信することも、プリンシパルのユーザーエージェント (ブラウザー) をパススルーとして使用することで間接的に送信することもできます。 - IDP がセッションの参加者を特定: IDP が Logout Request を受信すると、そのリクエストを使用して、IDP がセッション認証またはセッション参加者として所有するセッションを含め、どの依拠当事者に依存しているセッションを終了するかを決定します。IDP は各セッションに対して、依存側に対してログアウトリクエストを発行し、各当事者からのログアウト要求を待ってから、新しいログアウト要求を元のセッション参加者に発行します。IDP で Global Logout Profile フローが開始された場合、フローはこのステップで開始し、その他のメカニズムを使用してセッションと SP が決定されます。
-
IDP によって発行されたログアウト: IDP は、すべてのセッションと関連する証明書利用者を決定すると、ログアウト要求 (
<LogoutRequest>
メッセージ) を各証明書利用者に送信し、ログアウト応答を待ちます。これらの要求は IDP と依存側間で直接送信することも、プリンシパルのユーザーエージェントを介して間接的に送信することもできます。 -
セッション参加者または機関によって発行されたログアウト応答: 各証明書利用者 (場合によっては IDP 自体を含む) は、ログアウト要求で IDP の指示に従ってセッションを終了しようとし、ログアウト応答 (
<LogoutResponse>
メッセージ) をに返します。ログアウト要求と同様に、応答は依存側と IDP 間で直接発行することも、プリンシパルのユーザーエージェントから間接的に発行することもできます。 -
IDP は元のセッション参加者にログアウト応答を発行: 証明書利用者からすべてのログアウト応答を受信すると、IDP は、ログアウトを要求した元のセッション参加者に、新しいログアウト応答 (
<LogoutResponse>
メッセージ) を送り返します。このフローの他の部分と同様に、この応答は IDP とセッションの参加者間で直接渡されるか、プリンシパルのユーザーエージェントによって間接的に渡すことができます。ログアウト要求が IDP で開始された場合は、この手順は省略されます。
グローバルログアウトプロファイルの IDP によって開始される部分は、JBoss EAP 6 ではサポートされていません。
JBoss EAP 6 では、Global Logout Profile の IDP 部分と SP 部分との間の直接の通信はサポートされません。
1.2.3. 複数の IDP および Identity Discovery プロファイル
SAML v2 を使用するブラウザーベースの SSO は、複数の IDP を持つこともサポートし、Web Browser SSO プロファイルと Global Logout プロファイルの両方で使用できます。複数の IDP が設定されている場合には、Identity Discovery SAML プロファイルを使用してプリンシパルが使用する IDP が決定されます。そのためには、ドメイン情報のあるクッキーと IDP の一覧の読み取りと書き込みを行います。
1.3. 詳細はこちら
SAML v2 の詳細は、公式 SAML 2.0 仕様を参照してください。
第2章 SAML v2 での SSO の設定方法
このセクションでは、JBoss EAP 6 を使用して SAML v2 で SSO を設定する実際の手順について詳しく説明します。
2.1. コンポーネント
Red Hat JBoss Enterprise Application Platform 6 ドキュメントの 「エンティティー」 セクションと、Security Architecture で説明されているように、SAML v2 を使用したブラウザーベースの SSOには 3 つの エンティティー と当事者が関与します。
- セキュアなリソースへのアクセスを要求するユーザーエージェント (ブラウザー) を使用するプリンシパル。
- セキュリティー保護されたリソースを格納しているサービスプロバイダー (SP)。
- プリンシパルにセキュリティーアサーションを発行し、サービスプロバイダー (SP) のセキュアなリソースへのアクセスを許可するアイデンティティープロバイダー (IDP)。
さらに、SAML v2 を介したブラウザーベースの SSO をサポートするには、次のものが必要になります。
- SP および IDP としてサービスされる個別の Web アプリケーション
- SP および IDP をホストする JBoss EAP 6 インスタンス
- SP および IDP をサポートするセキュリティードメイン
2.2. IDP と SP の設定と設定
ここでは、アプリケーションを SP または IDP のいずれかに設定する方法と、それらのアプリケーションをホストする JBoss EAP 6 インスタンスを設定する方法について説明します。
2.2.1. IDP の設定
アプリケーションを IDP として動作するように設定するには、以下の手順を実行する必要があります。
アプリケーションを作成およびデプロイする前に、セキュリティードメインを作成および設定する必要があります。
2.2.1.1. 1.IDP のセキュリティードメインの作成
IDP はクレデンシャルのプリンシパル処理、そのプリンシパルの認証および承認処理のほかに、その結果に基づいて適切な SAML v2 セキュリティーアサーションを発行します。これには、セキュリティードメインでアイデンティティーストアを設定する必要があります。このセキュリティードメインおよびアイデンティティーストアを作成する唯一の要件は、認証および承認メカニズムが適切に定義されていることです。つまり、本質的に多くの異なる ID ストア (プロパティーファイル、データベース、LDAP など) とそれに関連するログインモジュールを使用して、IDP アプリケーションをサポートできます。セキュリティーマッピングの詳細は、Red Hat JBoss Enterprise Application Platform 6 Security Architecture のセキュリティードメインのセクションを参照してください。
以下の例では、アイデンティティーストアのプロパティーファイルを使用する簡単な UsersRoles ログインモジュールが使用されます。
セキュリティードメインを作成するための CLI
/subsystem=security/security-domain=idp:add(cache-type=default)
/subsystem=security/security-domain=idp/authentication=classic:add
/subsystem=security/security-domain=idp/authentication=classic/login-module=UsersRoles:add( \ code=UsersRoles, \ flag=required, \ module-options=[ \ ("usersProperties"=>"idp-users.properties"), \ ("rolesProperties"=>"idp-roles.properties") \ ])
reload
結果の XML
<security-domain name="idp" cache-type="default"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/idp-users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/idp-roles.properties"/> </login-module> </authentication> </security-domain>
上記の CLI コマンドは、JBoss EAP 6 のスタンドアロンインスタンスを想定して実行されました。JBoss EAP 6 ドメインでの CLI の使用の詳細は、Red Hat JBoss Enterprise Application Platform 6 Administration and Configuration Guide の The Management CLI セクションを参照してください。
プロパティーファイル
UsersRoles ログインモジュールは、プロパティーファイルを使用して、ユーザー/パスワードとユーザー/ロール情報を保存します。UsersRoles モジュールの詳細は、Red Hat JBoss Enterprise Application Platform 6 セキュリティーガイド を参照してください。この例では、プロパティーファイルには以下が含まれます。
idp-users.properties
Eric=samplePass Alan=samplePass
idp-roles.properties
Eric=All Alan=
2.2.1.2. 2.IDP の web.xml ファイルの設定
IDP の web.xml
ファイルには以下が含まれている必要があります。
-
セキュアな領域の URL パターンにマップする
<url-pattern>
が含まれる<web-resource-collection>
を持つ<security-constraint>
。任意で、<security-constraint>
に許可されるロールを明記する<auth-constraint>
を含めることもできます。 -
FORM 認証用に設定された
<login-config>
。 -
<auth-constraint>
にロールが指定されている場合、これらのロールを<security-role>
で定義する必要があります。 - 必要に応じて、イメージやスタイルなどのログインフォームで使用されるリソースは、追加のセキュリティー制約で、認証前にアクセスできるように、セキュアでない追加のセキュリティー制約で指定できます (例: ログインページ)。
<security-constraint>
および <security-role>
要素を使用すると、管理者は URL パターンおよびロールを基に制限された領域または無制限の領域をセットアップできます。これにより、リソースをセキュリティーで保護することができ、保護しないこともできます。
<login-config>
は、ユーザーの認証時に IDP が使用するログインおよびエラーページを定義します。
例: web.xml
ファイル
<web-app> <display-name>IDP</display-name> <description>IDP</description> <!-- Define a security constraint that gives unlimited access to images --> <security-constraint> <web-resource-collection> <web-resource-name>Images</web-resource-name> <url-pattern>/images/*</url-pattern> </web-resource-collection> </security-constraint> <!-- Define a security constraint that requires the All role to access resources --> <security-constraint> <web-resource-collection> <web-resource-name>IDP</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>All</role-name> </auth-constraint> </security-constraint> <!-- Define the Login Configuration for this Application --> <login-config> <auth-method>FORM</auth-method> <realm-name>IDP Application</realm-name> <form-login-config> <form-login-page>/jsp/login.jsp</form-login-page> <form-error-page>/jsp/error.jsp</form-error-page> </form-login-config> </login-config> <!-- Security roles referenced by this web application --> <security-role> <description>The role that is required to log in to the IDP Application</description> <role-name>All</role-name> </security-role> </web-app>
Welcome ページはアプリケーション内で定義することが推奨されます。デフォルトでは、JBoss EAP 6 は index.jsp
というファイルを検索しますが、これは web.xml
の <welcome-file-list>
を使用して設定できます。
例: login.jsp
ファイル
<html> <head></head> <body> <form id="login_form" name="login_form" method="post" action="j_security_check" enctype="application/x-www-form-urlencoded"> <center> <p>Welcome to the <b>IDP</b></p> <p>Please login to proceed.</p> </center> <div style="margin-left: 15px;"> <p> <label for="username">Username</label> <br /> <input id="username" type="text" name="j_username"/> </p> <p> <label for="password">Password</label> <br /> <input id="password" type="password" name="j_password" value=""/> </p> <center> <input id="submit" type="submit" name="submit" value="Login"/> </center> </div> </form> </body> </html>
例: error.jsp
ファイル
<html> <head></head> <body> <p>Login failed, please go back and try again.</p> </body> </html>
2.2.1.3. 3.IDP の認証システムの設定
この認証システムは、ユーザーの認証と SAML v2 セキュリティーアサーションを発行および検証します。オーセンティケーターは、プリンシパルの認証と承認に使用されるセキュリティードメインとともに jboss-web.xml
ファイルに存在する <valve>
の形式で設定されます (ステップ 1 を参照)。
jboss-web.xml
ファイルには、認証と承認に使用するセキュリティードメインを指定する <security-domain>
、SSO バルブクラスを使用するように設定された <valve>
(例: org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve) を含める必要があります。
例: jboss-web.xml
ファイル:
<jboss-web> <security-domain>idp</security-domain> <context-root>identity</context-root> <valve> <class-name> org.picketlink.identity.federation.bindings.tomcat.idp.IDPWebBrowserSSOValve </class-name> </valve> </jboss-web>
2.2.1.4. 4.IDP に必要な依存関係の宣言
IDP として機能する web アプリケーションは、org.picketlink
クラスを見つけることができるように依存関係を jboss-deployment-structure.xml
に定義する必要があります。JBoss EAP 6 は必要なすべての org.picketlink
と関連クラスを提供するため、アプリケーションはこれらの依存関係を宣言して使用することのみが必要となります。
jboss-deployment-structure.xml を使用した依存関係の宣言
<jboss-deployment-structure> <deployment> <dependencies> <module name="org.picketlink"/> </dependencies> </deployment> </jboss-deployment-structure>
この代わりに、依存関係を META-INF/MANIFEST.MF
ファイルに定義することもできます。
META-INF/MANIFEST.MF を使用した依存関係の宣言
Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.picketlink
2.2.1.5. 5.IDP の picketlink.xml ファイルの作成および設定
picketlink.xml
ファイルは authenticator の動作を管理し、アプリケーションの起動時にロードされます。
ファイルには、少なくとも次の要素が含まれている必要があります。
-
<IdentityURL>
を使用したアイデンティの URL と、IDP で信頼されるホストを定義する<PicketLinkIDP>
。 -
SAML リクエストおよび応答の処理に必要なハンドラーのセットを定義する
<Handlers>
。
picketlink.xml ファイルの例
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1"> <IdentityURL>${idp.url::http://localhost:8080/identity/}</IdentityURL> <Trust> <Domains>localhost,example.com</Domains> </Trust> </PicketLinkIDP> <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> </Handlers> </PicketLink>
ハンドラーは、Chain of Responsibility を使用して実装されます。各ハンドラーは、picketlink.xml
で定義された順序で要求および応答でロジックを実行します。ハンドラーが設定される順序に注意することが非常に重要です。
デフォルトでは、picketlink.xml
は IDP web アプリケーションの WEB-INF ディレクトリーにあります。ただし、アプリケーション外の picketlink.xml
へのカスタムパスを設定できます。これは、複数の JBoss EAP 6 インスタンス間で複数のアプリケーションが同じ picketlink.xml
設定を共有している場合に便利です。
picketlink.xml のカスタムロケーションの設定
アプリケーションの jboss-web.xml
のバルブ要素に 2 つのパラメーターを追加して、picketlink.xml
へのパスを指定します。timerInterval は、設定をリロードする間隔をミリ秒単位で指定します。
例
<jboss-web> ... <valve> <class-name>...</class-name> <param> <param-name>timerInterval</param-name> <param-value>5000</param-value> </param> <param> <param-name>configFile</param-name> <param-value>path-to/picketlink.xml</param-value> </param> </valve> </jboss-web>
2.2.2. SP の設定
アプリケーションを SP として動作するように設定するには、以下の手順を実行する必要があります。
アプリケーションを作成およびデプロイする前に、セキュリティードメインを作成および設定する必要があります。
2.2.2.1. 1.IDP のセキュリティードメインの作成
IDP はユーザーのクレデンシャルを処理し、セキュリティー (SAML v2) アサーションを発行するため、SP はこれらのアサーションを検証する役割を担います。この検証を実行するにはセキュリティードメインが必要になりますが、アイデンティティーストアは必要ありません。この場合、SP のセキュリティードメインは SAML2LoginModule を使用する必要があります。
セキュリティードメインを追加するための CLI
/subsystem=security/security-domain=sp:add(cache-type=default)
/subsystem=security/security-domain=sp/authentication=classic:add
/subsystem=security/security-domain=sp/authentication=classic/login-module=SAML2LoginModule:add( \ code=org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule, \ flag=required)
reload
結果の XML
<security-domain name="sp" cache-type="default"> <authentication> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required"/> </authentication> </security-domain>
上記の CLI コマンドは、JBoss EAP 6 のスタンドアロンインスタンスを想定して実行されました。JBoss EAP 6 ドメインでの CLI の使用の詳細は、Red Hat JBoss Enterprise Application Platform 6 Administration and Guide の The Management CLI セクションを参照してください。
SAML2LoginModule を使用すると、認証の決定を IDP に先送りできます。これは、SP の picketlink.xml
で設定されます。
2.2.2.2. 2.SP の web.xml ファイルの設定
STS の web.xml
ファイルには以下が含まれている必要があります。
-
セキュアな領域の URL パターンにマップする
<url-pattern>
が含まれる<web-resource-collection>
を持つ<security-constraint>
。任意で、<security-constraint>
に許可されるロールを明記する<auth-constraint>
を含めることもできます。 -
<auth-constraint>
にロールが指定されている場合、これらのロールを<security-role>
で定義する必要があります。
例: web.xml ファイル
<web-app> <display-name>SP</display-name> <description>SP</description> <!-- Define a Security Constraint on this Application --> <security-constraint> <web-resource-collection> <web-resource-name>SP</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>All</role-name> </auth-constraint> </security-constraint> <!-- Security roles referenced by this web application --> <security-role> <description> The role that is required to log in to the SP Application </description> <role-name>All</role-name> </security-role>
Welcome ページはアプリケーション内で定義することが推奨されます。デフォルトでは、JBoss EAP 6 は index.jsp
というファイルを検索しますが、これは web.xml
の <welcome-file-list>
を使用して設定できます。
ログアウトプロセスでは、正常にログアウトされた時にプリンシパルを logout.jsp
にリダイレクトしようとします。このファイルがアプリケーションのディレクトリールートで定義されるようにしてください。
2.2.2.3. 3.IDP の認証システムの設定
オーセンティケーターは、セキュリティーアサーション (この場合は SAML v2 アサーション) に基づいてプリンシパルの認証を行います.この場合、IDP によって発行されます。アプリケーションに追加された各リクエストをインターセプトし、SAML アサーションがリクエストに存在するかどうかを確認し、アサーションを検証し、プリンシパルの SAML 固有の検証を実行し、要求されたアプリケーションでプリンシパルのセキュリティーコンテキストを作成します。
オーセンティケーターは、プリンシパルの認証と承認に使用されるセキュリティードメインとともに jboss-web.xml
ファイルに存在する <valve>
の形式で設定されます (ステップ 1 を参照)。
SP の jboss-web.xml
ファイルには以下が必要です。
-
認証または承認に使用されるセキュリティードメインを指定する
<security-domain>
。 -
SSO サービスプロバイダーのバルブクラスを使用するように設定された
<valve>
(例: org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator)
例: jboss-web.xml
ファイル:
<jboss-web> <security-domain>sp</security-domain> <context-root>sales-post</context-root> <valve> <class-name>org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator</class-name> </valve> </jboss-web>
2.2.2.4. 4.SP に必要な依存関係の宣言
SP として機能する web アプリケーションは、org.picketlink
クラスを見つけることができるように依存関係を jboss-deployment-structure.xml
に定義する必要があります。JBoss EAP 6 は必要なすべての org.picketlink
と関連クラスを提供するため、アプリケーションはこれらの依存関係を宣言して使用することのみが必要となります。
jboss-deployment-structure.xml を使用した依存関係の宣言
<jboss-deployment-structure> <deployment> <dependencies> <module name="org.picketlink"/> </dependencies> </deployment> </jboss-deployment-structure>
この代わりに、依存関係を META-INF/MANIFEST.MF
ファイルに定義することもできます。
META-INF/MANIFEST.MF を使用した依存関係の宣言
Manifest-Version: 1.0 Build-Jdk: 1.6.0_24 Dependencies: org.picketlink
2.2.2.5. 5.SP 用の picketlink.xml ファイルの作成および設定
picketlink.xml
ファイルは authenticator の動作を管理し、アプリケーションの起動時にロードされます。
ファイルには、少なくとも次の要素が含まれている必要があります。
-
<PicketLinkSP>
IDP ( <IdentityURL>)
の URL と SP の URL ( <ServiceURL>)
を定義します。 -
SAML リクエストおよび応答の処理に必要なハンドラーのセットを定義する
<Handlers>
。
picketlink.xml ファイルの例
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" BindingType="POST"> <IdentityURL>${idp.url::http://localhost:8080/identity/}</IdentityURL> <ServiceURL>${sales-post.url::http://localhost:8080/sales-post/}</ServiceURL> </PicketLinkSP> <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> </Handlers> </PicketLink>
推奨されませんが、BindingType="POST" を BindingType="REDIRECT" に変更して SP が HTTP/REDIRECT を使用するように設定することも可能です。
ハンドラーは、Chain of Responsibility を使用して実装されます。各ハンドラーは、picketlink.xml
で定義された順序で要求および応答でロジックを実行します。ハンドラーが設定される順序に注意することが非常に重要です。
デフォルトでは、picketlink.xml
は IDP web アプリケーションの WEB-INF ディレクトリーにあります。ただし、アプリケーション外の picketlink.xml
へのカスタムパスを設定できます。これは、複数の JBoss EAP 6 インスタンス間で複数のアプリケーションが同じ picketlink.xml
設定を共有している場合に便利です。
picketlink.xml のカスタムロケーションの設定
アプリケーションの jboss-web.xml
のバルブ要素に 2 つのパラメーターを追加して、picketlink.xml
へのパスを指定します。timerInterval は、設定をリロードする間隔をミリ秒単位で指定します。
例
<jboss-web> ... <valve> <class-name>...</class-name> <param> <param-name>timerInterval</param-name> <param-value>5000</param-value> </param> <param> <param-name>configFile</param-name> <param-value>path-to/picketlink.xml</param-value> </param> </valve> </jboss-web>
2.2.3. SP 開始フローの使用
SP-Inited Flow は、ブラウザーベースの SSO を記述する際に発生する一般的なユースケースで、Red Hat JBoss Enterprise Application Platform 6 Security Architecture ドキュメント の Browser-Based SSO Using SAML および Multiple Red Hat JBoss Enterprise Application Platform Instances and Multiple Applications Using Browser-Based SSO with SAML セクションで説明されています。つまり、プリンシパルは SP 内のセキュアなリソースにアクセスしようとします。SP は、プリンシパルのセキュリティーアサーションをチェックし、認証されていないプリンシパルを IDP にリダイレクトしてフローを開始します。IDP で認証に成功すると、プリンシパルは、リクエストされた元のリソースの検証/ 拒否アクセスを検証および許可するためのセキュリティーアサーションを使用して、初期 SP にリダイレクトされます。
手順
- プリンシパルは SP 上のセキュアなリソースへのアクセスを試行します。
- SP はプリンシパルでチェックを実行します。プリンシパルが認証されていない場合は、IDP にリダイレクトする必要があります。すでに認証されている場合は、その他のステップはすべてスキップされ、最後のステップが実行されます。
- SP は IDP を見つけ、プリンシパルのブラウザーを使用して IDP に対する認証要求を発行します。
- IDP は、設定されたアイデンティティーストアを使用してプリンシパルをログインページなどで認証しようとします。
- プリンシパルが IDP で特定された後 (ログイン成功後など)、IDP はプリンシパルのセキュリティー関連情報が含まれる SAML v2 アサーションを、プリンシパルのブラウザーを使用して SP に発行します。
- SP はプリンシパルのセキュリティーアサーションに対してチェックを実行し、これらのアサーションに含まれる情報に基づいて、SP は要求されたリソースへのアクセスを許可または拒否します。
このフローでは、追加のステップや設定は必要ありません。すべてのリダイレクトは設定済みの SP および IDP によって処理され、セキュアなリソースとセキュアでないリソースの両方へのリンクに必要な追加の変更は必要ありません。
2.2.4. IDP 関係フローの使用
前のセクション で説明したように、SAML v2 を介したブラウザーベースの SSO のほとんどの例は、SP が開始されるフローを使用していますが、SAML v2 は、IDP が開始する、または未承諾の応答フローという追加のフローをサポートします。このシナリオでは、SP は認証フローを開始せずに IDP から SAML 応答を受信します。代わりに、フローは IDP 側で開始され、認証されるとプリンシパルはリストから特定の SP を選択し、その URL にリダイレクトできます。
手順
- プリンシパルは IDP にアクセスします。
- IDP は SAML 要求や応答がないことを確認し、SAML を使用する IDP-first シナリオを想定します。
- IDP はプリンシパルの認証を行います。
- 認証後、IDP は、すべての SP アプリケーションにリンクするページで、プリンシパルが表示されている、ホスト済みセクションを表示します。
- プリンシパルは SP アプリケーションを選択します。
- IDP は、クエリーパラメーターの SAML 応答に SAML アサーションを持つサービスプロバイダーへプリンシパルをリダイレクトします。POST バインディングが使用される場合、IDP は HTTP POST を使用して SAML アサーションをサービスプロバイダーに送信します。
- SP は SAML アサーションをチェックし、アクセスを提供します。
Hosted Section
hosted section は、IDP 開始フローの認証に成功した後、またはすでに認証済みのプリンシパルが IDP のルートに直接アクセスしようとする場合に、ユーザーを指示する場所です。デフォルトでは、ホストされるセクションは /hosted/ にありますが、HostedURI
属性を <PicketLinkIDP>
要素に追加することで picketlink.xml ファイルで変更できます。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1" HostedURI="/hosted/"> ... </PicketLinkIDP> </Picketlink>
SP へのリンク
ユーザーが認証されると、IDP はすべてのサービスプロバイダーアプリケーションへのリンクが含まれるページを表示します。通常、リンクは以下のようになります。
<a href="http://localhost:8080/identity?SAML_VERSION=2.0&TARGET=http://localhost:8080/sales-post/">Sales</a>
上記のリンクは、ユーザーを TARGET クエリーパラメーター (値は、ターゲット SP アプリケーションへの URL) を渡す IDP にリダイレクトする点に注意してください。ユーザーが上記のリンクをクリックすると、IDP は要求から TARGET パラメーターを抽出し、SAML v2.0 応答を構築し、そのユーザーをターゲット URL にリダイレクトします。ユーザーが SP に到達すると、自動的に認証されます。SAML_VERSION クエリーパラメーターは、SAML 応答を作成するために IDP によって使用される必要がある SAML バージョンを指定するために使用されます。
2.2.5. グローバルログアウトプロファイルの設定
2.2.5.1. Global Logout Profile
あるサービスプロバイダーで開始されるグローバルログアウトプロファイルで、アイデンティティープロバイダー (IDP) およびすべてのサービスプロバイダーからユーザーをログアウトします。
グローバルログアウトプロファイルが適切に機能するには、最大 つの SP が IDP ごとに設定されていることを確認してください。
picketlink.xml の設定
picketlink.xml の SAML2 LogOutHandler への追加
logout.jsp ページの作成
ユーザーは、ログアウトプロセスの一部として、サービスプロバイダーアプリケーションの root ディレクトリーにある logout.jsp ページにリダイレクトされます。このページが作成されていることを確認します。
logout.jsp の例
<html> <head></head> <body> <p>You have successfully logged out.</p> </body> </html>
SP の Global Logout Profile リンク設定
SP リソースへのリンクの URL パラメーターに glo GLO=true
を使用して、グローバルログアウトプロファイルプロセスを開始します。
ログアウトリンクの例
<a href="?GLO=true">Click to LogOut</a>
2.2.5.2. ローカルログアウト
グローバルログアウトプロファイルの他に、ローカルログアウトを使用することもできます。グローバルログアウトプロファイルとは対照的に、ローカルログアウトはプリンシパルを 1 つの SP からログアウトし、セッションはそのまま IDP およびその他の SP にすべて残します。基本的に、ローカルログアウトにより、プリンシパルを単一の SP で「ローカルにログアウト」できます。
ローカルログアウトを使用するプロセスは基本的に Global Logout Profile と同じですが、logout リンクの URL パラメーターは LLO=true
の形式を取ります。
ログアウトリンクの例
<a href="?LLO=true">Click to LogOut</a>
プリンシパルが SP のローカルログアウトリンクをクリックすると、SP はセッションを無効にし、プリンシパルが設定されたログアウトページに転送します。
ローカルログアウトを使用する場合は、その結果として生じるセキュリティーへの影響に注意してください。つまり、プリンシパルが単一のサービスプロバイダーのみから切断されている場合、プリンシパルには IDP と、セキュアなリソースに引き続きアクセスできる他の SP のアクティブなセッションがあります。場合によってはこの動作が必要になることがありますが、ほとんどの場合でグローバルログアウトを使用することが強く推奨されます。
2.3. 管理コンソールを介した IDP および SP の設定
IDP と SP を手動で設定することに加えて、SAML v2 での SSO は、JBoss EAP 6 サブシステムを使用して設定することもできます。この方法は Domain Model と呼ばれ、すべての設定を個別のアプリケーションではなく JBoss EAP 6 インスタンスに一元化できるようにします。これにより、管理コンソールや CLI などの JBoss EAP 管理インターフェースを使用して SSO 設定の作成および更新が可能になります。
フェデレーション
JBoss EAP サブシステムを使用して IDP と SP を設定およびデプロイする場合、それらは Federation にまとめられます。Federation は Circle of Trust として理解することができます。Circle of trust には、共通の設定 (証明書、SAML 固有の設定など) を使用するアプリケーション、相互に信頼しあい、ユーザーの識別に使用するプロセスを正確に文書化するドメイン、使用する認証システムの種類、結果として作成される認証クレデンシャルと関連のあるポリシーなどが含まれます。各フェデレーションには、IDP と多くの SP があります。また、フェデレーションは SP と IDP 間の信頼関係を定義し、各 SP がその情報を個別に追跡し、維持する必要性を取り除きます。
2.3.1. サブシステムの設定
サブシステムを使用してフェデレーションを設定する前に、JBoss EAP 6 で有効化し、設定する必要があります。サブシステムを有効にして設定するには、以下の手順が必要です。
これらのステップは、JBoss EAP 6 インスタンスが実行されていないときに実行することをお勧めします。
2.3.1.1. 1.エクステンションの更新
JBoss EAP 6 設定ファイルでは、スタンドアロンインスタンスの standalone.xml
またはドメインの domain.xml
に org.wildfly.extension.picketlink
拡張を追加します。
<extensions> ... <extension module="org.wildfly.extension.picketlink"/> ... </extensions>
2.3.1.2. 2.サブシステムの追加
JBoss EAP 6 設定ファイルでは、スタンドアロンインスタンスの standalone.xml
またはドメインの domain.xml
に jboss:domain:picketlink-federation:1.1
サブシステムを追加します。
<profile> ... <subsystem xmlns="urn:jboss:domain:picketlink-federation:1.1"/> ... </profile>
設定の例は、JBoss EAP 6 インストールディレクトリーの下の docs/examples/configs/standalone-picketlink.xml
ファイルにもあります。
2.3.2. すこしのセットアップ
サブシステムのセットアップと設定が完了したら、管理インターフェイスを使用してフェデレーションを設定できます。フェデレーションを設定するには、次の手順が必要です。
2.3.2.1. 1.SP および IDP アプリケーションの準備
前のセクション で説明したように、SAMLv2 を使用して SSO を手動で設定する場合は、以下のファイルを作成または更新する必要があります。
-
web.xml
-
jboss-web.xml
-
picketlink.xml
-
jboss-deployment-structure.xml
サブシステムを使用して SAML v2 を使用して SSO のフェデレーションを設定すると、設定の大半は管理インターフェースによって発生しますが、これらのファイルは更新されません。アプリケーションで実行する必要がある唯一の設定は、IDPs および SPs の web.xml
ファイルで <security-constraint>
および関連づけられた <security-role>
を設定することです。さらに、web.xml
の <login-config>
と、ログインページとエラーページも IDP に存在する必要があります。
設定済みの IDP および SP の準備
前のセクションで説明したように IDP または SP がすでに設定されている場合は、以下のファイルを削除する必要があります。
-
jboss-web.xml
-
picketlink.xml
-
jboss-deployment-structure.xml
アプリケーションの準備ができたら、それらをデプロイできます。
2.3.2.2. 2.管理インターフェイスを介したフェデレーションの作成
JBoss EAP 6 インスタンスが設定され、アプリケーションがセットアップおよびデプロイされると、管理コンソールからフェデレーションを作成できます。
- たとえば、Web ブラウザーを使用して管理コンソール (http://localhost:9990/console) に移動します。
- 上部の 設定 タブをクリックします。
- 左側のメニューで PicketLink → Federation をクリックします。
-
追加 ボタンをクリックして、新しいフェデレーションを作成します。
- フェデレーションの名前を入力し、保存 をクリックします。
-
フェデレーションの ビュー をクリックして、設定を開始します。
-
フェデレーション タブで ID プロバイダー を選択し、追加 をクリックして新しい IDP を設定します。
-
デプロイされた IDP の情報を入力し、保存 をクリックします。
-
フェデレーション タブで サービスプロバイダー を選択し、追加 をクリックして新しい SP を設定します。
-
展開された SP の情報を入力し、保存 をクリックします。
ID プロバイダー サブタブと サービスプロバイダー サブタブの両方の 詳細 セクションを使用して、追加の詳細を設定したり、既存の IDP または SP を更新したりできます。
フェデレーション内の IDP または SP (IDP または SP によって使用されるセキュリティードメインを含む) に関連して設定が変更された場合は、影響を受ける IDP または SP、あるいはその両方を再起動するのが最適です。これは、ID プロバイダー および サービスプロバイダー サブタブの 再起動 オプションを使用して実行できます。
2.4. IDP のアイデンティティーストアの設定
IDP はセキュリティードメインを使用するため、IDP の機能は、これをサポートする実際の ID ストアから独立しています。これにより、管理者は IDP のセキュリティードメインを設定する際に多くのオプションを利用できます。セキュリティードメインとログインモジュールの詳細は、Red Hat JBoss Enterprise Application Platform 6 セキュリティーアーキテクチャー のセキュリティーサブシステムセクションを参照してください。セキュリティードメインのログインモジュールを設定するのと同様に、異なる ID ストアがさまざまな機能とパフォーマンスのトレードオフを提供することに注意してください。
アイデンティティーストアを使用するセキュリティードメインを設定するには、以下の手順が必要です。
本書の目的上、データベースログインモジュールおよび LDAP ログインモジュールは例として示されていますが、他のアイデンティティーストアやログインモジュールは IDP と使用するように設定することもできます。
このセクションの CLI コマンドは、JBoss EAP 6 のスタンドアロンインスタンスを想定して実行されました。JBoss EAP 6 ドメインでの CLI の使用の詳細は、Red Hat JBoss Enterprise Application Platform 6 Administration and Guide の The Management CLI セクションを参照してください。
2.4.1. 1.アイデンティティーストアの設定
セキュリティードメインおよびログインモジュールを設定して、アイデンティティープロバイダー、アイデンティティープロバイダー、およびそのアイデンティティープロバイダーへの接続を使用するには、設定が必要です。
2.4.1.1. Database Login Module のアイデンティティーストアの設定
Database Login Module の ID ストアを設定するには、次の操作が必要です。
- データベースの設定
- データソースの追加
データベースの設定
データベースベースのアイデンティティーストアに必要な最初の項目は、ログインモジュールが使用するデータベースです。
次のデータポイントが必要です。
- ユーザー名
- パスワード
- ロール
- ロールグループ
Database Login モジュールでは、ユーザー名をパスワードにマップするクエリーと、ユーザー名をロールおよびロールグループにマップするクエリーを作成する必要があります。この情報はさまざまな方法でデータベースに保存できますが、テーブルを含むデータベースの作成については本書の範囲外となります。この例では、以下の表が作成されていることを前提としています。
username | passwd |
---|---|
Sarah | Testing123! |
username | role | role-group |
---|---|---|
Sarah | sample | SSO-Users |
データソースの追加
データソースの作成は、このドキュメントの範囲外です。データソースの設定の詳細は、管理および設定ガイド のデータソース管理セクションを参照してください。
この例では、idpDS という名前のデータソースが作成され、適切に設定され 、JBoss EAP 6 インスタンスにデプロイされていることを前提とします。このデータソースは、sso-users および sso-roles テーブルを格納するデータベースに接続します。
2.4.1.2. LDAP ログインモジュールのアイデンティティーストアの設定
LDAP ログインモジュールの設定前に、適切に設定された LDAP サーバーが必要です。Database ログインモジュールとは異なり、LDAP ログインモジュールの設定にデータソースは必要ありません。LDAP の基本と、それが JBoss EAP 6 セキュリティーにどのように関連するかについては、Red Hat JBoss Enterprise Application Platform 6 セキュリティーアーキテクチャー のドキュメントで説明されています。
LDAP サーバーの設定
LDAP サーバーの設定は本ガイドの範囲外です。LDAP サーバーの設定の詳細は、RHEL システムの管理ガイド を参照してください。この例では、http://ldaphost.example.com:1389/ で LDAP サーバーにアクセスできます。
ディレクトリー情報
LDAP サーバーのディレクトリー構造と編成は、ユースケースや組織のニーズによって大幅に異なる場合があります。この例では、以下のエントリーが LDIF 形式で作成されています。
dn: dc=example,dc=com objectclass: top objectclass: dcObject objectclass: organization dc: example o: Example #============================= dn: ou=People,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: People #============================= dn: uid=jsmith,ou=People,dc=example,dc=com objectclass: top objectclass: uidObject objectclass: person uid: jsmith cn: John sn: Smith userPassword: theduke #============================= dn: ou=Roles,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: Roles #============================= dn: cn=Sample,ou=Roles,dc=example,dc=com objectclass: top objectclass: groupOfNames cn: Sample member: uid=jsmith,ou=People,dc=example,dc=com description: the Sample group
2.4.2. 2.セキュリティードメインの追加
アイデンティティーストア自体が設定され、JBoss EAP 6 インスタンスとアイデンティティーストア間の接続が設定されたら、セキュリティードメインを作成および設定できます。次のコマンドは、MY-DOMAIN をセキュリティードメインの目的の名前に置き換えて、空のセキュリティードメインを作成する方法を示しています。
セキュリティードメインを追加する CLI
/subsystem=security/security-domain=MY-DOMAIN:add(cache-type=default)
2.4.3. 3.認証セクションとログインモジュールのセキュリティードメインへの追加
空のセキュリティードメインを作成したら、ログインモジュールを追加して authentication セクションを作成する必要があります。次のコマンドは、MY-DOMAIN をセキュリティードメインの名前に置き換えて、既存のセキュリティードメインに空の認証セクションを追加する方法を示しています。
セキュリティードメインに認証セクションを追加するための CLI
/subsystem=security/security-domain=MY-DOMAIN/authentication=classic:add
空の認証セクションが作成されると、ログインモジュールを追加して、必要なアイデンティティーストアを使用するように設定できます。ログインモジュールをセキュリティードメインに追加したら、通常、設定の再読み込みが必要になります。
以下は、ログインモジュールを追加して設定を再ロードし、MY-DOMAIN、MY-LOGIN-MODULE、および MY-CONFIGURATION を適切な情報に置き換えるための一般的なコマンド構造です。
/subsystem=security/security-domain=MY-DOMAIN/authentication=classic/login-module=MY-LOGIN-MODULE:add( MY-CONFIGURATION )
reload
2.4.3.1. データベースログインモジュールの追加
データベースログインモジュールを使用するための認証セクションを設定する CLI
/subsystem=security/security-domain=idp-db-domain/authentication=classic/login-module=Database:add( \ code=Database, \ flag=required, \ module-options=[ \ ("dsJndiName"=>"java:/idpDS"), \ ("principalsQuery"=>"select passwd from 'sso-users' where username=?"), \ ("rolesQuery"=>"select role, role-group from 'sso-roles' where username=?") \ ])
CLI 設定の再ロード
reload
結果の XML
<security-domain name="idp-db-domain" cache-type="default"> <authentication> <login-module code="Database" flag="required"> <module-option name="dsJndiName" value="java:/idpDS"/> <module-option name="principalsQuery" value="select passwd from 'sso-users' where username=?"/> <module-option name="rolesQuery" value="select role, role-group from 'sso-roles' where username=?"/> </login-module> </authentication> </security-domain>
2.4.3.2. LDAP ログインモジュールの追加
LdapExtended ログインモジュール (推奨) と Ldap ログインモジュールの両方を設定するために必要な手順は、Red Hat JBoss Enterprise Application Platform 6 の Identity Management を設定する方法 を参照してください。
2.5. SP および IDP を使用した SSL/TLS の設定
SSL/TLS の基本は、Red Hat JBoss Enterprise Application Platform 6 セキュリティーアーキテクチャー で説明されています。ブラウザーベースの SSO 環境に SSL/TLS サポートを追加することは、SSO 以外の環境に追加する場合とは非常に異なります。IDP と SP の両方に HTTPS コネクターを追加して、トラフィックのセキュリティーを保護することができます。
新しい HTTPS コネクターを追加します。
https スキーマ、https ソケットバインディング (デフォルトは 8443) を使用し、安全に設定されている HTTPS という名前のセキュアなコネクターを作成します。
/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
SSL/TLS 暗号化証明書およびキーを設定します。
例の値を独自の値に置き換えて、SSL/TLS 証明書を設定します。この例では、キーストアがサーバー設定ディレクトリー (管理対象ドメインの場合は EAP_HOME/domain/configuration/) にコピーされることを前提としています。
/subsystem=web/connector=HTTPS/ssl=configuration:add(name=https,certificate-key-file="${jboss.server.config.dir}/keystore.jks",password=SECRET, key-alias=KEY_ALIAS)
プロトコルを TLSv1 に設定します。
/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=TLSv1)
上記の CLI コマンドは、JBoss EAP 6 のスタンドアロンインスタンスを想定して実行されました。JBoss EAP 6 ドメインでの CLI の使用の詳細は、Red Hat JBoss Enterprise Application Platform 6 Administration and Guide の The Management CLI セクションを参照してください。
オプション: IDP での追加の CertificateRoles ログインモジュールの使用
オプションで、SSL/TLS 認証を検証するための別のログインモジュール (CertificateRoles) をセキュリティードメインに追加できます。これは、CertificateRoles ログインモジュール (Certificate ログインモジュールの拡張) と組み合わせたパスワードスタッキングを利用します。CertificateRoles ログインモジュールの詳細は、Red Hat JBoss Enterprise Application Platform 6 セキュリティーガイド を参照してください。
以下の設定例は、指定の証明書を検証します。証明書が指定されていない場合、または認証が失敗した場合、手順はユーザー/パスワードベースの認証にフォールバックします。
以下は例になります。
<security-domain name="idp" cache-type="default"> <authentication> <login-module code="CertificateRoles" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="securityDomain" value="idp"/> <module-option name="verifier" value="org.jboss.security.auth.certs.AnyCertVerifier"/> </login-module> <login-module code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="users.properties"/> <module-option name="rolesProperties" value="roles.properties"/> </login-module> </authentication> <jsse keystore-password="change_it" keystore-url="${jboss.server.config.dir}/server.keystore" truststore-password="change_it" truststore-url="${jboss.server.config.dir}/server.keystore" client-auth="true"/> </security-domain>
2.6. その他の機能
2.6.1. SAML Assertion Encryption
IDP と SP との間で SSL/TLS 暗号化を提供する他に、SAML アサーション自体も暗号化できます。これは、SSL/TLS を使用しないなど、セキュアでない方法で送信される SAML v2 アサーションのセキュリティーを保護する際に便利です。
2.6.1.1. IDP および SP の暗号化を直接有効にする方法
IDP および SP で直接セキュリティーアサーションの暗号化を有効にするには、IDP ファイルと SP picketlink.xml
ファイルの両方で以下の手順を実行する必要があります。
- Encrypt および SupportsSignatures を有効化します。
- ハンドラーを追加します。
- KeyProvider を設定します
1. Encrypt および SupportsSignatures の有効化
暗号化を有効にするには、<PicketLinkIDP>
および <PicketLinkSP>
を更新する必要があります。
IDP の場合は、Encrypt
および SupportsSignatures
属性を <PicketLinkIDP>
に、true になるように追加または更新します。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1" Encrypt="true" SupportsSignatures="true"> ... </PicketLinkIDP> </PicketLink>
SP の場合は、<PicketLinkSP>
の SupportsSignatures
に追加または更新します。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" SupportsSignatures="true"> ... </PicketLinkSP> </PicketLink>
2. ハンドラーの追加
さらに、ハンドラーを <Handlers>
に追加する必要があります。
IDP では、SAML2EncryptionHandler
および SAML2SignatureValidationHandler
を picketlink.xml
ファイルに追加します。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2EncryptionHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2SignatureValidationHandler" /> </Handlers> </PicketLink>
SP では、SAML2SignatureGenerationHandler
および SAML2SignatureValidationHandler
を picketlink.xml
ファイルに追加します。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2SignatureGenerationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2SignatureValidationHandler" /> </Handlers> </PicketLink>
ハンドラーは、Chain of Responsibility を使用して実装されます。各ハンドラーは、picketlink.xml
で定義された順序で要求および応答でロジックを実行します。ハンドラーが設定される順序に注意することが非常に重要です。
SAML2SignatureGenerationHandler は SAML2EncryptoinHandler と同じチェーンで設定することはできません。これにより、SAML メッセージが複数回署名されます。
3. キープロバイダーの設定
最後に、<KeyProvider>
要素を 両方の picketlink.xml
ファイルに追加する必要があります。この要素は、セキュリティーアサーションの暗号化および復号化に使用される Java キーストアにアクセスするための場所と認証情報を提供します。Java キーストアの生成例は、こちら を参照してください。
IDP の要素は <PicketLinkIDP>
に追加する必要があります。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1" Encrypt="true" SupportsSignatures="true"> ... <KeyProvider ClassName="org.picketlink.identity.federation.core.impl.KeyStoreKeyManager"> <Auth Key="KeyStoreURL" Value="/my_keystore.jks" /> <Auth Key="KeyStorePass" Value="store123" /> <Auth Key="SigningKeyPass" Value="test123" /> <Auth Key="SigningKeyAlias" Value="servercert" /> <ValidatingAlias Key="idp.example.com" Value="servercert" /> <ValidatingAlias Key="localhost" Value="servercert" /> <ValidatingAlias Key="sp1.example.com" Value="servercert" /> <ValidatingAlias Key="sp2.example.com" Value="servercert" /> </KeyProvider> ... </PicketLinkIDP> ... <PicketLink>
SP の場合は、<PicketLinkSP>
に要素を追加する必要があります。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" SupportsSignatures="true"> ... <KeyProvider ClassName="org.picketlink.identity.federation.core.impl.KeyStoreKeyManager"> <Auth Key="KeyStoreURL" Value="/my_keystore.jks" /> <Auth Key="KeyStorePass" Value="store123" /> <Auth Key="SigningKeyPass" Value="test123" /> <Auth Key="SigningKeyAlias" Value="servercert" /> <ValidatingAlias Key="idp.example.com" Value="servercert" /> <ValidatingAlias Key="localhost" Value="servercert" /> </KeyProvider> ... </PicketLinkSP> </PicketLink>
アサーションを適切に暗号化および復号化するには、IDP は署名を生成する必要があり、SP はこれらの署名を検証し、その出所を特定する必要があります。これは、<ValidatingAlias>
要素を使用して実行できます。IDP には、信頼される信頼されたサーバー/ドメイン (<Trust>
要素のすべてのエントリー) ごとに <ValidatingAlias>
が必要です。SPS には、IDP を含むサーバー/ドメインごとに <ValidatingAlias>
が必要です。
2.6.2. アサーションでのデジタル署名
デジタル署名により、IDP は セキュリティー (SAML v2) アサーションに署名し、SP によって署名とアサーションを検証できます。これは、特に SSL/TLS を使用しないなど、セキュアでない方法で送信されるアサーションの信頼性を検証する際に便利です。
2.6.2.1. IDP および SP で直接デジタル署名を有効にする方法
IDP および SP で直接セキュリティーアサーションのデジタル署名を有効にするには、IDP ファイルと SP picketlink.xml
ファイルの両方で以下の手順を実行する必要があります。
- SupportsSignatures を有効にします。
- ハンドラーを追加します。
- KeyProvider を設定します
1. SupportsSignatures の有効化
デジタル署名を有効にするには、<PicketLinkIDP>
および <PicketLinkSP>
を更新する必要があります。
IDP および SP の場合は、<PicketLinkSP>
の SupportsSignatures
属性を true に追加または更新します。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1" SupportsSignatures="true"> ... </PicketLinkIDP> </PicketLink>
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" SupportsSignatures="true"> ... </PicketLinkSP> </PicketLink>
2. ハンドラーの追加
さらに、ハンドラーを <Handlers>
に追加する必要があります。
IDP および SP では、SAML2SignatureGenerationHandler
および SAML2SignatureValidationHandler
を picketlink.xml
ファイルに追加します。
IDP picketlink.xml
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2SignatureGenerationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2SignatureValidationHandler" /> </Handlers> </PicketLink>
SP picketlink.xml
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1"> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2SignatureGenerationHandler" /> <Handler class="org.picketlink.identity.federation.web.handlers.saml2.SAML2SignatureValidationHandler" /> </Handlers> </PicketLink>
ハンドラーは、Chain of Responsibility を使用して実装されます。各ハンドラーは、picketlink.xml
で定義された順序で要求および応答でロジックを実行します。ハンドラーが設定される順序に注意することが非常に重要です。
SAML2SignatureGenerationHandler は SAML2EncryptionHandler と同じチェーンで設定することはできません。これにより、SAML メッセージが複数回署名されます。
3. キープロバイダーの設定
最後に、<KeyProvider>
要素を 両方の picketlink.xml
ファイルに追加する必要があります。この要素は、セキュリティーアサーションの署名に使用される Java キーストアにアクセスするための場所およびクレデンシャルを提供します。Java キーストアの生成例は、こちら を参照してください。
IDP の要素は <PicketLinkIDP>
に追加する必要があります。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:2.1" SupportsSignatures="true"> ... <KeyProvider ClassName="org.picketlink.identity.federation.core.impl.KeyStoreKeyManager"> <Auth Key="KeyStoreURL" Value="/my_keystore.jks" /> <Auth Key="KeyStorePass" Value="store123" /> <Auth Key="SigningKeyPass" Value="test123" /> <Auth Key="SigningKeyAlias" Value="servercert" /> <ValidatingAlias Key="idp.example.com" Value="servercert" /> <ValidatingAlias Key="localhost" Value="servercert" /> <ValidatingAlias Key="sp1.example.com" Value="servercert" /> <ValidatingAlias Key="sp2.example.com" Value="servercert" /> </KeyProvider> ... </PicketLinkIDP> ... <PicketLink>
SP の場合は、<PicketLinkSP>
に要素を追加する必要があります。
<PicketLink xmlns="urn:picketlink:identity-federation:config:2.1"> ... <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" SupportsSignatures="true"> ... <KeyProvider ClassName="org.picketlink.identity.federation.core.impl.KeyStoreKeyManager"> <Auth Key="KeyStoreURL" Value="/my_keystore.jks" /> <Auth Key="KeyStorePass" Value="store123" /> <Auth Key="SigningKeyPass" Value="test123" /> <Auth Key="SigningKeyAlias" Value="servercert" /> <ValidatingAlias Key="idp.example.com" Value="servercert" /> <ValidatingAlias Key="localhost" Value="servercert" /> </KeyProvider> ... </PicketLinkSP> </PicketLink>
アサーションを適切に署名して確認するには、IDP は署名を生成する必要があり、SP はこれらの署名を検証し、その出所を特定する必要があります。これは、<ValidatingAlias>
要素を使用して実行できます。IDP には、信頼される信頼されたサーバー/ドメイン (<Trust>
要素のすべてのエントリー) ごとに <ValidatingAlias>
が必要です。SPS には、IDP を含むサーバー/ドメインごとに <ValidatingAlias>
が必要です。
2.6.3. AJAX リクエストの処理
特定のケースでは、SP がセキュアなリソースに対する AJAX 要求を受信する必要がある場合があります。これは、追加の設定を必要とせずに自動的に処理されるので、認証および承認されたユーザーは問題なく AJAX 呼び出しを行うことができます。これは、要求に X-Requested-With ヘッダーが存在するかどうかをチェックすることによって実行されます。さらに、ユーザーが認証されていない場合、または要求にヘッダー XMLHttpRequest が含まれている場合に、IDP はログインページではなく 403 (禁止) ステータスコードで応答します。