問題タブ [claims-based-identity]

私は、フォームベースの認証とクレームベースの認証の両方を使用するWebサイト（ASP.NET C＃を使用）に取り組んでいます。カスタムIsAuthenticatedメソッドを実装し、クレーム認証に固有のIDにさらにプロパティを追加できるように、ClaimsIdentityクラスをオーバーライドしたかったのです。

現在、カスタムWSFederationAuthentionModuleを実装していますが、デフォルトのClaimsPrincipalではなくカスタムID /プリンシパルを設定できるように、オーバーライドする必要のあるモジュール（具体的にはどのメソッド）を見つけようとしていましたか？

これまで、SessionAuthenticationModuleとClaimsPrincipalHTTPModuleの両方を見てきましたが、プリンシパルが設定されているステップ/それをオーバーライドするための最良の方法を理解できませんでした。

ありがとう

追加： 私はこれに少し慣れていないので、これが正しいことを確認させてください：IDを設定する方法は、そのIDを使用するように設定されたカスタムプリンシパルを設定することです。

または、カスタムプリンシパルが不要な場合は、ClaimPrincipalクラスをClaimsIdentityCollectionを使用して構築できます。

私はAzure ACS Labsと協力して、 FederatedServiceCredentialsを使用してアクティブ フェデレーションのユーザーを認証しています。ここで、WCF サービス内からユーザーのクレームにアクセスしたいと考えています。

この記事によると、クレームはリクエストスレッドによってアクセスされます...誰かがそれが何を意味するのか説明または実証できますか?

.\sharepointにある私のデータベースメンバーシップ3 には、多数のメンバーシップ ユーザーがいます。

管理センター サイト用のweb.configファイルがあります

新しいクレーム ベース サイトのweb.configファイルがあります。

ファイル C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\Root\web.config :

Admin Center サイトでユーザー ポリシーを設定したいのですが、FBA ユーザーがPeople Picker に来​​ません。しかし、私のクレームベースの認証サイトは、どの FBA ユーザーともログインできません。管理センターのサイト設定で何が問題になっていますか?

Sharepoint 2010 で新しい Web アプリケーションを作成し、[認証] オプションで [クレーム ベース認証] を選択すると、[信頼できる ID プロバイダー] ボックスがグレー表示されます。

カスタム STS や ADFS のようなものを追加する方法についてのブログなどがありますが、組み込みの SharePoint STS は ID プロバイダーではありませんか?

Sharepoint STS は Web アプリケーションでどのような役割を果たしますか? 違うタイプのSTSですか？

STS と信頼関係を持つ通常の Windows Identity Foundation (WIF) アプリケーションでは、STS によって提供されるログイン画面が表示されます。

Sharepoint 2020 で、ログイン画面が表示されませんか?

Sharepoint クレーム対応アプリケーションは、WIF クレーム対応アプリケーションとは異なりますか?

私は最近WIFをよく研究していますが、いくつかの詳細についてはまだかなり混乱しています。ADFSを使用している場合、それは素晴らしいことだと理解していますが、それは私のシナリオではありません。私の組織内には、少なくとも3つの主要なセキュリティシステムがあります。私は会社にすべての内部用途にADを使用させようとしましたが、それは実現しません。統一されたプログラミングモデルを作成するために、認証/承認のために追加のSTSを構築することを検討しました。

1. これは本当に賢明ですか？私が読んだもののほとんどは、ADFSを使用するだけだと言っています。そうでない場合は、気にしないでください。カスタムSTSを作成するプロセスが難しい場合、統合クレームモデルにWIFを使用する価値はありますか？

2. すべてのユーザーがマップ先のADログインを持っているわけではない場合はどうしますか。たとえば、個人アカウントで実際にマシンにログインすることのない季節限定の従業員がたくさんいます。マシンは上司によって午前中にログインされ、従業員は自分のバッジをスキャンし、従業員IDが使用されます。

3. 少なくとも3つの異なるユーザーセットがコードベースにアクセスする新しいアプリケーションを作成しています。1つのグループは内部（ADを使用）であり、他の2つはおそらくasp.netのデフォルトメンバーシップを使用します（わかりました。2つの異なるユーザーストアのセットです）。WIFを使用して承認/認証を統合できるようにしたいと思いますが、WIFでは反対方向に進みたいようです。それは認証を強調せず、多くの場合それが主な関心事である場合、それがすべて良いと仮定します。このシナリオでWIFを活用するにはどうすればよいですか？

