1

次の当事者を考えると:

ブラウザベースのクライアント
ASP.NetMVC4WebアプリケーションASP.NetWebAPI
サービス
セキュリティトークンサービス(STS)、つまりThinktecture IdentityServer
(注:WebアプリケーションとWebAPIサービスは異なるボックスに存在します)

これと同様のフローを取得したいと思います。

ユーザーがWebAppに移動すると、アプリケーションはリクエストに有効なトークンを認識せず、STSで認証されるようにユーザーをリダイレクトします。ユーザーはSTSにログインし、認証が成功するとWebAppにリダイレクトされます。WebAppは有効なトークンを確認し、ユーザーにアクセスを許可します。ユーザーは、WebAPIへのサービス呼び出しを必要とするWebAppで操作を実行しようとします。WebAppは、サービスリクエストでユーザートークンを渡します。WebAPIサービスは、トークンを確認し、アクセスを許可せずにエラーを返すか、ユーザーに代わって要求を承認して結果を返します。

さらに、クライアントがAJAX呼び出しを介してWebAPIサービスに直接サービス呼び出しを行えるようにしたいと思います。

これまでのところ、フローをWebアプリケーションでSTSにリダイレクトして戻すことができますが、トークンをWebアプリからWeb APIサービスに渡すにはどうすればよいですか?

また、JavaScriptクライアントにAJAX呼び出しでトークンを渡すようにするにはどうすればよいですか?

4

2 に答える 2

1

SAML を使用している場合は、すぐに実行できます。

Web サイトのログインは SAML トークンを返し、saveBootstrapContext 機能は後で使用するためにトークンを保存し、それを Web API に転送できます。

Web API では、thinktecture identitymodel を使用して SAML を使用できます。AJAX 呼び出しの場合、JS から SAML トークンを取得し、それを認証ヘッダーで Web API に送信する方法を提供します。

これは最適ではありません。しかし、JWT を最後まで実行するには (これが望ましい方法です)、現在いくつかのビットが欠落しています (たとえば、IdSrv は対称署名のみを正しくサポートしており、私の JWT ハンドラーはブートストラップ コンテキスト、MS JWT ハンドラー、および対称署名をサポートしていません)。設定も問題です)。

私はこれに取り組んでいます。しかし、今のところ、このシナリオにはいくつかの荒削りな部分があります。

于 2013-02-22T06:24:08.493 に答える
0

両方のサービスが同じドメインにある場合は、Cookie を使用できます。

于 2013-02-24T17:34:46.253 に答える