【第4回】Azureで社内webシステムを再現｜Shibbolethを構成する


## はじめに

本記事は、「Azure で社内システムを再現する」シリーズの第4回です。  
Azure の IaaS を用いて、オンプレミス環境を模した構成を段階的に構築していきます。

構成図と処理フローの詳細は、以下の記事をご参照ください👇  
▶ [【第0回】Azureで社内webシステムを再現｜構成図と動作の流れ](https://qiita.com/saba_infra/items/a5e58ded68973e4551ee)

---

## システム構成（今回の対象範囲）
![ADFS_dousatyuhen.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/47028b04-205e-4c90-b5f5-32fff6d970f8.png)

この記事では、赤枠で囲っている 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` を使用しました。

---

インストーラーを実行すると、以下の画面が表示されます。

![スクリーンショット 2025-03-21 16.03.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/c9cc7484-ef20-413e-bffe-d47c1458e6b2.png)

全て規定値のままでインストールを行いました。  
「**Configure IIS support**」にチェックを入れて進めることで、Shibboleth SP の IIS 統合が自動的に設定されます。

---

## IISモジュールの確認

インストールが完了すると、IIS のモジュールに `ShibNative`（および `ShibNative32`）という名前のモジュールが追加されます。

![スクリーンショット 2025-04-08 15.20.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/c6972233-b85f-4923-a804-695584a1e4cd.png)


---

### ShibNative モジュールの役割

具体的には、ShibNative モジュールは以下のような流れを担当します。

1. ユーザーが Web アプリにアクセスすると、ShibNative が「このページは認証が必要だ」と判断します  
2. 認証されていない場合、ユーザーを ADFSへリダイレクトしてログインさせます  
3. ADFS での認証に成功すると、「この人は本人ですよ」という証明（SAMLアサーション）がクライアント（ブラウザ）に返されます  
4. ブラウザはそのアサーションを持って、SP 側のエンドポイント（例：`/Shibboleth.sso/SAML2/POST`）に再アクセスします  
5. 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` 

![スクリーンショット 2025-04-08 15.50.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/3a419bef-e788-4402-8e17-20f66db1a967.png)

今回は、[OSSTech社の技術ブログ](https://blog.osstech.co.jp/posts/2021/05/shibbolethsp-iis/)を参考に、`shibboleth2.xml` を編集しました。  
その中でも、特に重要となる以下の 3 つの設定について取り上げます。

### 1. SP の EntityID を設定

```xml
<ApplicationDefaults entityID="https://web-vm1.domain.local/shibboleth">
```
この entityID は、Shibboleth SP 自体を一意に識別するための ID です。
この値は、 ADFS 側に「この SP は誰なのか？」を伝える際に使用されます。

IdP（ADFS）から見ると、複数の SP が接続してくる可能性があるため、
どの SP からのリクエストかを識別するために entityID の設定が必須となります。

---
### 2. IdP の EntityID を設定

```xml
<SSO entityID="http://adfs.domain.local/adfs/services/trust">
```
こちらは、Shibboleth SP 側が認証を依頼する相手（IdP＝ADFS）の識別子です。
この entityID により、Shibboleth は「どの IdP に認証要求を送るか」を判断します。

---

### 3. IdP のメタデータファイルを指定

```xml
<MetadataProvider type="XML" path="C:/opt/shibboleth-sp/etc/shibboleth/adfs-metadata.xml"/>
```
この設定では、ADFS（IdP）のメタデータファイルをローカルパスで指定しています。
メタデータには、IdP 側のエンティティID、署名用の公開鍵、エンドポイントURL などが含まれており、
Shibboleth SP が通信や署名検証を行ううえで必要な情報が定義されています。


---