はじめに
本記事は、「Azure で社内システムを再現する」シリーズの第5回です。
Azure の IaaS を用いて、オンプレミス環境を模した構成を段階的に構築していきます。
構成図と処理フローの詳細は、以下の記事をご参照ください👇
▶ 【第0回】Azureで社内webシステムを再現｜構成図と動作の流れ
システム構成（今回の対象範囲）
今回は、ADFS と Shibboleth SP 間の信頼関係構築を進めていきます。
赤枠で囲った構成部分が、今回の対象範囲です。
- ADFS のメタデータを取得し、Shibboleth SP 側に配置
- Shibboleth SP のメタデータを ADFS に登録（証明書利用者信頼）
ADFS のメタデータを取得して、Shibboleth SP に配置
Shibboleth SP が ADFS と連携するには、IdP 側（ADFS）のメタデータが必要です。
このメタデータには、ADFS の EntityID、署名証明書、SAML エンドポイントなどが含まれており、
Shibboleth SP が ADFS を信頼するための情報として機能します。
ADFS メタデータのダウンロード
以下の URL にブラウザでアクセスすると、ADFS のメタデータ（XML ファイル）がダウンロードされます。
https://adfs.domain.local/FederationMetadata/2007-06/FederationMetadata.xml
Shibboleth SP 側への配置
ダウンロードした XML ファイルを、shibboleth2.xml で指定したパスに保存します。
今回の設定では、以下のように記述していました：
<MetadataProvider type="XML" path="C:/opt/shibboleth-sp/etc/shibboleth/adfs-metadata.xml"/>
このため、ダウンロードした FederationMetadata.xml を
C:/opt/shibboleth-sp/etc/shibboleth/adfs-metadata.xml にリネームして保存します。
証明書利用者信頼の追加
ADFS に Shibboleth SP を「信頼できるサービス」として登録するために、
**証明書利用者信頼（Relying Party Trust）**の追加を行います。
ADFS 管理コンソールを開く
証明書利用者信頼 を右クリックし、
「証明書利用者信頼の追加」を選択します。
この設定により、ADFS が Shibboleth SP からの SAML リクエストを「受け入れる対象」として扱えるようになります。
フェデレーションメタデータの指定
Shibboleth SP のメタデータURLを指定します。
https://web-vm1.domain.local/Shibboleth.sso/Metadata
これにより、SP 側が署名に使用している証明書や、SAML エンドポイントの情報を ADFS が自動で取得できます。
Shibboleth SP 側では、特に証明書を設定していなくても
インストール時点で自己署名証明書が自動生成されています。
この証明書情報が SP メタデータ内に含まれており、
ADFS 側でそれを受け入れることで通信が成立します。
証明書は以下に格納されています
C:\opt\shibboleth-sp\etc\shibboleth\sp-cert.pem （公開鍵）
C:\opt\shibboleth-sp\etc\shibboleth\sp-key.pem （秘密鍵）
表示名の設定
ログイン画面などで表示される識別名を設定します。
今回は Employee-App-SP としました。
アクセス制御ポリシーの選択
この設定では、どのユーザーがこの SP にアクセス可能かを制御します。
今回は「すべてのユーザーを許可する」を選択しました。
本番環境では、ユーザーグループや MFA 要件などを組み合わせて制限をかけることが一般的です。
証明書利用者信頼の登録完了
ウィザードを完了すると、以下のように ADFS 管理画面に追加した SP（Shibboleth）が表示されます。
