5.7. Kerberos を使う Desktop SSO を使用した Web アプリケーションへの SSO の提供
ここでは、JBoss で Kerberos を使用して web アプリケーションに SSO を提供する方法について説明します。JBoss EAP インスタンス EAP1 は作成済みで、スタンドアロンサーバーとして実行されています。sampleAppA と sampleAppB の 2 つの web アプリケーションが EAP1 にデプロイされています。両方の web アプリケーションと EAP1 は、Kerberos でデスクトップベースの SSO を使用して認証するよう設定されています。
5.7.1. Security
JBoss EAP は、SPNEGO と JBoss Negotiation による web アプリケーションでの SSO に対する Kerberos の使用をサポートします。Kerberos と SPNEGO に特化した情報は、「サードパーティーの SSO 実装」を参照してください。JBoss EAP とデプロイされた web アプリケーションが認証に Kerberos を使用するようにするには、2 つのセキュリティードメインを作成する必要があります。最初のセキュリティードメイン host-domain は、kerberos ログインモジュールで設定され、Kerberos サーバーへ接続します。これにより、JBoss EAP のコンテナーレベルでの認証が可能になります。2 つ目のセキュリティードメイン spnego-domain は、2 つのログインモジュールで作成されます。その 1 つは spnego ログインモジュールを使用して host-domain に接続し、ユーザーを認証します。もう 1 つは別のログインモジュール (プロパティーファイルを使用してユーザーをロールにマップする UsersRoles など) を使用して、承認の決定に使用するロール情報をロードします。
これら 2 つのログインモジュールは、password-stacking を利用して、承認モジュールのユーザーとロールを認証モジュールのユーザーにマップします。EAP1 は host-domain と spnego-domain の両方で設定されます。アプリケーションは、spnego-domain を使用して認証を実行し、承認のためにユーザーのロールを取得するよう、 web.xml および jboss-web.xml を介して設定されます。また、セクリティートークンをオペレーティングシステムからブラウザーに渡せない場合のために、FORM 認証をフォールバック認証としてアプリケーションに設定することもできます。FORM 認証がフォールバックとして設定された場合、追加のセキュリティードメインを追加してサポートする必要があります。このセキュリティードメインは Kerberos と SPNEGO には依存せず、FORM 認証のみ (ユーザー名とパスワードの検証およびロール) をサポートする必要があります。各アプリケーションは、spnego-domain を使用するよう設定され、FORM 認証をフォールバックとして提供するよう設定されます。また、各アプリケーションはパス /secure/* をセキュアにするよう設定され、承認の処理に独自のロールリストを提供します。
5.7.1.1. 仕組み
以下のユーザーが Kerberos サーバーに作成されています。
| ユーザー名 | パスワード |
|---|---|
| Brent | samplePass |
| Andy | samplePass |
| Bill | samplePass |
| Ron | samplePass |
以下のロールは、 password-stacking オプションを useFirstPass に設定してチェーンされた追加のモジュールを介してユーザーにマップします。
| ユーザー名 | ロール |
|---|---|
| Brent | all |
| Andy | A |
| Bill | B |
| Ron |
各アプリケーションには以下のロールが設定されています。
| アプリケーション/SP | 許可されるロール |
|---|---|
| sampleAppA | all、A |
| sampleAppB | all、B |
起動時に、EAP1 はコアサービスをロードしてから security およびその他のサブシステムをロードします。 host-domain は Kerberos サーバーへの接続を確立し、spnego-domain は host-domain に接続します。 sampleAppA と sampleAppB がデプロイされ、認証のために spnego-domain に接続します。
Brent は Kerberos でセキュア化されたコンピューターにログインしています。Brent はブラウザーを開き、sampleAppA/secure/hello.html へのアクセスを試みます。このページはセキュアであるため、認証が必要になります。EAP1 は、Brent のコンピューターに設定されている Kerberos Key Distribution Center (Kerberos サーバー) へのキーを要求するリクエストを送信するよう、ブラウザーに指示します。ブラウザーがキーを取得した後、sampleAppA に送信されます。sampleAppA はチケットを spnego-domain に送信します。そこでチケットがアンパックされ、設定済みの Kerberos サーバーとともに host-domain によって認証が実行されます。チケットが認証されたら、Brent のロールは sampleAppA に戻され、承認が実行されます。Brent は all ロールを持っているため、sampleAppA/secure/hello.html にアクセスできます。Brent が sampleAppB/secure/hello.html にアクセスする場合も同じ処理が発生します。all ロールを持っているため、アクセスが許可されます。Andy と Bill にも同じ処理が発生しますが、Andy は sampleAppA/secure/hello.html のみにアクセスでき、sampleAppB/secure/hello.html にはアクセスできません。Bill はこの逆で、sampleAppB/secure/hello.html のみにアクセスでき、sampleAppA/secure/hello.html にはアクセスできません。Ron は sampleAppA/secure/hello.html または sampleAppB/secure/hello.html の認証に成功しますが、ロールを持たないためどちらにもアクセスできません。
オフィスのネットサークに接続する個人のラップトップなど、Andy が Kerberos でセキュア化されていないコンピューターから sampleAppA/secure/hello.html にアクセスしようとすると、フォールバックのログインとして FORM ログインページに転送されます。Andy のクレデンシャルはフォールバックセキュリティードメイン経由で認証され、承認の処理が続行されます。
Revised on 2019-11-27 13:00:40 CET
