0

Sharepoint で認証モデルをいくつか作成しました。私はあなたから知りたいのですが、それは良いアプローチです。

バージョン 2.0 で POST SAML トークンを送信する IDP がありますが、RP アプリケーションはそのバージョンではなく v1.1 で SAML をサポートしていません。

私はこのようなモデルのために作成しました:

  1. IDP は SAML 2.0 を SAMLHandler.aspx ページに送信します

  2. SAMLHandler.aspx は、SAML 2.0 (署名) のトークンを検証し、そこからクレームのコレクションを取得します

  3. 一連のクレームに基づいて、Sharepoint でサポートされている v1.1 で SAML トークンを作成します。このトークンは、パスワード付きの証明書によって署名されます (この証明書は、Sharepoint 管理トラスト ストアに追加されます)。

  4. この SAML トークン v1.1 は WIF メッセージにパックされ、Sharepoint に送信されます。Sharepoint はクレームを認識し、最終的にユーザーが認証されます。よろしいですか?

4

2 に答える 2

0

Security Token Service を見ることができます。あるセキュリティ トークンを別のセキュリティ トークンと交換するために使用できます。あなたの場合、SAML 2.0 トークンを SAML 1.1 トークンと交換する必要があります。Security Token Service は、トークンの検証とトークンの署名もサポートしています。

于 2013-03-10T02:50:28.173 に答える
0

SAMLHandler.aspx の代わりに ACS (Azure コントロール サービス) のようなソリューションを使用できます。その結果、複数の IDP を処理し、シングル サインオンを作成することができます。

基本的にあなたのソリューションはよく見えますが、既存のものを再反転しています。

于 2013-03-09T16:52:01.543 に答える