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. セキュリティー
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 サーバーに作成されています。
表5.9 Kerberos ユーザー
ユーザー名 | パスワード |
---|---|
Brent | samplePass |
Andy | samplePass |
Bill | samplePass |
Ron | samplePass |
以下のロールは、 password-stacking
オプションを useFirstPass
に設定してチェーンされた追加のモジュールを介してユーザーにマップします。
表5.10 ユーザーロール
ユーザー名 | ロール |
---|---|
Brent | all |
Andy | A |
Bill | B |
Ron |
各アプリケーションには以下のロールが設定されています。
表5.11 アプリケーションロール
アプリケーション/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 サーバー) へのキーを要求するリクエストを送信するよう、ブラウザーに指示します。ブラウザーがキーを取得すると、これは simpleAppA
に送信されます。simpleAppA
はチケットを 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 2023-01-28 12:04:31 +1000