問題タブ [claims-based-identity]

Sharepoint2010をホストするサーバーがあります。SQLServer2008R2をホストする別のサーバーがあります。SharePointはKerberos/クレームベースです。

SharePointに、標準の接続文字列（）を使用してSQLServerマシンに接続するカスタムメイドのWebパーツをインストールしましたData Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;。

問題は、WebパーツがSQLサーバーに接続しようとすると、次のメッセージが表示されることです。

私たちがやったこと：

• すべてのspn/delegation/trustsを確認します-すべて問題ないようです。
• SharePointマシンからUDLファイルを介してSQLサーバーに直接接続しようとしましたが、機能します。
• コードが機能することになっていることを証明するために、単一のマシンサーバー上でスタンドアロンのASPXページとしてWebパーツを試してみましたが、機能します。
• Wireshark-> ANONYMUS LOGONがSQLサーバーに接続しようとすると（明らかに）、KDC_ERR_S_PRINCIPAL_UNKNOWNが表示されます。
• SharePoint Developer Dashboardには、ANONYMUSではない現在のユーザー名が表示されます。
• Webパーツのトレースは、2つのことを示しています。HTTPCONTEXTが現在のユーザーに設定されているため、Thread.Currentも設定されています。
• SQLプロファイラーを使用すると、リクエストがANONYMUSからのものであることがわかります。
• 別のカスタムメイドのWebパーツから別のサーバー上のWebサービスにアクセスしようとしましたが、同じ理由で失敗しました（ANONYMUS）。

何が欠けていますか？問題は、SharePointが現在のユーザー資格情報を別のサーバー（SQLかどうか）に送信できないことであるように思われます。

ここでクレームウォークスルーを使用してカスタムSTSを作成しました：http：//msdn.microsoft.com/en-us/library/ff955607.aspx。

これを本番環境にリリースできるように、今は別の証明書を使用したいと思いますが、これをどのように行うかがわかりません。

• どこかから署名付き証明書を購入する必要がありますか？
• どのような種類の証明書が必要ですか？

どんな助けでも大歓迎です。

私はAzureACSを使用しており、SAML2.0応答などから電子メールと名前を取得するために離れた場所を探していました。

しかし、そのオプションは表示されません。ユーザーをlocalhost：8000 / acc /completesigninup/にリダイレクトします。

FormCollectionオブジェクトからのXMLがあり、xmlにEメールと名前が表示されていますが、取得方法がわかりません。その情報を取得するためにIdentitydllに含まれているパーサーはありますか？

ユーザーが既存の Web サイトから SharePoint にサインインできるようにするカスタム クレーム プロバイダーを作成しました。これにより、username@domain 形式の UPN のクレームを含むクレームが発行されます。ユーザーは、SharePoint Web アプリケーション web.config で有効mapToWindowsにしてuseWindowsTokenService下に移動するまで、問題なくログインできます。samlSecurityTokenRequirementこの時点で、標準の SharePoint エラー メッセージが表示され、次の例外がトレースに表示されます。

渡された UPN クレームによって表される AD アカウントを無効にすると、そのユーザーとしてログインしようとすると、SharePoint に別の「アクセスが拒否されました」というエラーが表示されるため、c2wts 偽装部分は正しく機能していると思います。

また、SharePoint ログには、UPN が Windows AD アカウントに変換されたように見えます。これは、ログに次の情報が記録されているためです。

アップデート

これは、SharePoint 内での使用がサポートされていない設定のようです。ただし、設定をオフのままにしておくと、SharePoint サイトに埋め込まれた Performance Point および Excel Services のレポートが正しく機能しないようです。次のようなエラーが表示されます。

• The data connection uses Windows Authentication and user credentials could not be delegated.(エクセル)
• $Resources:ppsma.ServerCommon, ErrorCode_DataSourceCannotGetWindowsIdentityForNonWindowsClaim;(パフォーマンス ポイント SSRS レポート)

これを回避する方法はありますか？ユーザーの UPN が、これらの背後にある SSAS データのクエリに使用されるアカウントである必要があるため、固定の接続文字列を使用することは現実的ではありません。

Azure AccessControl Service 2.0 から要求認証を受け取った後、(ローカル データベースから読み込まれた) カスタム ユーザー情報をマップするための ASP.NET MVC3 インフラストラクチャの最適な拡張ポイントはどこかを把握しようとしています。

Microsoft.IdentityModel.Claims.ClaimsAuthenticationManager クラスの Authenticate メソッドをオーバーライドして、これを実現しようとしました。

ただし、このメソッドは、ページの読み込みリクエスト中に複数回呼び出されているようです。ここでカスタム ユーザー情報を読み込むと、パフォーマンスの問題が発生する可能性があります。認証されたセッションごとに一度だけロードしたいと思います。

それを行うためのより良い場所はありますか？おそらく、IClaimsPrincipal が構築されている下位レベルのどこかでしょうか?

Windows Azure クラウドに移行したい既存の Web アプリケーションは、(post)authenticaterequest イベントのどこかで次の方法でユーザーを認証します。

CreateGenericPrincipal メソッドは、xml ファイルで claimidentity のロールを検索し、そのロールを使用して新しい GenericPrincipal を作成します。認証が必要なページは実行するだけです

通常の IIS ホスティングと大きな違いはないため、これは 1 つの Webrole インスタンスで問題なく機能します。しかし、2 つ、3 つ、または 5 つのインスタンスで動作しますか? Azure ロードバランサーは「スティッキー」ではなく、アプリケーションの使用中にユーザーが別のインスタンスに転送される可能性があります。Thread.CurrentPrincipal がまだ道のりであるかどうかはわかりません。

