5

認証、承認を管理し、呼び出し元に accessToken を割り当てる dotnetopenauth を使用して OAuth2.0 承認サーバーを構築しました。呼び出し元は、アクセス トークンを使用して、リソース サーバーで API (Web サービス) にアクセスします。Resource Server の dotnetopenauth が提供するサンプルに従うと、WCF を使用してビルドされた api はOAuthAuthorizationManagerによって認証されます。

ServiceStack を使用して Resource Server で API を構築する場合、割り当てられた OAuth2.0 アクセス トークンに基づいて着信 API 要求を検証する認証プロセスを構築する方法を教えてください。機能は dotnetopenid サンプルの OAuthAuthorizationManager と同様であり、ログイン セッションに基づいていません。

4

1 に答える 1

4

ちょっとだけ更新

AuthenticateAttributeまたはRequiredRoleAttributeを使用しませんでしたServiceStack.ServiceInterface。

とRequestFilterAttributeが提供する機能を置き換えるために、2 つのカスタムを作成します。AuthenticateAttributeRequiredRoleAttribute

各 customRequestFilterAttributeのExecuteメソッドでは、dotnetopenauth のメソッドを使用してアクセス トークンを検証しています。

//httpReq==req from Execute(IHttpRequest req, IHttpResponse res, object requestDto)

アクセス トークン検証のコードは次のとおりです。詳細については、servicestack と dotnetopenauth の両方の関連ドキュメントを参照してください。ResourceServer は dotnetopenauth のクラスです

HttpRequestBase reqBase = new HttpRequestWrapper((System.Web.HttpRequest)httpReq.OriginalRequest);

var resourceServer = new ResourceServer(new StandardAccessTokenAnalyzer(AuthorizationServerPublicKey, ResourceServerPrivateKey));

IPrincipal ip = null;
resourceServer.VerifyAccess(reqBase, out ip);

ipがnull認証されない場合、そうでない場合null、着信要求は有効であり、 を使用しipて役割を確認できます。ip.IsInRole(requiredRole)

これがチェックを行う正しい方法かどうかはわかりませんが、私にとってはうまくいきます。より良い解決策は大歓迎です。

于 2012-06-01T17:05:07.887 に答える