問題タブ [claims]

SSO を使用するクレーム ベース認証の場合、アプリケーションは発行者から特定のユーザーのトークンを受け取ります。そのトークンには、発行者が信頼されていることをアプリケーションが追跡できるように、クレームと何らかのデジタル署名が含まれています。 1。このアプリケーションが発行者を認識するための何らかのアルゴリズムが含まれているかどうかを知りたいですか? 発行者には公開鍵があり、他のすべてのアプリケーションには独自の秘密鍵があると読みましたが、本当ですか?

私は4.5で新しいものをいじっていて、新しいクレームベースのセキュリティモデルでいくつかのことをチェックすることになっている単純なコンソールアプリケーションを作成しました。ClaimsAuthorizationManagerとClaimsAuthenticationManagerのカスタム実装を作成し、それらをアプリケーション構成ファイルに追加し、AppDomainプリンシパルポリシーをWindowsプリンシパルに設定しました。ほとんどすべてが、AuthenticationManager.Authenticateメソッドが呼び出されることを除いて正常に機能します。

AuthorizationManager.CheckAccessが期待どおりに呼び出されています。

コンソールアプリを実行しているとき、ユーザーはすでに認証されており、アプリの起動時にそれを行う必要がないため、これは正しい動作だと思います。ただし、データベースに保存されているプロファイルに基づいて、いくつかのクレームを変換したいと思います。もちろん、手動で実行して、CurrentPrinciapalオブジェクトを自分で処理することもできます。ただし、アプリにAuthManagerを使用して強制的に実行させる方法があるかどうか疑問に思っていました。

ただ好奇心が強い:)

それで、ここに2人のマネージャーがいます。それらは基本的に何もせず、ブレークポイントを設定するためだけに存在します:)

App.configは次のようになります。

そして、特別なことを何もしないコード：

私の会社は ADFS と WIF を使用して、SSO 機能を備えた内部ポータルをセットアップしています。現在、ユーザーの Active Directory グループに基づいて SQL 属性ストアから追加のクレームを作成するカスタム ルールがあります。

数年後には、30 ～ 40 を超えるアプリケーションがポータルに組み込まれる可能性があります。保守を容易にするために、これらすべてのアプリに適用されるこれらの基本ルールを 1 か所で変更したいと考えています。ADFS の証明書利用者エントリごとにカスタム ルールを設定する必要はありません。

また、SharePoint はポータルのオプションではありません。

これを達成するための最良の方法について誰かアドバイスをいただけますか?

クレームとフォーム認証を使用して、同じ SPWebApplication でHNSC https://division1.corp.com https://division2.corp.com を実行する必要があります。https://division1.corp.comにログインすると、 https://division2.corpにアクセスできるはずですが、ログオン ダイアログ ボックスが再度表示されます。UserInformationList は、この HNSC 間で同期されます。クッキーを見ると、それらは異なっています。これをどのように解決しましょうか。

ASP 4.5 Web サイトでの認証に ClaimsPrincipalPermission を使用しています。

これはうまくいきます。

しかし、ユーザーが許可されていないページを呼び出そうとすると、返されるエラー コードは 500 であり、401 のようなものではありません。

これは予想される動作ですか? 401 は、このページを呼び出せない理由をより多く表現すると思います。

または、エラーがありますか? デバッガーでは、securityexception が正しくスローされていることがわかります。

この動作を変更する方法はありますか? なぜこれが起こるのか誰か知っていますか？

ASP.NET MVCユーザーが認証されているかどうかを確認するコントローラーコードがいくつかあります。認証されている場合は、特定のクレームがあるかどうかを確認します。正常に動作します。

いくつかの単体テストがあり、モックを作成する必要がありますIPrincipal(これは簡単に実行できます) ... しかし、クレームを確認する方法がわかりません! 私は通常、次のようなことをします

そしていくつかのコントローラーコード...

しかし、ユニットテストでこれをテストすると、これはすべて失敗します..どうすればよいかわからないためmockですClaimsPrincipal

