概要
「Azureで社内システム再現（オンプレ編）」では、
AzureのIaaSサービスを使って簡単な社内システムを再現します。
機能としては、社員番号を入力して検索ボタンを押すと、
対応する名前を表示するだけのシンプルなものです。
※詳しい全体構成については、【第0回】Azureで社内システム再現（オンプレ編）｜構成図と動作の流れで紹介しています。
システム構成（今回の対象範囲）
この記事では、赤枠で囲っている WEB-VM1の構成が対象です。
今回は、WEB-VM1 に Shibboleth Service Provider（SP）を導入し、ADFS（IdP）と連携するための準備を行います。
- WEB-VM1 に Shibboleth SP をインストールします
- IIS 環境に Shibboleth のモジュールが正しく認識されているかを確認します
- 初期設定として
shibboleth2.xmlを編集し、基本的な構成を反映させます
Shibboleth SPとは？ADFSとの関係
今回の構成では、IdP（認証プロバイダ）として ADFS を使用し、
SP（サービスプロバイダ）として Shibboleth SP を導入しています。
Shibboleth SP は、Web アプリと IdP（ADFS）の間に挟まる中継役のような存在です。
Web アプリ自体に SAML 認証機能が備わっていなくても、Shibboleth SP を導入することで
SAML ベースのシングルサインオン（SSO）に対応させることができます。
認証ゲートとしての役割
Shibboleth SP は、「この Web アプリは SAML で認証します」というゲートのような役割を果たします。
Web アプリ自体は SAML を理解していなくても、
Shibboleth SP がユーザーのアクセスに対して IdP（ADFS）に認証を依頼し、
認証結果（アサーション）を受け取り、それを Web アプリに引き渡します。
この構成により、Web アプリはユーザーの認証状態を Shibboleth SP 経由で把握できるようになります。
Shibboleth SPを使う理由
- Web アプリに直接 SAML 認証を組み込むのは実装の難易度が高い
- Shibboleth SP を使えば、IIS 配下の任意の Web アプリを簡易的に SAML 対応 SP に変換できる
- オープンソースであり、構成ファイルベースで柔軟なカスタマイズが可能
Shibboleth SPのインストール
Shibboleth Service Provider（SP）のインストーラーは、公式サイトから入手可能です。
ダウンロード先（Windows 64bit版）:
https://shibboleth.net/downloads/service-provider/3.5.0/win64/
今回は、最新版である shibboleth-sp-3.5.0.2-win64.msi を使用しました。
インストーラーを実行すると、以下の画面が表示されます。
全て規定値のままでインストールを行いました。
「Configure IIS support」にチェックを入れて進めることで、Shibboleth SP の IIS 統合が自動的に設定されます。
IISモジュールの確認
インストールが完了すると、IIS のモジュールに ShibNative（および ShibNative32）という名前のモジュールが追加されます。
これらのモジュールは、Shibboleth SP がリクエストを処理するための中核的なコンポーネントです。
内部では iis7_shib.dll という DLL が動作しており、以下のような処理を担っています。
ShibNative モジュールの役割
具体的には、ShibNative モジュールは以下のような流れを担当します。
- ユーザーが Web アプリにアクセスすると、ShibNative が「このページは認証が必要だ」と判断します
- 認証されていない場合、ユーザーを ADFS（IdP）へリダイレクトしてログインさせます
- ADFS での認証に成功すると、「この人は本人ですよ」という証明（SAMLアサーション）がクライアント（ブラウザ）に返されます
- ブラウザはそのアサーションを持って、SP 側のエンドポイント（例：
/Shibboleth.sso/SAML2/POST）に再アクセスします - ShibNative はこのアサーションを受け取り、妥当性を検証したうえで、ユーザーが認証されたことを Web アプリに伝えます
この一連の流れによって、Web アプリ自体が SAML を理解していなくても、
ShibNative を通じて「認証済みユーザーだけがアクセスできる」仕組みが実現されます。
なお、ShibNative の内部では iis7_shib.dll が動作しており、
この DLL がリクエストの判定やリダイレクト、アサーションの受け取りと検証などを担っています。
Shibboleth SP の中核となるコンポーネントです。
shibboleth2.xml の編集
shibboleth2.xml は、Shibboleth Service Provider（SP）の動作を制御する主要な設定ファイルです。
Webアプリのどのパスを保護するか、どの IdP（ADFS）と連携するかなどを定義します。
C:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml を今回の構成に合わせて編集します。
今回は、OSSTech社の技術ブログを参考に、shibboleth2.xml を全体的に編集しました。
その中でも、特に重要となる以下の 3 つの設定について取り上げます。
1. SP の EntityID を設定
<ApplicationDefaults entityID="https://web-vm1.domain.local/shibboleth">
この entityID は、Shibboleth SP 自体を一意に識別するための ID です。
この値は、後編で ADFS 側に「この SP は誰なのか？」を伝える際に使用されます。
IdP（ADFS）から見ると、複数の SP が接続してくる可能性があるため、
どの SP からのリクエストかを識別するために entityID の設定が必須となります。
2. IdP の EntityID を設定
<SSO entityID="http://adfs.domain.local/adfs/services/trust">
こちらは、Shibboleth SP 側が認証を依頼する相手（IdP＝ADFS）の識別子です。
この entityID により、Shibboleth は「どの IdP に認証要求を送るか」を判断します。
3. IdP のメタデータファイルを指定
<MetadataProvider type="XML" path="C:/opt/shibboleth-sp/etc/shibboleth/adfs-metadata.xml"/>
この設定では、ADFS（IdP）のメタデータファイルをローカルパスで指定しています。
メタデータには、IdP 側のエンティティID、署名用の公開鍵、エンドポイントURL などが含まれており、
Shibboleth SP が通信や署名検証を行ううえで必要な情報が定義されています。