問題タブ [claims]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
wcf - Geneva Server STS
私の要件は、ユーザーに割り当てられたクレームが会社を認識していることです。たとえば、ユーザー1は会社1のプロダクトマネージャーの発行者ですが、同じユーザーは会社Bの編集者のみです。これはGeneva Server、または追加のコードが必要な場合に実現できますかクラスをオーバーライドするために作成されます。
wcf - ASP.Net WCF サービスの Thread.CurrentPrincipal は、Federated (WIF) 環境で一部のインターセプターによって破棄されています。
IIS (.svc) でホストされている呼び出しごとの WCF サービスがあります。サービスのコンストラクターで、この記事に従ってThread.CurrentPrincipal = HttpContext.Current.Userを設定しました。この場合、HttpContext.Current.UserはMicrosoft.IdentityModel.Claims.ClaimsPrincipal型であり、カスタム パッシブ STS から送り返されたクレームを持っています。
ただし、サービス操作に入ってThread.CurrentPrincipalを調べるとすぐに、このオブジェクトはまだMicrosoft.IdentityModel.Claims.ClaimsIdentity型ですが、オブジェクト自体はHttpContext.Current.Userと同じではなくなります( IsAuthenticated = false 、 AuthenticationType = "" 、および Name が Thread.CurrentPrincipal.Identity で null である場合)、これらの値はすべてHttpContext.Current.Userで正しく入力されます。これは、何かが操作への呼び出しをインターセプトし、現在のプリンシパルを一般的な、空の、認証されていないクレーム プリンシパルに誤って変更していることを示しています。
コンストラクターと操作でスレッド ID を確認しましたが、両方の場所で同じであり、HttpContext.Current.Userから割り当てた後、即時ウィンドウでThread.CurrentPrincipalを評価すると、スレッド ID が正しく設定されていることがわかります。コンストラクターなので、コンストラクターとメソッドの間で何かが確実に実行されており、その何かが私のThread.CurrentPrincipalを変更しています。
誰がこれをしているのか、どうすればこの動作を防止/修正できるのか分かりますか?
sharepoint-2010 - BDC での SharePoint 2010 クレーム
BDC ReadList() 操作で、ユーザー クレームからの電子メールに基づいてオブジェクトを取得したいと考えています。Web パーツで IClaimsPrincipal を使用してみましたが、問題はありませんでしたが、BDC モデルでは動作しません。
基本的に私はこのようなことをしたいと思います:
ReadList() { 1. Claims オブジェクトを取得する 2. Claims オブジェクトから電子メールを取得する 3. その電子メールでクエリを実行する 4. クエリ結果を返す }
この問題に関する考えやアイデアは非常に高く評価されます。
security - クレームベースの認証:文字列はクレームの本質ですか?
私はしばらくの間、WindowsIdentityFoundationを使用してクレームベースの認証を使用してプログラミングしてきました。
Windows Identity Foundationでは、ユーザーがログインすると、クレームは基本的にユーザーを説明する一連の情報であるように見えます。
以前の役割ベースの認証では、ユーザーは特定のグループのメンバーであるかどうかを判断できましたが、クレームベースの認証では、ユーザーを説明する一連の情報を取得できるようになりました。「このユーザーは女性です」。このユーザーは「1975年7月6日」に生まれました。「このユーザーはUSBキーを使用してログインしました」。
フレームワークによってアプリケーションに与えられたユーザーに関する一連の情報を持っているのは、クレームベースの認証の本質ですか?
wif - WIF を使用したパッシブ STS から追加の要求を要求するにはどうすればよいですか?
私は次のものを持っています:
- ID プロバイダーとして機能する Web サイト ASP.Net アプリケーション (IDP STS)
- フェデレーション プロバイダー (FP STS)
- (RP) として機能するリソース ASP.NET MVC Web サイト
RP でリソースにアクセスしようとすると、FP STS を通過し、IDP STS にリダイレクトされます。ユーザーは資格情報を入力し、その有効性が確認されると、IDP はいくつかのクレームを提供し、それが FP STS に渡されてから RP に送り返されます。RP 側では、クレームが受信され、リソースが提供されます。RP から追加請求を行うにはどうすればよいですか?
どんな提案や方向性も素晴らしいでしょう! ありがとうございました、
wif - JAVA ベースの STS によるクレームベースの認証?
Java ベースの STS サービスがあります。WIF が提供するクレーム ベースの認証にこの STS を使用したいと考えています。誰かがこれを達成する方法について洞察を提供できますか? 私が遭遇したすべての例は、C# ベースの STS と C# ベースの RP を使用しています。私の場合、RP は C# にすることができますが、STS は Java である必要があります。具体的には、要求された SAML がどのように STS に渡され、クレームの形式が RP に戻されるかを知りたいと思います。
ありがとう、ソムナス
.net - WebClient 経由で SharePoint リストのファイルにアクセスしようとすると 403 応答が返される
System.Net.WebClient を使用して SharePoint リスト内のファイルにアクセスしようとしています。リストでは匿名アクセスが無効になっており (有効にすると機能します)、クレームベース認証を使用しています。SharePoint リスト内のファイルにアクセスする方法が他にもあることは知っていますが、これは、画像を生成するファイルの URL を渡す必要がある Office Web Apps Web サービスに対して行う呼び出しに関するものです。 . この URL で OWA Web サービスを呼び出しても、WebClient を介してファイルを直接ダウンロードしようとしても、同じエラーが発生します。
エラーは 403 禁止されています。いくつかのグーグル検索の結果、原因は何らかの形でクレームベース認証の使用に関連していると考えられます。提案された多くの救済策を試しましたが、これまでのところ何も機能していません. ブラウザを使用してファイルと Web サービスにアクセスでき、認証チャレンジを取得した後に機能します。意図的に認証チャレンジに失敗すると、(403 ではなく) 401 エラーが発生するため、資格情報に問題があるとは思いません (ハードコーディングするまでは行っています)。RunWithElevated Privileges でコードを実行しようとしましたが、役に立ちません。
サンプルコードは次のとおりです。
どんな助けでも大歓迎です!
wcf - Windows ID Foundation は、wcf サービスからのアクセスを要求します
WCF メソッドの実装から Claims を取得しようとすると、 type のオブジェクトが取得され、System.Security.Principal.WindowsPrincipal
それは type のオブジェクトである必要がありますMicrosoft.IdentityModel.Claims.ClaimsPrincipal
。このオブジェクトを達成するための設定で何が欠けているか知っている人はいますか?
コード行: IClaimsPrincipal principal = Thread.CurrentPrincipal as IClaimsPrincipal;
前もって感謝します
c# - クレームを使用した、basicHttpBinding WCF サービスに対する Ntlm 認証
この特定のクレーム認証環境はたまたま SharePoint です。SharePoint には、クレーム認証を強制する独自の http モジュールがあります。認証されていないアクセスでは、クレーム ベースの認証 (Ntlm やフォームなど) の一連のオプションが発生します。
WCF サービス クライアントは、明らかに、SharePoint が返す 403 メッセージをどう処理すればよいかわかりません。理想的には、URL "/_windows" に対して Ntlm 認証シーケンスを実行し、401 チャレンジを生成してから、結果のフェデレーション Cookie を WCF サービスに渡します。
これは、複数認証オプションのクレーム ベースのサービスを処理するベスト プラクティスの方法ではありませんが、この件に関する適切なリソースを掘り下げることはできません。basicHttpBinding は無駄ですか? この時点での選択肢は何ですか?
c# - クレーム環境での WCF サービスに対する適切な認証
クレーム認証モードの SharePoint Web アプリケーションは NTLM をサポートしますが、次の手順を実行する必要があります。
- 2 番目の場所への HTTP 302 リダイレクト。
- NTLM 認証の HTTP 401 チャレンジ
- HTTP 401 検証
- 元の場所 (サービス) に戻る HTTP 302 リダイレクト
これを処理するカスタム動作、チャネル ファクトリ、またはバインディングを記述できますか? これについてもっと良い方法はありますか?