ここではクレームベース ID を使用します。ユーザーが初めてページにアクセスすると、セキュリティ トークン サービスに転送されます。今まで、これは 1 回だけです。複数のインスタンスを使用しているときにそれが数回発生すると面倒です..

ありがとう！

Sharepointのサイトにクレームを追加する小さなコードを作成しました。私はそのように進みます：

とても簡単ですが、私が作成したリストにクレームを追加したいと思います。今では、SPSiteとSPWebを使用してサイトにアクセスしていますが、さらに深く掘り下げる必要があります:)そしてその方法が見つかりません...

前もって感謝します！

以下は WSO2 IS を使用して可能ですか? 私はさまざまな WSO2 ブログを見てきました。彼らは素晴らしいポインターです。それでも私はこれについてアドバイスする必要があります。

要件 - WSO2 Identity Server + Rest STS Client (ESB なし)

1. ユーザーは WSO2 Identity Server で管理されます。
2. STS クライアントは、RestFul API を使用して、a) セキュリティ トークンの取得、b) トークンの検証、c) 発行済みトークンのキャンセル、d) 発行済みトークンの更新のための WSO2 Identity Server の STS サービスを呼び出します。
3. 特定のセキュリティ トークンを使用してユーザー プロファイルを取得します。

参照：

• https://web.cci.emory.edu/confluence/display/EmorySTS/Security+Token+Service+Client+API
  
• http://blog.facilelogin.com/2011/07/integrating-3-legged-oauth-with-xacml.html
  
• http://blog.facilelogin.com/2010/05/managing-users-and-roles-with-wso2.html
  
• http://blog.facilelogin.com/2009/05/security-token-service-with-wso2.html
  
• http://blog.facilelogin.com/2009/05/accessing-proxy-services-in-wso2-esb.html
  
• http://download.forgerock.org/downloads/openam/javadocs/9/com/sun/identity/wss/sts/TrustAuthorityClient.html

私は決してSharePointの専門家ではなく、これに関する適切な情報を見つけるのに非常に苦労しています。助けてください！

現在のユーザーをログアウトせずSPFederationAuthenticationModule.SetPrincipalAndWriteSessionTokenに、トークンのクレームを再計算するための呼び出しで確立されたクレームトークンを発生させる方法が必要です。これを行う方法はありますか？

私がこれを求めている理由のいくつかの背景：

カスタムSharePoint2010WebアプリケーションのauthN/Zにカスタムの役割とメンバーシッププロバイダーを使用します。（複雑な）理由の詳細に立ち入ることなく、ロールプロバイダーは、メインアプリデータベース内のユーザーの状態に基づいて、動的に生成されたユーザーのロール名を作成します。これらの役割はユーザーのアクセス許可を表し、SharePoint内で、アプリ内のサイトおよびサイトコレクションへのユーザーのアクセスを決定するために使用されます。

アプリ内には、ユーザーが権限を変更し、役割プロバイダーを介して新しい役割を効果的に追加し、アプリ内でユーザーに追加のアクセスを許可する方法があります。私たちが直面している問題は、SP2010で使用するように強制されているクレームベースの認証がログイン時にアクセス許可を事前計算し、それらのアクセス許可をセッショントークンにエンコードすることです-事実上、ユーザーにログアウトして再度ログインするように要求する必要があります新しい権限を取得できます。これはあらゆる種類のユーザビリティの問題を引き起こしているので、私の質問です。

ユーザーをログアウトせずにプログラムでセッショントークンを再計算する方法はありますか？

それとも間違った木を吠えていますか？私の通常の幸せなASP.NETランドでは、ログイン時ではなくすべての要求で認証を計算するFormsAuthを使用します。残念ながら、これはSP2010のオプションではないようで、現時点ではSharePointに固執しています。私たちが追求できる他の行動はありますか？

現在、ユーザーを認証するために独自のSTS（Microsoft WIF）を実装することを検討しています。その過程で、答えることができなかったいくつかの質問が出てきました。

さまざまな種類のアプリケーションを使用して、さまざまな種類のユーザーがいます。各種類のユーザーには、その種類のユーザーと所属するアプリケーションにのみ関連する特別な種類のクレームが必要です。すべてのクライアントを管理しているわけではないことに注意してください。

すべてのユーザーが、ユーザー名とパスワード（.NET MVC3）を使用した単純なhttpsを使用して認証されているとします。ユーザーは、そのタイプ、ユーザー名、およびパスワード（ユーザー名とパスワードだけではない）によって一意に識別されます。したがって、ユーザータイプを区別できるように、ユーザータイプごとにエンドポイントを作成する必要があります。ユーザーが承認すると、ユーザータイプを表すクレームを含むトークンを発行します。これを行うためのより簡単な方法はありますか？ユーザータイプごとにエンドポイントを回避できますか（現在は3つあります）？

次に、私のトークンサービスは、許可されたユーザーのトークンを調べてクレームを変換し、すべてのユーザーのタイプ固有のクレームを含むトークンを発行できます。私が思う複数のエンドポイントを除いて、これまでのところ良いですか？

複数のエンドポイントが必要な場合、エンドポイントごとに1つずつ、異なるメタデータドキュメントも公開する必要がありますか？すべてのクレームの説明を含む1つの大きなメタデータドキュメントがあると、すべてのクレームを必要とするアプリケーションがないため、意味がありません。

アップデート

いくつかの説明。

特定のアプリケーションは、特定のタイプのユーザーのみが使用します。1つのアプリケーションを複数のユーザータイプで使用することはできません。

リクエストの送信元のアプリケーションの種類に応じて、そのユーザーの種類についてユーザー名とパスワードを比較する必要があります。アプリケーションの種類ごとにユーザーストアがあります。そのため、リクエストの送信元のアプリケーションの種類を知る必要があります。ユーザー名とパスワードだけではタイプを解決できません。