.net n 层身份识别服务架构中的授权 [英] .net n-tier identity & authorization in service architecture

查看:22
本文介绍了.net n 层身份识别服务架构中的授权的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在构建一个应用程序,其中要求似乎是标准问题(至少对我而言)......我有一个基于 asp .net mvc & 的 Web.UI来自 iphone、andriod 的客户黑莓.

所以明智的做法是将我所有的业务逻辑移动到一个可以通过 http 访问的服务层中.该服务层必须接受具有用户上下文(身份)的请求,并且无论哪种类型的客户端与其进行通信(我希望?),都必须以某种很好的方式一致地执行授权.

一年多来,我做了一个 3 个月的演出,聘请了 W.I.F.(Windows Identity Foundation) 在混合本地 &云架构.我喜欢它.引起共鸣的 3 件事是 (1) 外部化身份验证而不关心它是如何完成的,(2) 从业务逻辑中删除授权逻辑,(3) 基于声明的授权.

在过去的一年里,我听说并看到了关于 Rest Services 的新酷嬉皮士做事方式".所以我虽然很棒,让我们试试吧.在我开始玩&之后开始编码,我开始变得非常困惑(然后昨天读了大约 10 个小时,而没有写另一行 c#).我仍然对所有 SOAP 与 REST、WS.* 与 Http、SAML 与 SWT 的胡言乱语感到困惑.我真的不希望这个帖子是关于那个的,因为在 stackoverflow 上有足够多的发言,但我觉得我可以在两个阵营之间做出选择,而我并不真正想要一个或另一个但每个人的位?

对我来说,我上面提到的关于 WIF 的 3 点似乎不是应该与 WS.* 相关联的概念?但我觉得他们,或者至少 WIF 目前是如何产生的,没有一些专家的调整(例如,我在几天前才看到这篇文章 - http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/).

我不太了解的其他领域是我的客户端(iphone、andriod、blackberry)能够使用 WIF,它是否与向他们抛出 SAML 令牌的 STS 相同,并且它们的行为就像浏览器和像任何其他客户端一样将其传递回标头?是的,我将不得不找出来,但如果这是与 W.I.F 的交易破坏者并且我在发布此消息后立即发现,那么至少我可以专注于它.

最后再加入一件事.我真的不想去想这些.我想使用第 3 方身份验证/身份提供商 - http://www.janrain.com/products/engage - 我相信它使用 OpenID.这能融入 W.I.F.还是我只是从 OpenID 创建一个新的 SAML 令牌并从那时起使用 WIF.

我想在这个胡言乱语结束时,我想回到我开始的地方,因为我问的问题越多,我考虑的选项就越多,它变得越来越复杂.

有一个服务层(在 WCF 上)与需要身份上下文和授权的不同非 .net 客户端进行对话是否如此奇怪?如果你已经构建了这样的东西,你是如何处理它的?

解决方案

当您有许多设备时,让相同的解决方案适用于所有设备的一种方法是针对最小公分母.

假设您的所有客户端都支持 cookie.这样做的一种方法是:

  • 拥有基于 cookie 的身份验证系统.
  • 在服务器端缓存所有授权信息,链接到 cookie 中的会话或密钥
  • 对于每个请求检查授权

不像使用 SAML 令牌那么优雅,但它确实可以跨平台/设备工作.

iPhone 支持 cookie http://support.apple.com/kb/HT1675>

Blackberry 支持 cookie http://docs.blackberry.com/en/developers/deliverables/11844/feature_cookie_storage_438273_11.jsp

I'm building an application where the requirements seem standard issue (at least to me)... I have a Web.UI based on asp .net mvc & clients from iphone, andriod & blackberry.

So the sensible thing to do is to move all my business logic into a services layer that can be accesses over http. This services layer must accept requests with a user context (identity) and in some nice way perform authorization consistently no matter which type of client is communicating with it (I hope?).

Over a year a go I did a 3 month gig that employed W.I.F. (Windows Identity Foundation) in a hybrid on-premises & cloud architecture. I liked it. The 3 things that struck a chord were (1) externalizing authentication and not caring how it was done, (2) removing authorization logic from business logic, (3) Claims based authorization.

Over the last year I've heard and watch all about Rest Services the 'new cool hippy way of doing things'. So I though great, let's try that. After I started to play around & get coding, I started getting really confused (and subsequently read for about 10 hours yesterday without writing another line of c#). I'm still confused about all the SOAP vs REST, WS.* vs Http, SAML vs SWT babble. I don't really want this thread to be about that because there is enough of that speak on stackoverflow, but I feel like I've got a choice between two camps, when it doesn't really feel like I want one or the other but bits from each?

To me the 3 points I mentioned above about WIF don't seem like concepts that should be tied to WS.* ? But I'm getting the feeling that they, or at least how WIF comes at the moment makes them, without some expert tweaking (e.g. I came across this post only written a few days ago - http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/).

The other areas I don't know much about is are my clients (iphone, andriod, blackberry) capable of playing with WIF, is it the same STS that throws a SAML token to them and they behave just like a browser and pass it back in a header just like any other client? Yes I'm going to have to find out, but if this is a deal breaker with W.I.F and I find out straight after posting this, then at least I can focus away from it.

Finally to throw one more thing in the mix. I don't really want to think about any of this. I want to use a 3rd party authentication / identity provider - http://www.janrain.com/products/engage - which I believe uses OpenID. Can this fit into W.I.F. or do I just create a new SAML token from the OpenID and use WIF from that moment on.

I guess at the end of this babble, I want to come back to where I started because it's getting more and more complicated the more questions I ask and the more options I consider.

Is having a services layer (on WCF) that talks to different non-.net clients that requires identity context and authorization so strange? If you've build something like this, how did you approach it?

解决方案

When you have many devices, one way to get the same solution working across all of them, is to target the lowest common denominator.

Assuming that all your clients support cookies. One way of doing this would:

  • Have an authentication system based on a cookie.
  • Cache all authorisation information on the server side, linked to a session or key in the cookie
  • For each request check the authorization

Not quite as elegant as using SAML tokens, but it does work cross platform / devices.

IPhone supports cookies http://support.apple.com/kb/HT1675

Blackberry supports cookies http://docs.blackberry.com/en/developers/deliverables/11844/feature_cookie_storage_438273_11.jsp

这篇关于.net n 层身份识别服务架构中的授权的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