問題タブ [federated-identity]

クレームベースのセキュリティ（またはフェデレーションセキュリティモデル）のトピックについて調査した後。CardSpaceを例として使用する多くの例に出くわしました。私が読んだ主な記事は、この主題について非常に優れた説明を提供しており、 Zermattと呼ばれるフレームワークに関するMicrosoftのPDFでした。

私が調査しているクレームベースのセキュリティアーキテクチャは、STS認証ブローカーをSTS承認ブローカーと組み合わせて実装するのと同じです。このように、新しいサービスを作成するときに必要なのは、サービスが承認ブローカーによって発行されたクレームのみを受け入れるようにすることだけです。また、記事に記載されているように、Authorization Brokerは、AuthenticationBrokerによって発行されたクレームのみを受け入れます。

それが設定されると、クライアントが新しいサービスを使用しようとするときはいつでも、認証ブローカー で認証し（認証されたクレームを発行）、次に 承認ブローカー で承認される（承認されたクレームを発行する）必要があります。

これはすべて問題なく、ダンディであり、アーキテクチャは明確ですが、STSを実装する方法が正確にはわかりません。前述したように、Web上のほとんどの（すべてではないにしても）例はCardSpaceの使用方法を示していますが、認証スキームをバックアップするデータベースがある場合、それは正確には機能しません。

サンプルシナリオ

代替テキストhttp://img512.imageshack.us/img512/8329/claimsbasedsecurityza6.jpg

企業がパートナーの Active Directory にユーザーを作成することを頻繁に要求する場合、またはその逆の場合、AD インスタンス間にフェデレーション/信頼関係を設定することは理にかなっていますか? もしそうなら、何を考慮すべきですか？パートナー AD のユーザーの ACL は引き続き同じように機能しますか? これにより、どのようなセキュリティ リスクが明らかになりますか?

ありがとう！

カ

アップデート：

アプリケーション自体にユーザー ストアをチェックさせることで、これを行うためのより良い方法があることを知りました。これを行う最善の方法は、両方のユーザー ストアが信頼するドメインにアプリケーションを移動することです。以下の回答で詳細を説明しました。

ジュネーブ関連の質問はまだあまり見たことがありません。ジュネーブ フォーラムにもこの質問を投稿しました...

私は、幅広いインストールベースを持つ win フォーム アプリがあるシナリオに取り組んでいます。このアプリは、その運用全体を通じて、私たちがホストするさまざまなサービスに頻繁に呼び出しを発行します。

サービスはすべてジュネーブ フレームワークを使用しており、すべてのクライアントは、サービスへのアクセスを許可するトークンを発行するために、まず STS に電話する必要があります。

ws2007FederationHttpBinding を使用してすぐに使用できるように、各サービス呼び出しの前に STS からトークンを取得するようにアプリを構成できますが、サービスを呼び出す作業がほとんど重複しているため、明らかにこれは最も効率的な方法ではありません。

または、アプリから「手動で」トークンを取得するために必要なコードを実装し、サービスで操作を呼び出すときに、事前に取得した同じトークンを渡します (WSTrustClient サンプルとフォーラムのヘルプに基づく)。それはうまく機能するので、解決策はありますが、コードで WCF チャネルを構築する必要があり、素晴らしい WCF 構成から離れているため、あまり洗練されていないと思います。

私は ws2007FederationHttpBinding アプローチを好みます。クライアントは、Geneva について何も知らずに、他の WCF サービスと同じようにサービスを呼び出すだけで、バインディングがトークン交換を処理します。

その後、誰か (Jon Simpson) が [私が思うに] 素晴らしいアイデアをくれました - アプリ自体でホストされ、ローカルで取得したトークンをキャッシュするサービスを追加します。ローカル キャッシュ サービスは、STS と同じコントラクトを実装します。リクエストを受信すると、キャッシュされたトークンが存在するかどうかを確認し、存在する場合はそれを返し、存在しない場合は「実際の」STS を呼び出し、新しいトークンを取得し、キャッシュして返します。クライアント アプリは引き続き ws2007FederationHttpBinding を使用できますが、発行者として STS を使用する代わりに、ローカル キャッシュを使用します。

このようにして、サービス固有のカスタム コードを使用せずにトークンをキャッシュするという、両方の長所を実現できると思います。キャッシュはすべての RP のトークンを処理できる必要があります。

私はそれが機能するかどうかを確認するために非常に単純なプロトタイプを作成しました.

