5.5. SAML でブラウザーベースの SSO を使用する複数の Red Hat JBoss Enterprise Application Platform インスタンスと複数のアプリケーション

JBoss EAP は、web アプリケーションで SAML を介してブラウザーベースの SSO をサポートし、アイデンティティープロバイダーのホストもサポートします。アイデンティティープロバイダーをホストするには、セキュリティードメイン (この例では idp-domain) に定義した認証方法を設定する必要があります。この例では、 idp-domain が DatabaseLoginModule を認証方法として使用するよう設定されます。IDP アプリケーション (例: IDP.war) がその JBoss EAP インスタンス (この例では EAP-IDP) にデプロイされ、idp-domain をアイデンティティーストアとして使用するよう設定されます。IDP.war は、アプリケーションの機能とともにアイデンティティーストアを使用してユーザーを認証し、ユーザーのアイデンティティーとロール情報が含まれる SAML トークンを発行します。EAP1、EAP2、および EAP3 の 3 つの JBoss EAP インスタンスは、それぞれ個別の SP として動作するアプリケーション sampleAppA.war、sampleAppB.war、および sampleAppC をホストします。各 JBoss EAP インスタンスには、SAML2LoginModule を認証方法として使用するよう設定されている sso-domain セキュリティードメインがあります。各アプリケーションには、SSO をサポートし、 IDP.war をアイデンティティープロバイダーとして使用し、認証に HTTP/POST バインディングを使用する機能が含まれています。また、各アプリケーションは sso-domain を使用してパス /secure/* をセキュア化するよう設定され、承認の処理に独自のロールのリストを提供します。

この例では、idp-domain セキュリティードメインの DatabaseLoginModule によって使用されるデータベースに以下のユーザーが追加されています。

EAP-IDP の起動時、管理インターフェースが起動した後に security サブシステムが含まれるサブシステムとデプロイされたアプリケーションが起動します。security サブシステムには idp-domain と IDP.war が含まれます。idp-domain はデータベースに接続し、DatabaseLoginModule ログインモジュールに設定されたようにユーザー名、パスワード、およびロールをロードします。機密情報が DatabaseLoginModule ログインモジュールの設定にプレーンテキストで保存されないようにするため、データベースのパスワードなどの一部のフィールドを隠すようパスワードハッシュが設定されます。IDP.war は 認証と承認に idp-domain を使用します。また、認証されたユーザーに SAML トークンを発行し、認証の対象となるユーザーに対して簡単なログインフォームを提供するため、IDP.war は jboss-web.xml、web.xml、picketlink.xml、および jboss-deployment-structure.xml を使用して設定されます。これにより、IDP として機能できるようになります。

EAP1、EAP2、および EAP3 の起動時、管理インターフェースが起動した後に security を含むサブシステムとデプロイされたアプリケーションが起動します。security サブシステムには各インスタンスの sso-domain が含まれ、それぞれ sampleAppA.war、sampleAppB.war、および sampleAppC.war が含まれます。sso-domain は SAML2LoginModule ログインモジュールを使用するよう設定されますが、アプリケーションに依存して適切な SAML トークンを提供します。よって、sso-domain を使用するすべてのアプリケーションは適切に IDP に接続して SAML トークンを取得する必要があります。この場合、各 sampleAppA、sampleAppB、および sampleAppC は jboss-web.xml、web.xml、picketlink.xml、および jboss-deployment-structure.xml を介して設定され、IDP のログインフォームを使用して IDP.war から SAML トークンを取得します。

また、各アプリケーションは独自の許可されるロールでも設定されます。

認証されていないユーザーが sso-domain によってセキュア化された URL (すべてのアプリケーションの /secure/*) にアクセスしようとすると、ユーザーは IDP.war のログインページにリダイレクトされます。その後、ユーザーはフォームを使用して認証され、ユーザーのアイデンティティーとロール情報が含まれる SAML トークンが発行されます。ユーザーは元の URL にリダイレクトされ、SAML トークンが SP であるアプリケーションに提示されます。アプリケーションは SAML トークンが有効であることを確認し、SAML トークンによって提供されたロールとアプリケーションで設定されたロールを基にしてユーザーを承認します。ユーザーに SAML トークンが発行された後、同じ IDP を使用して SSO によってセキュア化された別のアプリケーションでは、ユーザーはそのトークンを使用して認証および承認されます。SAML トークンの期限が切れ、無効になると、ユーザーは IDP から新しい SAML トークンを取得する必要があります。

この例では、Eric が EAP1/sampleAppA/secure/hello.html にアクセスすると、ログインのために EAP-IDP/IDP/login.html にリダイレクトされます。正常にログインした後、Eric にユーザー情報とロール all が含まれる SAML トークンが発行され、EAP1/sampleAppA/secure/hello.html にリダイレクトされます。この SAML トークンが sampleAppA に提示され、トークンの確認後にロールを基にして承認が行われます。sampleAppA は、ロール all および AB の /secure/* へのアクセスを許可します。 Eric は all ロールを持っているため、EAP1/sampleAppA/secure/hello.html にアクセスできます。

Eric が EAP2/sampleAppB/secure/hello.html にアクセスしようとすると、この SP に対しては認証されていないため、認証リクエストとともに IDP.war にリダイレクトされます。Eric はすでに IDP に対して認証されているため、その SP に対する新しい SAML トークンとともに IDP.war によって EAP2/sampleAppB/secure/hello.html にリダイレクトされ、再認証は必要ありません。sampleAppB によって新しい SAML トークンがチェックされ、ロールを基に承認が行われます。sampleAppB は、ロール all および AB の /secure/* へのアクセスを許可します。 Eric は all ロールを持っているため、EAP2/sampleAppB/secure/hello.html にアクセスできます。Eric が EAP3/sampleAppC/secure/hello.html にアクセスする場合も同様に処理されます。

SAML トークンがグローバルログアウトによって無効になった後、Eric が EAP1/sampleAppA/secure/hello.html や、EAP2/sampleAppB/secure/* または EAP3/sampleAppC/secure/* 以下の URL に戻ろうとすると、再認証のために EAP-IDP/IDP/login.html へリダイレクトされ、新しい SAML トークンが発行されます。

Amar が EAP1/sampleAppA/secure/hello.html または EAP2/sampleAppB/secure/hello.html にアクセスしようとすると、Eric と同様に処理されます。Amar は AB ロールを持ち、EAP1/sampleAppA/secure/* および EAP2/sampleAppB/secure/* のみにアクセスできます。そのため、 EAP3/sampleAppC/secure/hello.html にアクセスしようとすると、SAML トークンの保持または取得が必要になりますが、EAP3/sampleAppC/secure/hello.html の閲覧は制限されます。Brian も同様ですが、EAP3/sampleAppC/secure/* のみにアクセスできます。Alan はロールを持たないため、サービスプロバイダーのセキュアな領域にアクセスしようとすると、SAML トークンの保持または取得が必要になりますが、閲覧はすべて制限されます。各 SP には、承認の有無に関わらず、すべてのユーザーが SAML トークンを取得しなくても閲覧可能なセキュアでない領域もあります。