2

私はこのようなことをしようとしています:

  1. MVC4 Web アプリと Web-API サービスがあります (Azure の 2 つの別々のロールでホストされています)
  2. 別のロールが CustomSTS1 を実行します。
  3. MVC Web アプリは CustomSTS1 を信頼します
  4. 顧客がサイトにログインすると、STS ログイン ページにリダイレクトされます。
  5. ログインすると、MVC Web サイトにリダイレクトされます。
  6. この Web サイトから、顧客がアクションを実行すると、Web API サービスが呼び出されます。

Web アプリに SAML トークンがあり、これを WebAPI サービスに渡します。

Web API 側で SAML トークンを検証しようとすると、

Message=ID1032: At least one 'audienceUri' must be specified in the SamlSecurityTokenRequirement when the AudienceUriMode is set to 'Always' or 'BearerKeyOnly'. Either add the valid URI values to the AudienceUris property of SamlSecurityTokenRequirement,  or turn off checking by specifying an AudienceUriMode of 'Never' on the SamlSecurityTokenRequirement.

これには、CustomSTS1 を信頼する Web API サービスがありません

信頼を設定すると、Web API サービスに対して HTTP Get 要求を実行しようとすると、常に HTTP 401: UNAUTHORIZED が返されます。

さて、私の質問は、（私の現在のアプローチが間違いなく間違っていることを知っています）

  1. WebAPI サービスが MVC サイトにログインしたユーザーに代わって ActAS を実行できるように、CustomSTS1 との信頼関係をセットアップするにはどうすればよいですか?

また

  1. このアーキテクチャは間違っていますか?
  2. そして、これを達成する別の方法はありますか?
4

1 に答える 1

1

そのアプローチは概念的に間違っています。MVC アプリケーションは、ActAs を使用して STS で Web API の新しいトークンをネゴシエートする必要があります。これが、SOAP サービスの伝統的な仕組みです。ただし、SAML はさまざまな WS-* 仕様に依存する複雑な形式であるため、Web API は SAML から離れつつあります。そのレベルで SSO をサポートしたい場合は、OAuth 2.0 がその領域の標準になりつつあります。

もう 1 つの方法は、MVC アプリと Web API の間に暗黙的な信頼を確立することです。そのため、MVC アプリから Web API へのすべての呼び出しは、基本認証などのより標準的な HTTP 認証メカニズムを介して行われます。 MVC アプリは知っています。MVC アプリにログインしているユーザーに関する情報は、追加情報として渡されます。

よろしく、パブロ。

于 2013-03-06T14:45:31.373 に答える