ユーザーリポジトリとしてのActive Directoryの第2弾です。
前回はActive Directoryのプロパティに色々な属性を入れると便利だよ、という話をしてきましたが、
今回はもう一つのパターンを見てみたいと思います。
テーマはずばり、AD FS(Active Directoryフェデレーションサービス)です。
AD FSは、2つのドメイン
(AD FSの連携先はもっと多彩なのですが、ここではわかりやすくドメインとしておきます)
を利用するときに、ドメインの信頼関係を結ぶことなく、
互いのドメインのリソースにアクセスできるようにするサービスで
たとえば、相手のドメインに認証を必要とするWebサーバーがある場合、
下図のような連携を通じてアクセスできるようになります。
(下図は、アカウントパートナーのドメインのユーザーが、リソースパートナーのドメインの
Webサーバーにアクセスしにいく、というシナリオです)
手順4.のところで認証を(アカウントパートナー側で)済ませ、認証が済んだよ！という情報を
(リソースパートナー側に)送ります。
このとき、送られる情報はユーザーログオン名とは限らず、違う情報を送ることができます。
たとえば、Webサーバーにアクセスしたときに、表示されるWebページをパーソナライズする場合だったら、
ユーザーログオン名を使って「ようこそ、kuniiさん」と表示されるよりも、
ユーザーの名字属性を使って「ようこそ、国井さん」と表示したほうが親切なわけです。
だから、Active Directoryオブジェクトの様々な属性がリソースパートナー側に
送ることができるようになっているのですね。
どのような属性をアカウントパートナーからリソースパートナーに送るかについては
AD FSであらかじめ定義しておきます。
こうやって見てみると、リソースパートナー側でどのようなサービスを提供しているかによって、
アカウントパートナー側から送ってほしい属性は異なってくるわけですが、
いずれにしても、ユーザーの属性が役立つことが見て取れると思います。
特に、AD FSとAD RMSを組み合わせるシナリオでは、電子メール属性(mail属性)を受け渡すことが必須なので、
少なくともユーザーのプロパティに電子メールアドレスは入れておかなければならないですね。
このように、ユーザーをはじめとするActive Directoryオブジェクトに様々な属性情報を入れておく使い方
(=ユーザーリポジトリとしての使い方)をすると、AD FSを使った連携をするときに、
幅が広がってくるわけです。
AD FSは、Active Directoryドメイン以外との連携も今後できるようになりますし、
アプリケーションも単なるWebアプリケーションだけでなく、AD RMS、SharePoint2010と
IT Proにもなじみの深いアプリケーションにも広がってきていますから、
私も注目している分野のひとつです。
だけど、トレーニングを提供している立場の人間から言わせると、
AD FSを皆さんに理解していただくのって、すごく難しいんですよね(涙)
