2

私たちのチェーンは次のようになります。

WIF を使用した ASP.NET アプリ -> ADFS -> および場合によっては Azure ACS -> Facebook、Google など。

ロールなどを使用して AD で構成されたユーザーがいます。これらのユーザーは、ADFS を介して AD にログオンし、通常どおりロールを取得できます。

必要に応じて、ACS プロバイダーの 1 つにログオンでき、ACS プロバイダーの一意の ID を AD に格納するユース ケースがあります。複数のプロバイダーを使用している場合、複数のマッピングがあります。

したがって、ACS 経由でログインするユーザーを AD の「実際の」ID にマップできます。

私たちが戦っているのは、ACS 経由でログインするユーザーにクレームの完全なセットを配信する方法です。通常、名前、メール アドレス、一意の ID だけを取得します。

一意の ID を使用して AD を検索できるクレーム ルールはありますか? このルールでは、AD で正しい一意の ID を使用するために、使用したプロバイダーを確立する必要があります。

アプリケーションから AD を照会することはできると思いますが、それは、そのようなすべてのアプリケーションにコードを追加する必要があるということですか?

カスタム STS でも変換できるのでしょうか?

アイデア、良いリンク、記事などはありますか?

4

2 に答える 2

0

これを実現するには、ACS のクレーム プロバイダー信頼のクレーム ルール言語を使用して ADFS でカスタム ルールを作成します (一部の言語ドキュメントについては、こちらとこちらを参照してください)。

ただし、AD のクエリに使用されるパラメーター タイプがクレーム ルール言語で指定されていないため、一意の ID で AD をすぐに検索できるかどうかはわかりません。ルール テンプレートは Windows アカウント名 (レイアウト: DOMAIN\USERNAME) を使用して検索するため、AD 自体の代わりに (カスタム) 属性ストアを使用し、一意の ID を Windows アカウント名にマップすることをお勧めします。

属性ストアが設定されていると仮定すると、Windows アカウント名クレームを設定するカスタム ルールを作成し、ADFS のテンプレート ルールを使用して AD にクエリを実行できるようになります。

カスタム ルールは次のようになります。

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
 => add(store = "YourAttributeStore", 
  types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"),
  query = "{0}", param = c.Value);

テンプレート ルールを実際に有効にするには、新しく生成されたクレームに発行者を設定する必要もあります。これは、「AD AUTHORITY」からのものかどうかを確認するためです。これが正当なアプローチかどうかはわかりませんが、便宜上これを行います。これには、次のような 2 番目のルールが必要です。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Issuer = "AD AUTHORITY", OriginalIssuer = "AD AUTHORITY",
  Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
  Value = c.Value);

異なる一意の ID プロバイダーの違いに関しては、それをどのように処理するかはあなたの選択です。すべてのプロバイダーに対してカスタム ルールを作成し、属性ストアに区別させるか、属性ストアに対して汎用クエリを作成することができます。ここでは、Claim Rule Language のドキュメントが役立ちます。

注: これは、ADFS/WIF/Claims ベースの ID に関する本では一般的に避けられているトピックのようです。これは私の個人的な解決策であり、ベスト プラクティスではないかもしれません。私が思いついた最も便利な方法です。誰かがこの特定のトピックの報道を知っている場合: 共有してください.

また、注意: ADFS ではルールの順序が重要であり、最初のルールで作成された要求は次のルールで使用できます。これがこれを可能にするものです。

編集：この質問が1年前に尋ねられたのを見ませんでした...とにかく、この回答が誰かの役に立てば幸いです。

于 2013-07-25T15:02:11.100 に答える
0

代わりにチェーンが次のようになっていると、シナリオの摩擦が少なくなる可能性があります。

WIF を使用した ASP.NET アプリ -> Azure ACS -> (ADFS または Google または Facebook)

これは実行可能なオプションですか？

ADFS が証明書利用者ではなく ID プロバイダーとして機能している場合、ACS は ADFS と最適に統合されます。さらに、ADFS は外部の ID プロバイダーと喜んでフェデレーションを行い、外部ディレクトリからのユーザーにアクセスを許可しますが、ACS から発行されたトークンを使用して、ADFS が独自のローカル AD ディレクトリからユーザーを認証することはできないと思います。

于 2012-07-24T17:39:08.787 に答える