問題タブ [claims-based-identity]

App Fabric Labs の認証メカニズムを MVC3 アプリに実装したので、Facebook、Google、Yahoo、LiveID でログインできるようになりました。はい!!

では、ユーザーがこれらのシステムのいずれも使用したくない場合はどうすればよいでしょうか? 「従来の」登録フォームを提供する必要があります。アプリを変更せずに残すことができるように、ID プロバイダーを実装する必要があると考えています。

すぐに使用できるテンプレート/プロジェクトはありますか?

thx-e

テスト環境には SharePoint 2010 があり、カスタム STS (フェデレーション、すべてのサイトはクレームベース) を使用しています。サイトにログインしようとすると、sts ログイン ページにリダイレクトされ、資格情報を入力すると、siteurl/_trust にリダイレクトされ、ここに長時間留まり、タイムアウトします。Windows アプリケーション エラーでは、次のように表示されます。この操作に割り当てられた時間は、より長いタイムアウトの一部であった可能性があります。

別のエラーは次のとおりです。

セキュリティ トークンを発行しようとしたときに例外が発生しました: 00:00:59.9843751 の後に応答を待っている間に要求チャネルがタイムアウトしました。Request への呼び出しに渡されるタイムアウト値を増やすか、Binding の SendTimeout 値を増やします。この操作に割り当てられた時間は、より長いタイムアウトの一部である可能性があります..

何か案は？

コントローラー内でクレームを取得したい場合は、次のようなことができると言われています。

ただし、これはビューとコントローラーの分離に違反します。コントローラーが存在しないコンテキストで呼び出される可能性がありますHttpContext-では、それを行う適切な方法は何ですか?

TIA - ekkis

STS にログオンしてクレームのコレクションを取得する Silverlight クライアント アプリケーションがあります。Identity Training Kit に付属の Silverlight IdentityModel を使用します。これはうまくいきます。

問題は、(データを取得するために) サービス呼び出しを行うときに、サービス内で IClaimsIdentity タイプの ID を確認できますが、そのクレーム コレクションは空です。サービスは ClaimsIdentitySessionManager InvokeAsync メソッドを使用して呼び出されるため、IssuedToken 情報が SOAP ヘッダーに追加されます。サービス コールは、セッション マネージャのコンテキスト内で実行されます。

さまざまな種類のコードと設定を試しましたが、サービスに対するクレームを取得できません。CustomBinding を使用して動作するはずだと読みましたが、使用するとエラーが発生します: Content Type text/xml; charset=utf-8 はサービスでサポートされていませんでした。クライアントとサービスのバインディングが一致していない可能性があります。

さまざまなメッセージ バージョンで「BinaryMessageEncoding」の代わりに「TextMessageEncoding」を使用してみましたが、役に立ちませんでした。

このエラーの意味と解決方法を教えてください。

WCF サービスの呼び出しに使用されるコード:

サーバー App.config からのコード スニペット: http://pastebin.com/7RmPQVUR

クライアントの web.config: http://pastebin.com/Bz9W6mUj

敬具、

ハンス

Java アプリケーションから組織の境界外の AD にクエリを実行し、ADFS と SAML を使用して適切な認証と権限を持つユーザーのリストを取得する必要があります。

私は ADFS と SAML とクレーム ベース認証を初めて使用します。これらのテクノロジーを Java で使用する必要があります。

このシナリオで ADFS を Java と統合するにはどうすればよいですか?

エンタープライズアプリケーションのセキュリティに対するクレームベースのアプローチを実装しています。組み込みのサポート（System.IdentityModelを使用）とWindows Identity Foundation（WIF）を検討してきましたが、どちらもSilverlightアプリケーションをサポートしていないようです。SL4がIPrincipaletalをサポートしていないことは理解していますが、それでもクレームベースの認証を実行できないという意味ではありません。

SL4でそれを行う方法を示すサンプルやドキュメントが不足していますか、それとも自家製のソリューションに任されていますか？

iDM (ADFS ではない) にサードパーティの STS を使用しています。ユーザーがログインすると、リレー側で必要なすべてのクレームが取得されます。