何か案は？

環境：SharePoint 2010

認証 : クレーム ベース (ACS 経由の Windows Live) および Windows クレーム。

承認 : PUID を使用してサイトの Contribute グループに追加されたユーザー。

問題 : ユーザーが SharePoint ページのいずれかのリンクをクリックすると、ユーザーはサインイン ページにリダイレクトされます。これは Live ユーザーのみに発生し、Domain ユーザーには発生しません。

設定がありませんか？

全て、

私はクレームベース認証について多くのことを読んでいますが、まだ少し混乱しています。特にSharePoint2010/2013だけでなく、一般的に（つまり、ASP.NET）についても、理解を深めようとしています。

さまざまな技術用語についての私の理解は次のとおりです。

• WIF（Windows Identity Foundation）-IDクレームの使用やカスタムSTSの構築などに使用される.NETライブラリ（APIのセット）。

• 依拠当事者-クレームの「消費者」（つまり、SharePoint、ASP.NET Webサイトなど）。クレームはSTSを介して提供されます（IP-STSのみ？）。

• STS（セキュリティトークンサービス）-セキュリティトークンを発行する特殊なWebサービス。2つのフレーバーがあり、一部のSTSはおそらく同時に両方のフレーバーですか？

  • RP-STS（証明書利用者セキュリティトークンサービス）
  • IP-STS（IDプロバイダーセキュリティトークンサービス）

• 信頼できるIDプロバイダー（SharePointの用語）-別名。IP-STS。

• SharePoint2010/2013STS-RP-STSとしてのみ機能するWIFを使用して開発されたSharePointサービスアプリケーション。ユーザーが構成可能な多数の信頼できるIDプロバイダー（IP-STS）のプラグ可能な集約ポイントとして機能します。これらは、必要に応じてWIFを使用して手作業で作成できます。

• ADFS2.0-ActiveDirectoryインスタンスに対してのみ組織を統合するために特別に設計されたWindowsの役割。WIFを使用して構築されたIP-STSエンドポイントを公開します。ADFS 2.0についての私の理解では、他のIDプロバイダーを「集約」することはできません。ローカルではない可能性があるため、SSOをサポートするためにフェデレーションする必要がある特定のADインスタンスに対して認証することができます。 。

• Windows Azure ACS 2.0-構成済みのサードパーティIDプロバイダー（Microsoftアカウント、Google、Facebook、ADFS 2.0など）を統合するためのサービス。依拠当事者のように機能する他のIDプロバイダーのプラグ可能な集約ポイントとして機能します。WIFを使用して構築されたIP-STSエンドポイントを公開します。集約するIDプロバイダーは必ずしもIP-STSである必要はありませんが、ACS 2.0は、組み込みのIP-STSを使用してクレームを通じてすべてを公開します。

SharePoint 2010/2013の質問：

私の主な問題は、ADFS 2.0とSharePointについて説明している記事をいくつか見たことです。これらの記事は、組み込みのSharePoint2010/2013STSをADFS2.0に置き換えているかのように読めます。これはうまくいけば私の読書ですが、それは私の理解を混乱させました。

1. あなたは実際にこれを行うことができますか？本当に必要な場合にできなかった理由はわかりませんが、SharePoint STSを無効にして、多くの手動構成を行う必要があると思いますか？
2. なぜあなたはこれをしたいのですか？

2.1。AD認証はSharePointSTSによってOOTBトラステッドIDプロバイダーオプションとして既にサポートされており、代わりにADFS 2.0を使用する場合は、ブログ投稿を見たトラステッドIDプロバイダー（IP-STS）としてこれを追加できます。

2.2。ADFS 2.0の説明に基づいて、SharePoint STSに変更すると、実際には柔軟性の低いソリューションになりますか？

ステートメント：

