ShibbolethとGriffinそして単一デーモンで複数のIdentity ProviderとFederation

こんにちは、富士榮です。

ここしばらくポスト数が減っていたので、今年は小ネタを中心に色々と書いていこうかと思います。

ということでみなさん大好きなShibbolethです。スペルがずっと覚えられずShobbolethと某所に書いて伝説のワード「しょぼれす」を産んでしまったのは遠い過去の記憶です。

Shibbolethってなんだ？というかなぜShibboleth

そういえばShibbolethコンソーシアムのWebサイトを見てもあんまりその辺は触れられていないんですよね。

A world leader in identity management technology, Shibboleth is an open-source project with a strong community of users. With a dedicated team of developers and vital support from Consortium members, Shibboleth has grown over the years to offer a variety of products alongside its world-renowned Identity Provider.（原文：What is Shibboleth?）

アイデンティティ管理技術の世界的リーダーであるShibbolethは、ユーザーの強力なコミュニティを持つオープンソースプロジェクトです。献身的な開発者チームとコンソーシアムメンバーからの重要なサポートにより、Shibbolethは世界的に有名なIdentity Providerに加え、様々な製品を提供するまでに成長しました。（Deepl翻訳） 

なお、Shibbolethという言葉自体は麦の穂を示す言葉で、アッカド語、ウガリト語、アラム語、古代シリア語、旧南アラブ語、アラビア語あたりが語源みたいです。

Cognate with Akkadian 𒋗𒁍𒌌𒌈 (šubultum, “ear of wheat”), Ugaritic 𐎌𐎁𐎍𐎚 (šblt, “ear of grain”), Aramaic שׁוּבַּלְתָּא/שִׁבַּלְתָּא‎ (šubbaltā/šibbaltā), Classical Syriac ܫܒܠܬܐ‎ (šeb(b)eltāʼ, “ear of grain; flow of a river”), Old South Arabian 𐩪𐩨𐩡𐩩‎ (s¹blt, “ear of grain”), and Arabic سُنْبُلَة‎ (sunbula), سَبَلَة‎ (sabala).

- Wikidisctionary「שיבולת」より

同じくWikipediaによるとこのShibbolethのsh（ʃ）の発音ができる・できないで民族の違いを見極めていたことから「ある社会集団の構成員と非構成員を見分けるための文化的指標を表す用語」になってきたとのことです。

そしてギレアデびとはエフライムに渡るヨルダンの渡し場を押えたので、エフライムの落人が「渡らせてください」と言うとき、ギレアデの人々は「あなたはエフライムびとですか」と問い、その人がもし「そうではありません」と言うならば、 またその人に「では『シボレテ』と言ってごらんなさい」と言い、その人がそれを正しく発音することができないで「セボレテ」と言うときは、その人を捕えて、ヨルダンの渡し場で殺した。その時エフライムびとの倒れたものは四万二千人であった。

多分「しょぼれす」って言ったら瞬殺されてますね・・・

この辺りからセキュリティドメイン（フェデレーション）の境界線を区分するためのゲートキーパーとしての認証システムにShibbolethという名称が用いられているのかな、という推測もあながち間違ってないのかもしれません。また、Shibbolethのロゴマークがグリフィンなのも「黄金を守る」という役目を持つ神話上の生物だから、というところに起源があるのかもしれません。（いずれも真偽は不明）

Shibbolethのロゴ

単一デーモンで複数のIdentity ProviderとFederation

さてさて、そんなShibbolethですがSAMLが喋れるIdentity Provider（IdP）としての役割を持つサーバーとApacheやnginxなどのWebサーバに組み込んでService Provider（SP）として構成するためのモジュールから構成されます。

ということで小ネタですが、単一のデーモン/shibdで動作しているSPがVirtual Directoryの単位で別のIdPとFederationさせたいケースが時たまありますので、どう設定するのが良いのかをちょっとだけ。（なお、セッション管理などSPとなるアプリ側でどう扱うかはアプリ側の設計次第なのでスコープアウトします）

やり方としては単純でRequestMapperに追加のApplicationIdを定義してMetadataProviderの設定をオーバライドしてあげるだけです。

こちらがshibboleth2.xmlの設定。additionalAppというapplicationIdを設定し、SP側のEntityID、HandlerURL、IdPのEntityIDとMetadataを別のものを設定してあげます。

<RequestMapper type="Native">

  <RequestMap applicationId="default">

    <Host name="sp.example.org" authType="shibboleth" requireSession="true" applicationId="additionalApp"/>

  </RequestMap>

</RequestMapper>

<ApplicationOverride id="additionalApp" entityID="https://sp.example.org/additionalApp/shibboleth-sp">

  <Sessions lifetime="28800" timeout="7200" checkAddress="false" handlerURL="/additionalApp/Shibboleth.sso">

    <SSO entityID="https://otheridp.example.jp/idp" >

      SAML2

    </SSO>

  </Sessions>

  <MetadataProvider type="XML" validate="true" path="otheridp-metadata.xml"/>

</ApplicationOverride>

その上で、httpd.confのLocationにVirtual Directoryを設定し、ShibRequestSettingで追加したApplicationIdを参照するように指定してあげます。

<Location /additionalLocation>

  AuthType shibboleth

  ShibRequestSetting requireSession 1

  require shib-session

  ShibRequestSetting applicationId additionalApp

</Location>

これでshibdとhttpdを再起動すれば完了です。

従来のパスへのアクセス時はshibboleth2.xmlに元々指定してあったデフォルトのIdPへ、追加したパスへのアクセス時には追加で指定したIdPへリダイレクトされるようになります。

なお、REMOTE_USERはそれぞれのパス単位で別のもの（リダイレクト先のIdPのもの）となりますので、この辺りのハンドリングをアプリ側でコントロールしてあげる必要はあります。

ということで今年もよろしくお願いします。