問題タブ [claims]

.net4.5でクレームベイズド認証をいじっています。これはかなりうまくいきます。しかし、うまくいけば小さな問題が発生しました。

名前クレームタイプを設定すると、ID名になるはずだと思いました

ident.NameClaimTypeの値がClaimTypes.Nameと同じであることを確認しました。どちらもhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameです。

私は新しい主張を設定しました。私が見ることができるのは、アイデンティティの主張の一部です。しかし、Identity.Nameはまだ空です。

私は何が間違っているのですか？

ClaimsAuthorizeAttribute( .net4.5 ) を使用して、必要なリソースとアクションを次のように定義できます。

複数の属性を追加して、より詳細な権限を付与することもできます

しかし、CheckAccessメソッドには、関係のない2 つの分離されたコレクションがあります。

だから私は「表示」と「編集」があり、反対側に「人」と「設定」があることを知っています

しかし、それが意図されていたかどうかはわかりません

「人物を表示」または「設定を表示」または

「人を編集」または「設定を編集」

それに対処する方法は？

リソースとアクションを意図しない方法で使用していますか?(.net 4.5)

以下のサンプル シナリオを検討してください。

• 運用、テスト、および開発用の単一の Active Directory ドメインがあります (それぞれ OU レベルで分離されています)。
• テスト OU レベルで ADFS をインストールしたいのですが、テスト OU ADFS で認証されたユーザーに他の OU へのアクセス (読み取りと書き込みの両方) を許可したくありません。

これは可能ですか？ADFS 2.0 が特定の OU の下でのみ動作するように制限できますか?

adfsを使用してクレームベースの認証を構成したSharepointがあります。ADFSは、サードパーティのクレームプロバイダーの信頼を使用するように構成されています。したがって、ユーザーがSharePointにアクセスしているとき、ユーザーはadfsを介してサードパーティのIDプロバイダーのログインページにリダイレクトされます。このIDプロバイダー（IdP）は、saml2トークンをadfsに返し、adfsはユーザーをSharePointにリダイレクトします。

問題は、サードパーティのIdPが特定のsaml属性（クレーム）のみを返すように構成されていることです。この特定の属性を理解するようにADFSを構成する必要があります。

カスタムsaml属性は次のようになります。

このクレームをADFSで使用して、SharePointに送信するにはどうすればよいですか？

ありがとう。

次のシナリオがあります

トークンを発行する STS があり、それを使用して ASP.NET アプリケーションをフェデレーションしました。このアプリケーションは、必要な機能を実行するために WCF サービスを呼び出します。

しかし、ASP.NET アプリケーションで ClaimsPrinicipal.Current を調べると、STS へのアクセスに使用したユーザーのクレームに正しく対応していることがわかります。しかし、ASP.NET アプリケーションからサービスを呼び出して ClaimsPricipal.Current を調べると、null に等しいことがわかりました。

回避策として、ASP.NET アプリケーションから ClaimsPricipal.Current を渡し、Thread.CurrentPricipal を WCF サービスに配置しました。

しかし、それが正しいアプローチだとは思いません。

だから私の質問は：

1) ASP.NET クレーム プリンシパルが WCF プリンシパルと異なるのはなぜですか? 2)アクセストークンを使用してWCFサービスにもアクセスする正しいアプローチは何ですか?

アップデート：

ADFS でユーザーを証明書利用者アプリケーションに転送することができました。ComponentSpace の SAML2.0 ライブラリと RelayState を使用しました。WIF アプリケーションに正常に転送されますが、ユーザーが認証されたと認識されません。代わりに、IDP STS にリダイレクトすることで、SP が開始する SSO シナリオを開始します。どのように進めればよいのかよくわかりません。

オリジナルメッセージ：

次の方法でシングル サインオン セットアップを構成しました。

IDP - SAML2 応答を SP に投稿するポータル Web サイト。

SP - SAML2.0 エンドポイントとして構成されたクレーム プロバイダー信頼で構成された ADFS 2.0 (もちろん私の IDP を使用)

RP アプリケーション - ADFS (WS-Fed) で証明書利用者信頼として構成された ASP.NET アプリケーション。

