2011年2月20日日曜日

ADFSのLDAP属性

ADFSというか、Active DirectoryのLDAP属性は、ここに一覧があります。
http://msdn.microsoft.com/en-us/library/ms675090(v=VS.85).aspx

ADSIエディターなどで表示される属性は、LDAP表示名(Ldap-Display-Name)と呼ばれるもののようですね。
E-Mail-Addressだとこういう感じの内容で書かれています。

IdPとSPを連携させてクレーム対応アプリケーションを試してみた

IdP側のSTSで認証して属性ストアからメールアドレスをセキュリティトークンとしてもらい、SP側のSTSでそのメールアドレスに対応する役職をセキュリティトークンに追加する動作を試してみました。

アプリケーションにアクセスしてからの一連の動作は、以下の図のようになります。
ADFS2-Idp-SP-01-flow.jpg

そして、それぞれどのような信頼関係や属性ストアがあるかは、以下の図の通りです。
ADFS2-Idp-SP-02-trust.jpg
注)IdP側STSからActive Directoryに対する"要求プロバイダー信頼"、"属性ストア"は、AD FS 2.0の構成時に合わせて作られています。

今回は、以下のものを設定しています。
(1)IdP側STSから、SP側STSに対する"証明書利用者信頼"
(2)SP側STSから、役割(役職)ストアに対する"属性ストア"
 これは、SQL Server 2008 R2 Express上に作ったデータベースです。
 DBMSに対する属性ストアの接続については、日本マイクロソフトの安納さんのブログ記事を参考にしています。
 【IDM】AD FS 2.0 で属性ストアとしてSQL Server を使用する
 ただ、SQL Server 2008 R2 Expressの場合は、
  server=ホスト名\sqlexpress
 としてやる必要がありますね。
 参考: SQL Server Express ユーザー インスタンスへの接続 (ADO.NET)
(3)SP側STSで認証しないように、Web.configを以下のように変更します。
 localAuthenticationTypesタグの要素をコメントアウトすると、このADFSで認証しない様になります。
<localAuthenticationTypes>
<!-- add name="Integrated" page="auth/integrated/" />
<add name="Forms" page="FormsSignIn.aspx" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" / -->
</localAuthenticationTypes>

(4)SP側STSから、IdP側STSに対する"要求プロバイダー信頼"
(5)SP側STSから、クレーム対応アプリケーションに対する"証明書利用者信頼"

では、(1)、(4)、(5)の要求規則セットと要求規則についても書いておきます。
(1)は、"発行承認規則"に以下の要求規則を定義しました。
sponly01.jpg
メールアドレス属性を名前というクレームに入れて発行してます。

(4)は、"受け付け変換規則"に以下の要求規則を定義しました。
sponly02.jpg
名前というクレームをパススルーしてます。

(5)は、"発行承認規則"に二つの規則を定義しました。
 一つ目は、名前というクレームを発行してます。
sponly03.jpg
名前というクレームをパススルーしてます。

二つ目は、カスタム規則で、名前(メールアドレス)に応じた役職(役割)をSP側STSに設定した属性ストアから取り出して発行します。
sponly04.jpg
ここは、SQL文をカスタム規則に書いて、クレームとして発行しています。

ということで、参考になれば幸いです。

参考)
【セミナー資料】AD FS 2.0 を使用して Windows Azure との SSO を実現しよう V1.1
【IDM】AD FS 2.0 カスタムルール(カスタム規則)の作り方 1/2
【IDM】AD FS 2.0 カスタムルール(カスタム規則)の作り方 2/2
BoF-09 Silverlight and WIF /TechEd Japan 2010
IdM実験室


2011年2月6日日曜日

ログオンしているユーザー情報から、そのユーザーが格納されているOUまで移動するPowerShellコード

ログオンしているユーザー情報から、そのユーザーが格納されているOUまで移動するPowerShellコードを書いてみたので、晒しておきます。
制御の委任が行われていれば、cd $DNPATH 以降で、新規にユーザーを作成するなどの処理が実行できます。
実行にあたっては、PowerShellのActive Directoryモジュールが必要です。
・Windows Server 2008 R2は、"機能の追加"で追加しましょう。
・Windows 7は、RSATのダウンロードとインストールが必要です。
ただこのコード、あまり深く考えていないところがあるので、複数のグループで制御の委任を受けているユーザーはどうするのかとか、administratorだとこれまずいのじゃという点、多々留意点があります。