服务体系结构中的.net n层身份和授权

Question

我正在构建一个应用程序，其中的需求似乎是标准问题(至少对我来说是这样)……我有一个基于asp .net mvc的Web.UI和来自iphone，andriod和黑莓的客户端。

因此，明智的做法是将我的所有业务逻辑移动到一个可以通过http访问的服务层。此服务层必须接受具有用户上下文(标识)的请求，并以某种良好的方式一致地执行授权，而不管与其通信的是哪种类型的客户端(我希望是？)。

在一年多的时间里，我做了一个为期3个月的工作，在一个混合的内部和云架构中使用W.I.F. (Windows Identity Foundation)。我很喜欢。引起共鸣的3件事是(1)外部化身份验证并不关心它是如何完成的，(2)从业务逻辑中删除授权逻辑，(3)基于声明的授权。

在过去的一年里，我听过和看过所有关于Rest服务的东西，这是一种“新的、酷的、时髦的做事方式”。所以我觉得很棒，让我们试一试。在我开始胡乱编写代码后，我开始变得非常困惑(随后我昨天读了大约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，是不是同样的STS抛出一个SAML令牌给它们，它们的行为就像浏览器一样，并像其他客户端一样在头部中传递它？是的，我将不得不找出答案，但如果这是与W.I.F的交易破裂，而我在发布这篇文章后立即发现，那么至少我可以专注于它。

最后，让我们再多加一件东西。我真的不想去想这些。我想使用第三方身份验证/身份提供商- http://www.janrain.com/products/engage -我相信它使用OpenID。这是否适合W.I.F.，或者我只是从OpenID创建一个新的SAML令牌，并从那一刻开始使用WIF。

我想在这次谈话的最后，我想回到我开始的地方，因为我问的问题越多，考虑的选择越多，事情就变得越来越复杂。

有一个服务层(在WCF上)与不同的需要身份、上下文和授权的非.Net客户端对话，这有什么奇怪的吗？如果你已经构建了这样的东西，你是如何实现它的？

Answer 1

当您有许多设备时，让相同的解决方案在所有设备上运行的一种方法是以最小的公分母为目标。

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

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

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

IPhone支持cookies http://support.apple.com/kb/HT1675

黑莓支持cookies http://docs.blackberry.com/en/developers/deliverables/11844/feature_cookie_storage_438273_11.jsp

Answer 2

我将尝试更抽象地回答您的问题……

在我开始之前，我的背景是MS偏向，所以可能有相同的(或更好的)其他来源的选择。

我发现有两个非常有用的参考资料：

1)基于声明的身份和访问控制指南

http://msdn.microsoft.com/en-us/library/ff423674.aspx

2) Windows Identity Foundation编程

作者: Vittorio Bertocci提供kindle格式的硬拷贝

还有很多其他来源，但这两个涵盖了几个场景，并为任何想要快速了解您的起点的人提供了很好的背景信息。

我鼓励其他帖子来填补任何空白或错误:)我正在粉饰一系列技术细节，以专注于所提出的问题。

我分解联邦身份的方式大致如下：

1. Application(s) App(s)
2. Authentication服务Trust(s)
3. Transport方法Transport(s)

• 声明集声明

• 信任关系

STS负责验证用户的身份，并为某些声明提供担保。它通过提供(1)包含声明的签名blob或(2)第三方可以用来查找声明的唯一标识符来实现这一点。

想要为用户提供服务的应用程序可以“信任”STS来为它提供声明，它可以用来适当地与用户一起工作，从而免除它验证用户的责任(在其他事情中，例如维护集中的元数据，但我离题了)。

STS还可以“信任”另一个STS，基本上就是说：“如果你说这个人是Joe Smith，他们有X、Y和Z角色，那么我可以担保你所说的话！”

因此，套用一下：

应用程序“信任”一个STS {它又可以“信任”另一个STS }来提供它/他们的声明

**切换齿轮**

SOAP与REST

归根结底，SOAP和REST都是服务类型，让我们称它们为声明消费者。他们都希望有人给他们一桶索赔，这样他们就可以做自己的工作，并寄回一些东西。此外，这两种服务类型都可以通过使用令牌的查询字符串(假设服务可以处理一些url重写)或通过标头(HTTP用于REST，SOAP用于SOAP服务)提供声明。无论哪种方式，目标都是相同的:将声明或UID传输到应用程序。

