はじめに
本記事は、「Azure で社内システムを再現する」シリーズの第4回です。
Azure の IaaS を用いて、オンプレミス環境を模した構成を段階的に構築していきます。
構成図と処理フローの詳細は、以下の記事をご参照ください👇
▶ 【第0回】Azureで社内webシステムを再現｜構成図と動作の流れ
システム構成（今回の対象範囲）
この記事では、赤枠で囲っている WEB-VM1の構成が対象です。
今回は、WEB-VM1 に Shibboleth Service Provider（SP）を導入し、ADFS（IdP）と連携するための準備を行います。
- WEB-VM1 に Shibboleth SP をインストールします
- IIS 環境に Shibboleth のモジュールが正しく認識されているかを確認します
- 初期設定として
shibboleth2.xmlを編集し、基本的な構成を反映させます
Shibboleth SPとは？
今回の構成では、IdP（認証プロバイダ）として ADFS を使用し、
SP（サービスプロバイダ）として Shibboleth SP を導入しています。
Shibboleth SP は、Web アプリと IdPの間に挟まる中継役のような存在です。
Web アプリ自体に SAML 認証機能が備わっていなくても、Shibboleth SP を導入することで
SAML ベースのSSOに対応させることができます。
Shibboleth SPを使う理由
- Web アプリに直接 SAML 認証を組み込むのは実装の難易度が高い
- Shibboleth SP を使えば、IIS 配下の任意の Web アプリを簡易的に SAML 対応 SP に変換できる
Shibboleth SPのインストール
Shibboleth Service Providerのインストーラーは、公式サイトから入手可能です。
ダウンロード先（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）という名前のモジュールが追加されます。
ShibNative モジュールの役割
具体的には、ShibNative モジュールは以下のような流れを担当します。
- ユーザーが Web アプリにアクセスすると、ShibNative が「このページは認証が必要だ」と判断します
- 認証されていない場合、ユーザーを ADFSへリダイレクトしてログインさせます
- 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 が通信や署名検証を行ううえで必要な情報が定義されています。