問題タブ [wif]

管理者グループのすべてのユーザーに、WCF を介したアクセスを許可しようとしています。

いくつかの Microsoft Connect ブログから、Geneva Server が ID プロバイダーとして AD/LDAP と連携していると聞いたことがあります。SQL サーバーで独自のカスタム属性ストアを構成する必要がある場合、これらのユーザーが AD グループに属していない場合は可能です。ブログから私が見たのは、Genevea サーバーが AD と密接に結合されていることです。カスタムを使用する必要がある場合次に、ジュネーブ フレームワークの基本クラスをオーバーライドして、カスタム STS を作成する必要があります。私の質問は、Geneva Server Beta 2 を使用して SQL ストア (AD グループに属していないユーザー) からユーザーを認証することは可能ですか?

昨日、WIF - Windows Identity Foundation SDK RC がパブリック ドメインでリリースされたことが発表されました。Vista の Home Premium エディションを搭載した PC に MSDN から msu ファイルをインストールしようとしましたが、失敗しましたか? Microsoft は、Vista がサポートされていると述べていますが、サイト上で Vista のどのバージョンについても言及していません。同様の問題を抱えている人はいますか??

Windows Identity Foundationで遊んでいて、MVC.NETベースのセキュリティトークンサービスを作成し、それをシングルサインオンアプリケーションとして使用しようとしています。

私の唯一の問題は、federationmetadata.xmlファイルを生成する方法がわからないことです。

このファイルを手動で生成するツールはありますか？

私は素晴らしいので、7 ボックスで VS2k10 B2 を使用して最新の WIF デモ アプリを実行しようとしています... もちろん 64 ビット (私の首ひげは強いです) 実行するのに問題があります。

デモ全体の一部では、ローカル マシンにいくつかの証明書をインストールする必要があります。問題は、Web サイト証明書の一部をLocalMachine/Myという証明書ストアにインストールするように求められることです。さて、/Myはもうないようです。Personalと呼ばれる疑わしい類似のストアが表示されますが、そこに証明書をインストールし、 LocalMachine/Personalを参照するように構成を変更すると、アプリは機能しません。

TrustedPeopleに証明書をインストールした場合(Personal を使用しようとしたときにスローされた例外によって有効な場所として言及されています) 、それで十分ですか? これを行うと、実稼働マシンで悪いフォームと見なされますか?

Windows Identity Foundation テスト プロジェクトは、http: //claimsbasedwpf.codeplex.comにあります。

例外：

プロパティ名: 'certificateReference' エラー: 'ID1025: 条件に一致する一意の証明書が見つかりません。StoreName: 'My' StoreLocation: 'LocalMachine' X509FindType: 'FindBySubjectDistinguishedName' FindValue: 'CN=busta-rpsts.com''

私は、すべてのクレーム ベースの Windows アイデンティティ基盤の魔法に頭を悩ませようとしています。

私が ADFS を使用したくないと仮定すると、WIF を使用して独自の STS を作成して難しい作業を行うのが最善なのか、それともサード パーティに依存するのが最善なのか、はっきりしないことが 1 つあります。

そして、それがサードパーティのオプションである場合 - どのようなサードパーティの STS がありますか?

WIF（以前はgenevaと呼ばれていました）を使用して承認および認証されたWCFの消費に関して、クライアントアプリ（winforms / console /その他）のベストプラクティスは何ですか？

また、サービス レベルで、WCF 操作ごとに STS へのトリップが不要になるようにトークンをキャッシュすることは可能ですか? （これに関する詳細情報も高く評価されています）ありがとう

この質問は、私がクレーム アイデンティティ管理についてほとんど知らないことを示しているのかもしれませんが、ここで説明します。

ID にサード パーティの STS を使用し、承認にカスタム クレームを使用するアプリケーション内で WIF を使用する場合 ( CanCreateFooBar のようなアプリケーションに関連する固有のもの)

1) ユーザーを管理するにはどうすればよいですか? つまり、AD やその他のメンバーシップ プロバイダーからのユーザーは特定できますが、内部的に私のシステムでは、それらについて知る必要があり、ID とは関係のないより多くのユーザー情報が必要です (したがって、この情報を利用できるようにすることは本当に意味がありません)。
問題は、システム データ (ID から開始) をスマートな方法で管理および作成するにはどうすればよいかということです。
私が考えている正確なシナリオは、新しい従業員が会社に追加され、システム管理者が特定の役割を持つドメインのユーザーを作成することです。私のシステムはどのようにしてこの事実を認識することができますか? (私はおそらく、システムの管理者にアクションを求めるようにシステムに促したいと思います。

2) これらのユーザーとロールの要求値はどこに保存されていますか? また、それらを変更するにはどうすればよいですか? 理想的には、特定のユーザーとアクションの権限を変更できるようにしたいと考えています。これに関するガイドラインはありますか？