WS* vs HTTP

这些(连同TCP/IP、SSL、秘密解码器环等)是来回传递信息的方法，尽管在不同程度上确定中间的人找不到模仿用户的方法。

SAML vs SWT

这些(连同base64编码、xml、简单文本等)都是序列化权利要求的方法。这两个只是碰巧符合其他人没有的标准，所以每个人都可以说同一种语言。

**回到正题**

这些技术组合中的每一种都是有效的(根据应用程序的不同，一些技术组合不太安全，其他技术组合更容易实现，其他技术组合在低级设备上工作得更好，等等)，只是一个人的工作方式与另一个人的方式。

因此，如果我有一个.Net应用程序，该应用程序已经通过WS*管道以SAML格式提供了一组声明，那么最终结果是该应用程序具有SAML格式的声明。

通过一些处理，这些可以转换为SWT中的声明。

然后，可以将新声明打包并通过HTTP/SSL发送到Java应用程序。

如果Java应用程序“信任”相同的STS (或者“信任”.Net应用程序STS的STS)，那么它就打开声明并执行它的工作。

• 你提到的专家调整是必须发生的，问题很简单，就是它是由谁来进行的，以及它有多透明

1. Dave provides a perfectly valid example of one way to accomplish the tweaking with custom code.
2. ADFS provides translation rules that try to accomplish merging and translation via configuration.

​

• 在完全不同的平台/设备/应用程序等上提供服务的想法并不奇怪，所有这些东西都是为了解决

而构建的

我正在尝试构建像你所问的那样的东西，所以我自己也在做同样的事情。

您提到的Engage服务允许您将应用程序的用户与外部来源相关联，并可用于对这些用户进行身份验证...ala“我看到你在谷歌认证为John@gmail.com，我知道你是id为4321的John Walker，哦，看，你在谷歌把你最喜欢的颜色设置改成了蓝色...继续！”

它不做的是提供特定于应用程序的对应用程序的声明(除非您需要知道的所有内容都来自google数据，在这种情况下，您很可能是在构建mash up而不是LOB应用程序……

另一种情况是：

1. 用户转到您的application
2. Is重定向到您的STS
3. 重定向到您的STS
4. 返回到您的STS
5. 电子邮件并添加最喜欢的颜色声明(根据谷歌)

<代码>H133角色列表和购买限制声明已添加(从您的应用程序特定的datastore)

1. User返回到application
2. User尝试购买$10,000紫色小部件，并且您说：“好吧，您只能通过信用卡购买$5,000，而且...您确定要紫色我听说您更喜欢蓝色吗？”<代码>H238<代码>G239

我想带你去的另一个地方是微软提供的AppFabric访问控制服务。(http://msdn.microsoft.com/en-us/library/ee732536.aspx)免责声明:我还没有使用它，但是，看起来它做了你正在寻找的翻译类型，并为你隐藏了很多肉。

Answer 3

当WIF在幕后讨论WS-Trust / WS-Federation时，您可以在服务层公开基于声明的身份验证。

本文展示了如何创建一个WCF STS，它将使用这些协议与外部客户端进行通信。http://msdn.microsoft.com/en-us/library/ee748498.aspx

从服务层的授权角度来看，您可以使用自定义授权管理器来检查是否已提交声明。http://msdn.microsoft.com/en-us/library/ms731774.aspx

要插入外部身份服务，如OpenID，并将您自己的声明添加到由WIF生成的那些服务中，那么您可以从ClaimsAuthenticationManager中创建一个子类，如下所示：

public class MyClaimsAuthenticationManager : ClaimsAuthenticationManager {

    public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal)
    {
        if (!incomingPrincipal.Identity.IsAuthenticated)
        {
            return incomingPrincipal;
        }

        //TODO: obtain user profile claims from external source, i.e. database, web service            
        // below code demonstrates how to custom claims to the current principal 
        // (which are then persisted for the lifecycle of the user's browser session)            

        IClaimsIdentity identity = (IClaimsIdentity)incomingPrincipal.Identity;

        identity.Claims.Add(new Claim(ClaimTypes.Email, "dave@dave.com"));

        return incomingPrincipal;
    }
}

​

您需要通过设置claimsAuthenticationManager配置参数来告诉WIF在Web.config文件中使用您自己的索赔管理器。

希望这能有所帮助。