SQL Server に接続するには、Windows トークンが必要です。MSDN ブログで、C2WTS サービスを使用して Windows トークンを取得できることを読みました。STS は upn クレームをアプリケーションに送信しています

ADFS がなく、別の STS からの正しいクレーム (upn クレームを含む) を持つ SAML トークンがある場合、C2WTS を使用して Windows トークンを取得することは可能ですか?

Silverlight、WP7、および ASP.NET MVC クライアント アプリケーションをいくつか持っています。ほとんどのアプリケーションでは、アプリケーションへの匿名アクセスを許可していますが、ログイン時のユーザーの資格情報に基づいてさまざまな機能を保護しています。すべてのクライアントは、データ アクセスとビジネスに共通のバックエンド サービス アプリケーションを使用しています。認証と承認のためにユーザーの資格情報を必要とする処理。

現在、すべてのクライアント アプリケーションでフォーム認証を使用しており、フェデレーション ID とクレーム ベースのモデルを使用するようにアーキテクチャを移行したいと考えています。パッシブ フェデレーションはオプションではありません。

次の流れを探しています。

1. ユーザーはログイン ダイアログをトリガーし、ユーザー名とパスワードを入力して [OK] をクリックします。
2. バックグラウンドで、アプリケーションは認証のために既存のサービス アプリケーションでアクティブな STS サービスを呼び出します。
3. このサービスは実際にはフェデレーション STS であり、ADFS である場合とそうでない場合がある (アクティブな) IP_STS に呼び出しを渡します。
4. IP がトークンを FP に返すと、FP はクライアント アプリケーションにトークンを返す前に、サーバー データ ストアからの追加のクレームでトークンを変更します。
5. クライアント アプリケーションは、承認チェックのためにトークンをメモリ内に保持します (たとえば、Thread.CurrentPrincipal 内)。
6. クライアントは、サービス アプリケーションで他のサービス操作に要求を行うときにもトークンを渡します。
7. これらのサービス操作は、トークンを使用してリクエストを認証/承認します。

これは、私が見つけたどの記事やサンプルとも大きく異なるユース ケースです。誰かがガイダンスを提供したり、正しい方向に向けたりすることはできますか?

Silverlight 4 プラットフォーム (WS-Trust) からのユーザー認証に IdentityServer を使用しています。
ユーザーが適切な資格情報を送信すると、もちろんすべて問題なく、Silverlight アプリの RP に追加のクレームを含むトークン Cookie を作成します。
パスワードが正しくない場合、Silverlight アプリは HTTP ステータス コード 500 (SOAP 仕様で定義された SOAP 例外を送信するための標準値) を受け取ります。

Silverlight http スタックはこのようなステータス コードの結果を無視するため、クライアントに送信する前に STS にこのステータス コードを強制的に変更させようとしました。オブジェクトのインスタンスをエンドポイントの IDispatchMessageInspector インターフェイスにインストール/登録して、その場でステータス コードを変更しようとしていました (SilverlightFaultBehavior が Silverlight と連携する WCF サービスの変更を行うのと同様の方法です)。または私は何かを知りません）。

結果が OK (パスワードは OK) の場合、HTTP ステータス コードを変更でき、IDispatchMessageInspector インターフェイスを持つオブジェクトでメソッドが呼び出されますが、パスワードが正しくない場合、検査オブジェクトのメソッドはまったく呼び出されず、結果を変更できません。 (HTTP ステータス コード) したがって、結果は再び 500 になります。

IdentityServer は適切な構成で WSTrustServiceHost ホスト オブジェクトをインスタンス化するだけなので、WSTrust の処理全体が WIF のみによって行われるように見えます。

トークンが既に古くなっているとどうなるかわかりません。WIF は HTTP ステータス 500 でも例外をスローしますか? Silverlight プラットフォームで WIF によって生成された例外を読み取ることはできますか?

Silverlight 5 は WS-Trust をサポートする必要がありますが、STS サーバーが HTTP ステータス 500 を送信した場合、例外情報は再び無視されますか? Silverlight 5 でテストした人や、そのような問題の解決策を知っている人はいますか?