• SharePoint STSは、ローカルADと同様に、またはローカルADの代わりにADFS 2.0 aa Trusted Identity Provider（IP-STS）を使用するように構成できます。
• Windows Azure ACS 2.0 aa信頼済みIDプロバイダー（IP-STS）を使用するようにSharePointSTSを構成できます。これにより、WIFを使用して独自のIP-STSを開発しなくても、サードパーティの認証プロバイダーをサポートすることが非常に簡単になります。

ASP.NET WIFの質問：

1. 私の理解では、信頼交渉とクレーム交換を実行するには、RP-STSがIP-STSと通信する必要があります。これは正しいです？
2. したがって、WIFを使用するときにクレームベースのASP.NET Webアプリケーション（証明書利用者）を構築する場合、RP-STSを開発/再利用してアプリに組み込み、IPとの信頼関係を持つように構成します- STS？そうでない場合は、WIFを使用してIP-STSから直接IDを取得できますか？

これを書くだけで頭から離れることができましたが、不正確さ/過度の単純化/完全な誤りについての助けをいただければ幸いです。

よろしく、

マイケル・テイラー

私のアプリケーションでは、階層データ (ツリーなど) があり、ユーザーは親に関係なくツリーの任意のノードにアクセスできます。ここで、WIF が属性とともにどのように役立つのでしょうか?

次のシナリオがあります。

• Sharepoint 2010 とクレーム ベース認証 Web アプリケーション。
• ThinkTecture IdentityServer に対するクレーム プロバイダーの信頼を構成した ADFS 2.0。
• ADFS 2.0 を証明書利用者として構成した ThinkTecture IdentityServer。
• Sharepoint 2010 には、ADFS 2.0 を指すように構成された SPTrustedIdentityTokenIssuer があります。

Sharepoint にログインしているときに、ID プロバイダーを選択すると、ADFS 2.0 ホーム領域ページにリダイレクトされます。次に、ThinkTecture IdentityServer にリダイレクトされます。次に、IdentityServer からの資格情報でログに記録され、ADFS にリダイレクトされてから、Sharepoint にリダイレクトされます。問題は、sharepoint がエラー メッセージを表示することです。SharePoint からログ レコードを追加しています。

ログイン プロバイダーで認証されます。リクエスト セキュリティ トークンを検証しています。

信頼されたログイン プロバイダー 'SAML2 プロバイダー' は、構成された入力 ID クレーム タイプ 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress' を送信していません

SPSecurityTokenService.Issue() が失敗しました: System.ServiceModel.FaultException: 信頼されたログイン プロバイダーは、このファームで受け入れられるトークンを提供しませんでした。
Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.SPRequestInfo.ValidateTrustedLoginRequest() で

アクセスが拒否されました: 認証が必要です。

Identity Server から ADFS に返されたトークンには emailaddress クレームが含まれていることがわかりましたが、ADFS から SP に返されたトークンには含まれていません。すべてのクレームに対してパススルーする電子メール アドレスをサポートするように ADFS を構成しているため (ID サーバーのクレーム プロバイダー信頼で)、これは奇妙です。別の場所で adfs をセットアップする必要がありますか? 私はadfsの初心者です。

私が達成したいのは、ADFS を介して要求を IdentityProvider (この場合は ThinkTecture IdentityServer) に転送し、IdentityProvider からトークンを取得することです。ThinkTecture IdentityServer は、実際の環境の私のテスト環境にのみあり、Oracle Identity Federation に置き換えられます。

ターゲットの問題は、Sharepoint 2010 を Oracle Identity Federation と統合することです。しかし問題は、Sharepoint が、OIF が排他的なエンドポイント バインディングとして提供する SAML 2 プロトコルをサポートしていないことです。そのため、一方の側では SAML 1.1 に基づく Sharepoint と、もう一方の側では SAML 2 に基づく OIF と通信する ADFS (somethinkg のようなプロキシとして) でハッキングしようとしています。

これは、IdP メタデータからの次の抜粋です。

したがって、WS-Federation を使用するオプションはありません。

これが必要な動作を達成するための良い方法であるかどうか、アドバイスをいただければ幸いです。

ありがとう