これらはおそらく非常に不十分な質問であることがわかりますが、問題を解決する方法について考えると、複雑な解決策や、多くの重複を必要とする解決策 (つまり、2 つの場所で使用されるものを作成する) を思い付くので、私は確信しています。この問題について正しい方法で考えていないだけです

ありがとう

IIS (.svc) でホストされている呼び出しごとの WCF サービスがあります。サービスのコンストラクターで、この記事に従ってThread.CurrentPrincipal = HttpContext.Current.Userを設定しました。この場合、HttpContext.Current.UserはMicrosoft.IdentityModel.Claims.ClaimsPrincipal型であり、カスタム パッシブ STS から送り返されたクレームを持っています。

ただし、サービス操作に入ってThread.CurrentPrincipalを調べるとすぐに、このオブジェクトはまだMicrosoft.IdentityModel.Claims.ClaimsIdentity型ですが、オブジェクト自体はHttpContext.Current.Userと同じではなくなります( IsAuthenticated = false 、 AuthenticationType = "" 、および Name が Thread.CurrentPrincipal.Identity で null である場合)、これらの値はすべてHttpContext.Current.Userで正しく入力されます。これは、何かが操作への呼び出しをインターセプトし、現在のプリンシパルを一般的な、空の、認証されていないクレーム プリンシパルに誤って変更していることを示しています。

コンストラクターと操作でスレッド ID を確認しましたが、両方の場所で同じであり、HttpContext.Current.Userから割り当てた後、即時ウィンドウでThread.CurrentPrincipalを評価すると、スレッド ID が正しく設定されていることがわかります。コンストラクターなので、コンストラクターとメソッドの間で何かが確実に実行されており、その何かが私のThread.CurrentPrincipalを変更しています。

誰がこれをしているのか、どうすればこの動作を防止/修正できるのか分かりますか?

オフィスの上司は、開発者が次のことを行った Microsoft "Geneva" (現在の Windows Identity Foundation) のプレリリース バージョンのデモンストレーションを見たと言います。

1. 彼は、カスタマイズされたログオン システムを使用してユーザーがログインできる、ある種の ASP.net Web アプリケーションをセットアップしました。バックグラウンドで、Web アプリケーションはユーザーを Active Directory のユーザーとしてログインさせます。

2. ユーザーがログインします。

3. ユーザーがログインすると、ASP.net Web アプリケーション スレッドは、ユーザーのセッション中にログイン ユーザーとして実行され、ネットワーク上のリソースにアクセスできます (アクセスが Active Directory で制御されているテーブルで SQL クエリを実行するなど)。

手順 2) と 3) は、IIS の Web サイト設定の [ディレクトリ セキュリティ] タブで [統合 Windows 認証] 設定を使用する場合とまったく同じです。ステップ 1) は、Kerberos 認証ではなくカスタム ログオン システムを使用しているため、異なります。

1)、2)、および 3) で説明したとおりに動作するように、アプリケーションの 1 つをセットアップしたいと考えています。ただし、私が見た Windows Identify Foundation に関するドキュメントはすべて、Cardspace と Federated Security に関するものです。現在、これらのテクノロジーのいずれかを使用することに関心はありません。

舞台裏でユーザーが Active Directory アカウントにログインできるようにしたいだけです。

ActiveDirectoryMembershipProviderはい、 withを試しましたForms Authenticationが、ネットワーク上のリソースに実際にアクセスするには、すべてのページで偽装が必要です。

更新 2010 年 1 月 7 日。わかりました、私はしばらくこれに取り組んできましたが、私がなんとか達成したことはすべて、私が達成したいことには達していません。おそらく、私が必要とする機能は、WIF のリリース バージョンには含まれていません。

ここが今いる場所です。MSDN で、ASP.net で使用される 3 つの異なる ID があることを示すドキュメントを見つけHttpContext.Current.UserましThread.CurrentPrincipalたWindowsIdentity.GetCurrent。 リンク

設計しようとしているプロセスを使用する場所の一例として、ログインしたユーザーとして SQL クエリを実行したいと考えています。私のデバッガーでは、HttpContext および Thread ユーザーをログイン ユーザーに簡単に設定できることがわかります。ただし、Windows 認証を使用して SQL サーバーに接続すると、常にユーザーとして接続され、WindowsIdentity.GetCurrent偽装で Windows 認証を使用していない限り、そのユーザーは常に ASP.net プロセスの ID になります。ユーザーは魔笛の曲を演奏してログインする必要があり、Windows 認証は魔笛の曲でのログインをサポートしていないため、アプリケーションで Windows 認証を使用することは絶対にできません。

明確にするためにWindowsIdentity、ログインしたユーザー (魔笛の歌でログインしたユーザー) を表す を取得することに問題はありません。WindowsIdentity問題は、それを使用してユーザーの SQL クエリを実行できないことです。