私のローカル サービス (現在はコンソール アプリ) が要求を取得し、最初に STS を呼び出してトークンを取得し、それをキャッシュして、正常にクライアントに返します。その後、クライアントはそれを使用して RP を呼び出します。すべてうまくいきます。

ただし、2 回目は、ローカルのキャッシュ サービスが同じトークンを再度使用しようとしますが、クライアント側は MessageSecurityException で失敗します -

「セキュリティ プロセッサは、メッセージ内のセキュリティ ヘッダーを見つけることができませんでした。これは、メッセージがセキュリティで保護されていない障害であるか、通信する当事者間にバインディングの不一致があるためである可能性があります。これは、サービスがセキュリティ用に構成されていて、クライアントがセキュリティを使用していません。」

同じトークンが複数回使用されるのを妨げているものはありますか? WSTrustClient サンプルに従ってトークンを再利用したとき、うまく機能したので、私はそれを疑っています。私は何が欠けていますか？私の考えは可能ですか？いいもの？

これは、ローカルキャッシュの（この段階では非常に基本的な）メインコードビットです-

クレーム値の認証と取得にパッシブSTSを使用するasp.netアプリケーション（証明書利用者）があります。証明書利用者は、FederatedAuthenticationModule（FAM）を使用して、stsへのパッシブリダイレクトを有効にしています。InformationCardsを使用するときに必要なクレームを指定する方法に関するドキュメントを見つけましたが、FAMを使用してこれを構成する方法に関する詳細な情報をまだ見つけていません。

誰かがこれの例を持っていますか？私が見つけた最も近い例は、Geneva Frameworkのサンプルですが、アクティブなSTSとWCFを扱っていますが、これは適用されません。

前もって感謝します。

私の会社はフェデレーション ID ソリューションを必要としており、マイクロソフト ショップとして、この目標を達成するために MS テクノロジを使用することを検討しています。

Server 2008 または .NET 3.5 は運用環境にないため、.NET 2.0/Server 2003 ベースのソリューションに限定されます。

これは、(フェデレーション ID ソリューションに関して) Active Directory フェデレーション サービスを意味します。

ADFS は WS-Federation 標準をサポートしているため、非常に優れているように見えます。つまり、Microsoft テクノロジを使用していないパートナーとフェデレーションできます。

残念なことに (私たちにとって)、Microsoft は .NET 3.5 ベースの ID フレームワークであるGeneva Frameworkのリリースを間近に控えています。

Geneva フレームワークは、あらゆる点で ADFS よりも優れているように見えます (ほとんどの場合、ADFS に追加の機能と標準サポートが追加されているためです)。

私たちは .NET 3.5 ショップではなく、Geneva はベータ版のみであるため、現時点では実行可能なオプションではありません。

私の質問は次のとおりです。ADFS からジュネーブに移行するのはどれほど難しいでしょうか?

ADFS の概念実証段階にあるので、ID ベースの承認から ADFS クレーム ベースに移行するために必要なコードの変更についてはまだ掘り下げていません。このロジックは、Geneva クレーム ベース認証をサポートするように更新できるアセンブリに組み込むことができると確信しています。

必要なコードの変更に加えて、クレーム ベースのインフラストラクチャを ADFS から Geneva に移行するのはどれほど難しいでしょうか? (例: ADFS の STS (Federation Service) から Geneva の STS (Geneva Server) への移行)

このトピックに関するご意見をお寄せいただきありがとうございます。

Active Directory フェデレーション サービス (ADFS) と承認マネージャー (AzMan) の統合をカバーする優れたスクリーンキャストまたはドキュメントを知っている人はいますか?

私たちのクライアントは、アプリケーションを開発するために私たちにアプローチしてきました.いつものように、範囲は日々拡大しています.

当初は、企業ネットワーク内に限定された専用アプリとして開始されました。ユーザー認証は、ユーザーの Windows ログインを取得し、SQLServer データベースを使用してアクセス権をホストすることによって確立されました。すべて非常に簡単です。

- アプリケーションを Web ベースにする - アプリケーションを企業ネットワークの外部でホストする-ユーザー 認証が同じように機能する (パスワードを使用せず、Windows ログインのみ)

さらに複雑なことに、彼らはアプリケーションのさまざまな機能を、HTTP リクエストを発行するだけの別のアプリケーションで使用できるようにしたいと考えています。
- ユーザーが企業ネットワークにログインする
- ユーザーが企業アプリケーションを起動する - ユーザーが
顧客の詳細を処理する
- ユーザーがボタンをクリックする
- 企業アプリケーションがホストされている Web アプリに HTTP 要求を送信する
- HTTP 要求に必要な認証と顧客の詳細が含まれる
- ユーザー認証が「自動的に完了する」 ' (人間の関与なし)
- 顧客データは安全に送信されます

