はじめに
本記事は「LibertyとIBM Verifyで試すSAML認証」シリーズの第3回（最終回）です。LibertyとVerifyを使用したSAML認証の仕組みをより深く理解するため、設定内容を確認していきます。
【1】SAML認証とは
【2】動かして体験しよう
【3】仕組みの詳細を理解する（本記事）
Verifyの定義
アクセス履歴とSAMLアサーション
Verifyのアプリケーション一覧から、対象アプリケーションの3点メニューにある「アプリの使用量」を選択します。
ここで、対象アプリのログイン状況をグラフで確認できます。画面下部には各ログインの履歴が表示されます。
各ログインの履歴をクリックすると、クリック対象の詳細が表示されます。
ここからSAMLアサーションの「詳細の表示」リンクをクリックします。
SAMLアサーションに含まれる情報が表示されます。
さらに「XMLのオープン」をクリックすると、実際に送信されたSAMLアサーションのXMLデータが表示されます。
この例では、SAMLアサーションにgroupIdsとして3つのグループが含まれ、そのうち1つがgroup1であることが分かります。
認証後のアプリケーション挙動が期待通りでない場合、まずSAMLアサーションの内容が想定通りか確認しましょう。
アプリケーション定義
Verifyのアプリケーション一覧から、対象アプリケーションの設定（歯車アイコン）を開きます。サインオンタブには以下の項目があります。
| 項目 | 説明 |
|---|---|
| サービス・プロバイダーの固有ID | IdP側でSPを一意に識別するためのID。 SPメタデータから設定。 |
| SAMLアサーションを受信するサービス・プロバイダー・エンドポイント | SPがアサーションを受信するURL。 SPメタデータから設定。 |
| ターゲットURL | 認証成功後に遷移するSPの入口URL。 |
| サービス・プロバイダーのSSO URL | 上記サービス・プロバイダー・エンドポイントと同じ値を設定。 |
| 属性マッピング | SAMLアサーションに含める属性を指定。「すべての既知のユーザー属性を送信」をONにすると、取得可能な属性がすべて含まれる。 |
詳細は公式ドキュメントを参照してください。
Libertyの定義
server.xml
server.xmlはLibertyのプラットフォーム設定を定義します。
<featureManager>
<feature>pages-3.1</feature>
<feature>samlWeb-2.0</feature>
</featureManager>
- pages-3.1：JSPページを動かすための機能
- samlWeb-2.0：SAML認証を有効化する機能
SAML設定は以下の通りです。
<samlWebSso20
id="defaultSP"
idpMetadata="${server.config.dir}/federation_metadata.xml"
groupIdentifier="groupIds"
/>
- idpMetadata：IdPから取得したメタデータファイルのパス
- groupIdentifier：SAMLアサーション内でグループ情報を示す属性名（例：groupIds）
上で記載したSAMLアサーションの例では、groupIdsに3つのグループが含まれています。
後述するセキュリティロールと、グループとの関連付けを指定します。
<application-bnd>
<security-role name="ALL_USER">
<group access-id="group1" />
<group access-id="group2" />
</security-role>
<security-role name="PRIVILEGED_USER">
<group access-id="group2" />
</security-role>
</application-bnd>
ALL_USERというロールには、group1またはgroup2というグループ、PRIVILEGED_USERというロールには、group2というグループが該当すると認識されます。
ここでのグループは、groupIdentifierの定義に基づきSAMLアサーションのgroupIdsを参照します。
web.xml
web.xmlはアプリケーション設定を定義します。
<security-role>
<role-name>ALL_USER</role-name>
</security-role>
<security-role>
<role-name>PRIVILEGED_USER</role-name>
</security-role>
アプリケーション機能に認可を与えるセキュリティロールを定義します。
ここでは、「ALL_USER」「PRIVILEGED_USER」という2種類のロールを定義しています。
ログインユーザーがどのロールに該当するかは、server.xmlのapplication-bndに定義された関連付けによって決定されます。
<security-constraint>
<web-resource-collection>
<web-resource-name>normal_page</web-resource-name>
<url-pattern>/hello.jsp</url-pattern>
<url-pattern>/hello1.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>ALL_USER</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>priviledged_page</web-resource-name>
<url-pattern>/hello2.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>PRIVILEGED_USER</role-name>
</auth-constraint>
</security-constraint>
リクエストのURLを基準に、そのリクエストはどのロールに許可されているかを定義しています。
今回の構成では、認証・認可をXML定義のみで実現しており、アプリケーションコードには全く触れていない点が特徴的です。
ただ認可の定義をコードに近い部分で定義したほうが実装しやすいと判断する場合には、@ServletSecurityアノテーションを使用してコード上に直接指定する方法もあります。
その他、アプリケーションの全範囲を一律の認証対象として指定し、認可部分はアプリケーション内で実装するという設計も考えられます。
どのような実装を選択するかは、各種要件を鑑みて検討する必要があるでしょう。
おわりに
SAML認証の仕組みと実現方法について、サンプルを使いながら確認しました。実際に動かして体験することが理解への早道と考えます。
今回紹介したのはSAMLの一部機能に過ぎません。要件に応じて、接続方式や属性の扱いを検討してください。
本記事がSAML認証導入の第一歩となれば幸いです。
参考
WebSphere Liberty SAML Web SSO 構成ガイド