問題タブ [federated-identity]

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

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

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

thx-e

Windows Identity Framework（WIF）を統合したいSSOの場合、WIFのフェデレーション認証モジュールがWebサイトのすべてのページでトリガーされ、ユーザーをサインインページに送信します。Webサイトの一部のページで認証が適用されませんでした。

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

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

TIA - ekkis

私が開発している ASP.NET MVC 3 サイトは、複数の異なる URL からアクセスでき、それぞれがバックエンドの異なるデータベースに接続します (1:1 URL から DB)。ユーザーが各 URL にログインしなくても、URL を切り替えることができるようにする必要があります。現在、ほぼ標準の MembershipProvider/RoleProvder スキームで Forms Auth を使用しています。

URL の変更を許可し、「ログイン状態を維持する」ためのオプションは何ですか? ある種の連合セキュリティを実装する必要があると思います。おすすめは何ですか？セキュリティのすべての側面を制御する必要があることに注意してください (たとえば、Google ID を使用できません)。

必要に応じて、WCF Web サービスをミックスに追加しても問題ありません。

すべての Web ユーザーをドメイン ユーザーにしたくないので、可能な限り AD と統合したくありません。

EDIT : 認証 DB は現在、すべての URL で同じです

前もって感謝します。

環境：

Stack と Bing には、 WCFとASP.NETとのセッション共有について話しているスレッドがいくつかあります。私の問題を完全に満たすものはありません。だからここに行きます：

パス「/services」の下のRouteTableにもいくつかのサービスがあるMVCサイトがあります。これはすべて本当にうまく機能します。コントローラー アクションと WCF サービス メソッドの両方を呼び出すことができます。

Windows Azure Access Control Service (ACS)でWIFとFederated Authenticationを有効にしました。これもうまく機能します。Facebook、Google などを使用してログインでき、自分のサイトでセッションが明確に確立されています。MVC コントローラー アクションと WCF メソッドを呼び出すことができます。それらの本体内で、現在のユーザーの IPrincipal が現在のセッションに設定されます。

今、私はいい子になりたいと思っており、カスタムClaimsAuthenticationManager とカスタム ClaimsAuthorizationManager を使用しています。奇妙な問題が発生します。

セットアップ:

このシナリオでは、ログインしています。セッションがあります。これは、MVC コントローラー メソッドと WCF サービス メソッドのメソッド本体内で確認できます。つまり、カスタム ClaimsAuthenticationManager は、既にセッションを持っている場合には触れられないため、ここから除外できます。

私の頭痛の種はカスタム ClaimsAuthorizationManager です。

MVC サイトを呼び出すと、ClaimsAuthorizationManager.CheckAccess メソッド内のセッションで認証され、MVC コントローラー アクションの本体内でも認証されます。ここまでは順調ですね。

問題：

WCF サービスを呼び出すと、ClaimsAuthorizationManager.CheckAccess メソッド内のセッションで認証されませんが、WCF サービス メソッド内でブレークポイントに到達すると (突然) 認証されます。

これだけでは意味がありません！私のセッションは ClaimsAuthorization マネージャー内では膨張していないようですが、パイプラインをさらに下ると、自分の WCF コードをヒットするとセッションが配置されます!

どうすればいいの？

乾杯、

マグナス

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

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

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

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

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

フェデレーション ID 管理を実装しており、ユーザーが一意に識別されたアイテムに対して認証する必要があるシナリオがあります。たとえば、ボブはレコード 12345、34444、23443、および 23443 への読み取りアクセス権を持ち、ジェーンはレコード 12345、34444、および 23443 への読み取り/書き込みアクセス権と、レコード 56445 への読み取りアクセス権を持っている場合があります。

2 つの質問があります。

1. たとえば、誰かが 100 から 1000 の個別の一意のレコードにアクセスできるとします。クレーム ベースのセキュリティでは、受信するセキュリティ トークンにこれらすべてのクレームが含まれることを理解しています。トークンのサイズは問題になりますか?

2. 承認を管理するための管理システムの作成に関するガイダンスはあまり見当たりません。つまり、私たちの場合、認証されたレコードにユーザーを割り当てることです。許可を可能な限り宣言的にすることについてのアドバイスはたくさんありますが、それが不可能な場合にどうすればよいかについてのアドバイスはあまりありません。

アドバイスや指示は大歓迎です。

認証メカニズムとして Windows Live ID を使用する実稼働 Web アプリケーションがあります。数ヶ月間、それはうまく機能しています。しかし、8月初旬、突如深刻な問題が発生し始めました...

ユーザーが (別のウィンドウのアプリまたは別の Windows Live アプリを介して) Windows Live に既にサインインしており、サイトに移動すると、[続行] ボタンが表示されます。「既にサインインしています」と表示され、ユーザーが [続行] をクリックすると、サイトにリダイレクトされます。8 月上旬に、この [続行] ボタンが機能しなくなりました。クリックしても何も起こりません。私たちはコードを何も変更していません。見よ、この問題を経験しているのは私たちだけではありません。 -4e10-821b-55c3bae580bc

これは明らかに Microsoft のページのバグです。私たちが必要としているのは回避策です。お客様が既に Windows Live にサインインしている場合、文字通り私たちのアプリにアクセスできません。別の Web サイトにアクセスし、サインアウトしてから、私たちの Web サイトに戻る必要があります。これは苦痛であり、Windows Live を認証メカニズムとして使用することについて考え直す必要があることは想像に難くありません。

Microsoft のバグ修正が保留されているため、私たちは水に沈んでおり、これを顧客に説明する必要があります。回避策を探して独自に取り組んでいます。現在の解決策は、「Web アプリにアクセスするときに Windows Live にサインインしていないことを確認してください」です。理想的とは言えません。何か案は？

ありがとう！

すべての ID プロバイダーが安全にユーザー情報をサニタイズできると想定できますか? それとも、アカウントまたは ID プロバイダーを作成して、悪意のあるユーザー名、電子メール、連絡先リストなどを配信できますか?