私たちの最初のアプローチは彼らが望んでいたものだったので、彼らは私たちが彼らのためにこれを行うことに非常に熱心です. そのようなホストされた Web アプリは私たちの専門分野ではありませんが、それでも彼らは私たちにこれを行うことを望んでいます。だから私は今専門家にアプローチします。
- これにアプローチする方法について誰かアドバイスはありますか?
- 避けるべき落とし穴の可能性について誰か警告がありますか?

Microsoft Geneva Framework を使用したカスタム STS の実装に関する MSDN の記事 ( http://msdn.microsoft.com/en-us/magazine/2009.01.genevests.aspx ) を読んだ後、そこで取り上げられているシナリオの 1 つについて少し戸惑いました。 . このシナリオは、上記の参照記事の図 13 に示されています。

私の質問は、IP-STS から既に取得したクレームを渡すために、RP が RP-STS への呼び出しを開始する方法についてです。目的のメソッド DeleteOrder() は、RP-STS からの Action クレームの Claim Request にどのように変換されますか? RP-STS は、呼び出しを承認する値 Delete を持つ Action クレームで応答しますか? また、RP-STS とポリシー エンジンの間の相互作用では、クレームと矢印が逆になるはずであるという点で、この図は少し間違っていると思います。

構造はわかりますが、Geneva/WCF によって提供されているものと、RP 内のコードで何を実行する必要があるかが明確ではありません。これは、削除の PrincipalPermission 要求で DeleteOrder メソッドを保護できなかったため、少し奇妙に思えます。許可」ですが、最初に役割を要求し、その後、削除アクションのきめ細かい要求を取得する必要があります。

要点を見逃していた場合は (Web 上でこのケースを簡単にカバーすることができないため)、申し訳ありません。

前もって感謝します。

RPXサードパーティ フェデレーション ID システムを統合したばかりの ASP.NET MVC アプリケーションがあります。統合は問題なく機能していますが、ASP.NET レベルでそれをどうするかについて頭を悩ませています。

ID は外部で処理されるため、アプリにパスワードは必要ありません。ユーザーのパスワードを受け取ることはなく、ID だけを受け取ります。ただし、ASP.NET メンバーシップ プロバイダーでは、ユーザーの作成、ユーザーのサインインなどのためにパスワードを渡す必要があります。

new Guid()作成時に使用することを検討していましたが、メンバーシップ プロバイダー経由でユーザーをサインインさせる前に、データベースを呼び出してユーザーのパスワードを取得する必要があります。各ユーザーに同じパスワードを使用して事前に知ることができますが、これによりユーザーのデータが安全でなくなるのではないかと心配しています。

StackOverflow など、他のサイトがこの問題をどのように処理しているかを知りたいです。

[このようなアプリのメンバーシップ プロバイダーに関する私の他の質問も参照してください。]

RPXサードパーティ フェデレーション ID システムを統合したばかりの ASP.NET MVC アプリケーションがあります。統合は問題なく機能していますが、ASP.NET レベルでそれをどうするかについて頭を悩ませています。

私は ASP.NET にかなり慣れていません (MVC で学習しています)。メンバーシップとプロファイル データのプロバイダー モデルについて少し発見しましたが、信じられないほど複雑に思えます (しかし同様に強力です)。私が苦労している特定のことは、データベースへのユーザーの永続性です。これまでのところ、標準のSqlMembershipProvider実装を使用してきましたが、うまく機能しています。ただし、メール検証のためにデータベースに検証コードを保存してチェックしたり (ユーザーのメールアドレスが RPX の結果で未検証としてリストされている場合)、返されたデータを保持したりしたいと考えています。これには、電子メール アドレスなどの認証に不可欠なものもあれば、単なるプロファイル情報 (ユーザーの年齢、性別など) もあります。

ASP.NET データベースには、NHibernate を介してやり取りする他のアプリ固有のテーブルがたくさんあります。ASP.NET のメンバーシップ/プロファイルに関する私の理解では、永続性を処理するため、NHibernate を使用してこれを実行する必要はありません。

私の目標は、サインオン エクスペリエンスを StackOverflow のものと似たものにすることですが、いくつか追加のビット (電子メールの検証など) があります。これを行うには完全なカスタム プロバイダーを構築する必要がありますか? それとも、効果的な方法でデフォルトSqlMembershipProviderを自分の意志に合わせることはできますか?

[このようなアプリケーションのパスワードに関する私の他の質問も参照してください。]