IDP にログインし、SAML2 トークンを ADFS にポストするリンクをクリックすると、すべて正常に動作します。IdpInitiatedSignOn.aspx ページに移動すると、ログインしたことが通知されます。問題は、通常、選択するアプリケーションのドロップダウン リストが表示されることを期待する場所です (単一の RP アプリケーションのみが含まれている必要があります)。何も見えません。すべてのアプリケーションまたは 1 つのアプリケーションからサインアウトできるボタンは 2 つしかありません。私が認識していない RP アプリケーションの信頼を構成するためのトリックはありますか? ADFS 2.0 が SAML2 と WS-Fed のこの構成を受け入れることは、私の理解でした。( 「いつ RelayState を使用できますか?」の下のhttp://blogs.technet.com/b/askds/archive/2012/09/27/ad-fs-2-0-relaystate.aspxを参照してください)。

これに関するアドバイスをいただければ幸いです。

次の問題があります。

私のチームは、SharePoint チーム サイトを使用して、特に仕事を提供しています。私たちは SharePoint 開発者であり、多くの PowerShell を作成していますが、このサイトに関する限り、私たちは単なるユーザーであり、管理者ではありません。サイトとの間でドキュメントをアップロードおよびダウンロードするスクリプトを作成しました。以下は、私たちが行ったことの簡単な例です。

Get-Credential 関数により、ユーザー名とパスワードのダイアログがポップアップ表示されます。これは、サイトのプロバイダーが認証方法をクレームに変更するまで機能しました。これで 403 が返されます:

「リモート サーバーがエラーを返しました: (403) 許可されていません。」

SharePoint Web アプリケーションでクレーム認証を設定する方法に関する記事をたくさん入手しました。しかし、これはすべて管理者のものであり、サイトで必要な権限がないため、私には役に立ちません。私が必要とするのは、それを使用する方法の例です。powershell からクレームを使用して認証する方法。Get-Credential を介して取得した資格情報を提供するだけでは、もはや十分ではありません。

追加情報: 正しい資格情報を使用しています。ブラウザーから手動でサイトにログオンしようとすると機能します。アクセスしようとしているファイルに対する完全な権利も持っています。SharePoint 2010 向けに開発している Powershell バージョン 2 を使用しています。私が認証しようとしているサイトも (おそらく) SharePoint 2010 です。前もって感謝します。

最初に何をしようとしているのかを説明します。たとえば、クレーム識別子が渡されてい0e.t|saml provider|first.last@domain.localます。にトリミングしたいfirst.last@domain.local。

これは単純な文字列フォーマットで実行できることはよく知っていますが、これはあまり柔軟ではないため、予期しないものが渡されると、文字列フォーマットが失敗する可能性があります。問題が発生しやすくなります。

代わりにこれを動的に行いたいです。これが私が試したことです。

上記のクレーム識別子をEnsureUser使用して、SPUser.Name を呼び出します。

のパラメーターとして次の文字列を試しましたがEnsureUser、すべて例外が発生します。The user with the specified logonName cannot be found in Active Directory.

0e.t|saml provider|first.last@domain.local

saml provider|first.last@domain.local

first.last@domain.local

繰り返しますが、それらはすべて失敗します。

（このブログSPClaimProviderManagerから引っ張ってきました）を使用して、私が試した別のアプローチ：

他の何かではなく、実際のクレームをデコードしようとしていることを確認したいので、 を呼び出しますIsEncodedClaim。ただし、これは常に を返しますfalse。

私の質問:

1) これらの試みの両方が失敗する結果となる、ここで間違っていることは何ですか? それらが適切に機能するためには、何を別の方法で行う必要がありますか?

2) 文字列を解析せずにフレンドリ クレーム ユーザー名を取得するためのより良い方法はありますか?

私は BrockAllen.MembershipReboot を使用しています

請求が正確にいつ更新されるかに関して、請求の処理に問題があります。以下のコードは私の問題を示すはずです...

私の質問はこれです：

System.Security.Claims.ClaimsPrincipal.Current.Claims.GetValue()メソッドが Cookie が発行された時点でクレームを強制的に更新する方法はありますか?