私はこの記事を読んでみました：

http://msdn.microsoft.com/en-us/library/ff359105.aspx

そして私はStarterSTSについて読みましたが、それでももう少し読む必要があります。StarterSTSの作者のビデオも見ました。私は本当にすべてをまとめることに失敗しています。WIFは私には役に立たないように感じますが、私が本当に求めているのは認証と承認の統一されたモデルであるため、そうすべきだと思います。ありがとう

Access Control Service (ACS)とWindows Identity Foundation (WIF)を使用して、WCF Data Services Web API アプリケーションを保護することを考えています。

クレームを使用してユーザーを一意に識別するにはどうすればよいですか?

私の考えは、標準クレームNameIdentifierと WIF クレーム IdentityProvider を組み合わせて使用​​し、任意のユーザーに一意の ID を作成することです。

このコンボは本当に安定してユニークですか? IP が IdentityProvider 文字列を突然変更する可能性はありますか?

ここでの考え方は、2 つの半分を連結した文字列を任意のユーザーの一意の ID として保存することです。

NameIdentifier クレームにはセキュリティ上の意味がありますか?

乾杯、

M.

Windows Phone 7 アプリケーションを開発しています。クレームベース認証は初めてです。次のリンクを使用して、wp7 でクレーム ベースのサイトに対してクレーム ベースの認証を行っています。

http://blogs.msdn.com/b/pstubbs/archive/2010/10/04/developing-windows-phone-7-applications-for-sharepoint-2010.aspx

上記のリンクでは、authServiceUri の uri をhttp://login.live.com/として使用し、適切なユーザー名とパスワードを渡しています。「サインインするには JavaScript が必要です。お使いのブラウザは JavaScript をサポートしていないか、スクリプトがブロックされています」というエラーが表示されます。このエラーを取り除くにはどうすればよいか教えてください。私が何か間違ったことをしているなら、私を導いてください。クレーム ベース認証に関する新しいアイデアがある場合は、そのアイデアを共有してください。

ページの 1 つに Silverlight アプリを含む Web アプリケーションがあります。Web サイトは WIF を使用して保護されています。Silverlight から自分の Web サイトと同じ appdomain でホストされているサービスに WCF 呼び出しを行おうとしています。

AspNetCompatibilityMode を有効にしている場合、これは正常に機能します。ブラウザーは既に認証されているため、WCF 呼び出しが行われると、Silverlight クライアントによって FedAuth Cookie が送信され、WIF はセッション Cookie (FedAuth/FedAuth1) から HttpContext.Current.User を正しく設定します。

残念ながら、AspNetCompatibilityMode をオフにする必要があります。この場合、Silverlight WCF 呼び出しが引き続き FedAuth Cookie をサーバーに渡し、SessionAuthenticationModule が Thread.CurrentPrincipal を正しく設定していることがわかります。残念ながら、sessionauthenticationmodule は、呼び出しようとしている実際の WCF メソッドとは別のスレッドで実行されているように見えるため、WCF/WIF パイプラインのどこかで ID を失いました。

これを回避する方法はありますか？SessionAuthenticationModule のカスタム実装を作成し、SetPrincipalFromSessionToken をオーバーライドしようとしましたが (その中でクレームなどにアクセスできます)、チャネル ハンドラーが呼び出しをディスパッチした後にプリンシパルにアクセスできるように、プリンシパルをどこに格納できるかわかりません。別のスレッドでサービスを提供します。

タイプのクレームは何http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifierに使用する必要がありますか?

これが主な質問であり、ここに追加の質問があります。

請求とどう違うのhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/name？

名前の主張とは対照的に、特定のユーザーに対して永続的ですか?

グローバル スコープですか、それとも IdP スコープですか?

Sharepoint 2010 でいくつかの Web パーツを作成しました。現在のバージョンでは、ユーザーは Ad ログインによって認証されますが、今ではそれをカスタマイズして、AD ログインまたは電子メール名による認証を許可したいと考えています。

私の問題は、ユーザーがクレームによって認証されているかどうかを確認する必要があることです (これを管理 Web パーツで使用するため)。sharepoint でユーザーのログイン名を確認できることはわかっています。それがi:0#.f|ldapmember|user@example.com
の形式であれば、Claims がオンになっていることを意味します。

しかし、クレームがオンになっているかどうかを確認するより良い方法があるでしょうか? 誰かその方法を知っていますか？