問題タブ [ws-federation]

追加の説明が必要です。

このリンクから正しく取得した場合、フェデレーション認証トークンはどこに保存されますか [WIF STS]? およびその他の一般的な WIF-STS の議論では、STS トークンは既定のシナリオではブラウザーの Cookie に保存されます。私のブラウザでは、FedAuth で始まる 2 つの Cookie に分割されています。大丈夫です。よく理解できれば、RolePlayer アプリケーションでの STS トークンの検証後に、WIF によって Cookie が作成されます。その場合、Cookie は RolePlayer アプリケーション ドメインにあります。ユーザーが RolePlayer2 アプリケーション (フェデレーションおよび 2 番目のドメイン) にヒットしたとき、作成された Cookie にアクセスできない場合に、STS がそのユーザーをどのように認識するか。

これを明確にしていただけますか？

.NET 4.5 で新しい ASP.NET MVC アプリケーションを作成しました。STS による認証を正常にセットアップしました。認証フローは正常に機能しており、必要なクレームを含む ClaimsIdentity を Thread.CurrentPrincipal で取得できます。

ここで、サービス層への呼び出しを保護するためにブートストラップ トークンが必要です。identityConfiguration 要素で saveBootstrapContext を true に設定しました。

ただし、ClaimsIdentity の BootstrapContext プロパティは常に null です。

ここで何か不足していますか？これは簡単なはずでした:(

Windows Identity Framework (WIF) を使用して IP-STS を作成し、1 つのフェデレーションの下で 3 つの個別の証明書利用者を作成しました。フェデレーション シングル サインオンおよびサインアウトのシナリオは正常に機能します。これはデモとして用意されています。

私の問題は何ですか?

本番環境では、3 つの異なる Web アプリケーションを同一の屋根の下で統合する必要があります。現在、これらのアプリケーションはすべて異なる認証および承認メカニズムを備えており、データ ストアでは、特定のユーザーなどに異なるテーブル セットが割り当てられています。サインオンとサインアウトについては、すべて明らかです。問題は、新しいユーザーの作成にあります。これらのシナリオに一般的なパターンはありますか。なぜ私はこれを求めているのですか。このケースを深く掘り下げると、それほど単純ではないことがわかります。最初の Web アプリでは、サポートされている一連のフィールド (これらのほとんどは DB からのいくつかの列挙) があり、2 番目のその他のセットから... したがって、すべての依拠当事者からこのプロセスのすべてのデータを取得する必要があります。 . これを達成する方法は？1つのアプローチは、一連のIFRAMESまたはそのようなものを使用することですか? また、ユーザー エンティティに依存する別のアプリケーションのリレーション テーブルがあるため、各アプリケーションに新しいユーザーが必要になります。私には非常に複雑に見えますが、このケースによく知られているパターンはありますか? まったく異なるアプリケーションを 1 つの ID 管理下で統合しなければならないのは、私が初めてではないと確信しています。

更新: これはプロビジョニング管理またはフェデレーション プロビジョニングの一部であることがわかりました。また、SAML プロトコルと歩調を合わせている SPML プロトコルで実現できることもわかりました。これらの目的で WIF に統合するプロトコルまたはポイントはありますか?

よろしく、ラストコ

SAML2プロトコルを使用するIDプロバイダー（claimsprovider）を備えたフェデレーションプロバイダーとしてADFS2.0を使用しています。ADFSの証明書利用者は、WS-Federationプロトコルを使用します。

これで、証明書利用者に要求し、SAML2 IDプロバイダーでサインインしてサインアウトできるようになりました。これにより、ADFSはサインアウト要求をIDプロバイダーに送信し、実際にサインアウトします。

この問題は、同じセッション中に（ブラウザーを閉じずに）証明書利用者に再度要求し、SAML2 IDプロバイダーで再度サインインしてから、サインアウトしようとしたときに発生します。ADFSはサインアウトされたページを表示しますが、IDプロバイダーにサインアウト要求を送信しないため、プロセスはそこで停止します（ADFSで）。その後、再度サインインしようとすると、当然、IDプロバイダーでまだサインインしているので、IDプロバイダーで「バウンス」します。

最初のサインアウト（常に機能します）の後、これはその後のすべての試行で発生します。

関係とプロトコルは次のとおりです。

RP <--- wsfed ---> ADFS <--- samlp ---> IDP

asp.netアプリケーションをフェデレーションするための次のネットワーク構成がありますが、ホームレルム検出画面が表示されません。何が間違っているのか理解できません。

ADFS＃1-ADFS＃2による信頼関係者の信頼

ADFS＃2-私のWebアプリケーションでの信頼関係者の信頼。-ADFS＃1でプロバイダーの信頼を主張します-ActiveDirectoryでプロバイダーの信頼を主張します

Webサーバー-ADFS＃2へのSTS参照を持つASP.NETアプリケーション。

Webサイトにアクセスしようとすると、ADFS＃1または＃2のレルムを選択できる缶詰のホームレルム検出画面が表示されると思いました。代わりに、ADFS＃2のドメイン（アプリケーションにSTS参照がある）への資格情報の入力を常に求められます。どんな助けでもいただければ幸いです。この構成は正しいと思いました。

セキュリティ トークンを使用して factory.CreateChannelWithActAsToken を呼び出すと、間違った名前空間を使用し、間違った信頼バージョンを期待して STS の問題が呼び出されます。

STS に接続し、WSTrust13 を使用して WSTrustChannel でトークンと ActAs トークンを手動で要求でき、完全に正常に動作します。しかし、WS2007FederationHttpBinding をセットアップして STS をポイントすると、常に間違った形式を使用して発行リクエストが行われます。STS に足を踏み入れ、WSTrust13ResponseSerializer の代わりに WSTrustFeb2005ResponseSerializer を使用してメッセージを逆シリアル化する必要がありました。

私はおそらく何かがどのように機能するかを誤解していると確信しています。しかし、これは機能するはずですが、そうではありません。入力はありますか？

Azure ACS 2.0 を使用して WCF 4.5 サービスをセキュリティで保護するにはどうすればよいですか?

最近、既存の Web アプリケーションでクレームベース認証を使い始めました。アプリケーションは jQuery と、特に AJAX 関数を使用するため、ハンドラーを変更してXmlHTTPRequests.

FederatedAuthentication.WSFederationAuthenticationModule.AuthorizationFailedイベント ハンドラは次のとおりです。

AJAX 呼び出しを実装して応答を処理する次のパターンがあります。

'Session.aspx' は基本的にモーダル ダイアログを閉じて、ID プロバイダーへのリダイレクトと戻りが成功した場合、戻り値は true になります。

しかし、私の問題は、次のエラーが発生することです。

「ID4223: SamlAssertion.NotOnOrAfter 条件が満たされていないため、SamlSecurityToken は拒否されました。」

これは、現在のアプリケーション ユーザーを偽装するサブシステムで呼び出され、明らかに前のセッションのトークンが引き続き保持されます。アプリケーションの web.config に次の設定があります。

このエラーを回避するにはどうすればよいですか? どんな助けでも大歓迎です。