どうも技術部のシニアエンジニア 佐藤です。
今回は表題の通りLDAPレスのShibboleth構成をご紹介させていただきます。
しかもなんと今回は私がやったわけではありません。
サイオスと長年に渡りお付き合い頂いておりますベンダー様がチャレンジした結果を佐藤がお届けいたします。
今回技術情報をご提供頂きましたのはあの大企業 ネットワンシステムズ株式会社 様となります。
その中でもネットワンシステムズ株式会社 東日本第1事業本部 パブリック第5技術部の門間様、奥山様からの情報提供となります。
この場を借りて情報提供ありがとうございました。
今回は次のような構成で試しております。
- 認証はEntra IDで実施
- Shibboleth IdPはフェデレーションIdPとして利用
- LDAPを使わないDBレス構成
- ユーザー属性はEntra IDに格納
アーキテクチャ
従来のShibboleth構成ではLDAPが存在します。
従来構成
今回の構成（DBレス）
LDAPの代わりにEntra IDがユーザーストアの役割を担う構成になります。
認証フロー
今回の構成では認証をEntra IDへ委譲します。
1 User → SPアクセス 2 SP → Shibboleth IdPへリダイレクト 3 IdP → Entra IDへ認証要求 4 User → Entra IDでログイン 5 Entra ID → IdPへ認証結果 6 IdP → SPへSAMLアサーション 7 SPログイン完了
フロー図で表すと次のようになります。
この構成では以下の役割分担になります。
- 認証処理 → Entra ID
- フェデレーションIdP → Shibboleth
今回利用するのは External Authentication フローです。 これにより認証処理を外部IdPへ委譲できます。
ユーザー属性の扱い
従来はLDAPからユーザー属性を取得しますが今回の構成では属性はEntra IDに保存します。
認証後のレスポンスから属性を取得しSPへ渡します。
Entra ID | v OIDC / SAML Response | v Shibboleth Attribute | v Service Provider
Shibboleth設定例
authn.properties
idp.authn.flows=External idp.authn.External.externalAuthnPath=/authn/External idp.authn.External.supportedPrincipals=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
relying-party.xml
<bean parent="RelyingPartyByName" c:relyingPartyIds="https://sp.example.org">
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO"/>
</list>
</property>
</bean>
attribute-resolver.xml（サンプル）
<AttributeDefinition id="mail" xsi:type="Simple"/> <AttributeDefinition id="displayName" xsi:type="Simple"/> <AttributeDefinition id="givenName" xsi:type="Simple"/>
学認フェデレーションへの接続確認
学認テストフェデレーション
Shibboleth側の設定は今回割愛しましたが、当然こちらの構成で学認へも接続が可能です。
今回は検証のためテストフェデレーションまでしか確認していませんが属性情報の確認が出来ておりますので運用フェデレーションでも問題なく動作されるでしょう。
この構成のメリット
LDAPサーバが不要
従来 IdP + LDAP + DB 今回 IdP + Entra ID
ユーザー管理の一元化
LDAPを無くすことにより実質的にユーザーディレクトリの管理をADに集約することが出来るので学内にADはあるがLDAPは利用していない。
といったようなユースケースのお客様には実用的な構成だと感じました。
MFAやConditional Accessが利用可能
Entra IDのMFAやConditional Accessなどの機能を そのまま認証基盤に組み込むことができます。
まとめ
Shibboleth IdPはLDAPと組み合わせる構成が一般的ですが、 Entra IDと連携することでDBレス構成も実現できます。
- 認証 → Entra ID
- ユーザー属性 → Entra ID
- フェデレーションIdP → Shibboleth
クラウドディレクトリ中心の認証基盤を構築する場合、 シンプルで運用性の高いアーキテクチャになります。
サイオスでは今回の構成をこれまで考えたことはありますが検証してブログにアップするまではしていなかったので
これをベンダー様であるネットワンシステムズ様が検証して情報提供くださったことに改めて御礼申し上げます。
これからも認証基盤を含めたお仕事で協力しあえる関係性を続けさせてください。
他の企業・団体様からでも弊社ブログに掲載したい情報等ございましたらご一報頂けると幸いです。
