はじめに

本記事は「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 構成ガイド