我正在开发适用于以下客户端/服务器方案的安全设置,我有几个问题/注意事项,我想与您分享。
情况: 我在不同平台上有许多客户:
大多数相应的服务器组件都基于使用REST的.NET WCF(但对于某些后端,我正在使用其他协议)。
我发现开源项目IdentityServer v2 from ThinkTecture对我的解决方案来说是一个很好且灵活的安全令牌服务(STS)。它支持许多令牌类型,协议并且具有高度可扩展性,并且如果需要,还具有基于ASP.NET成员资格数据库的自包含身份提供程序(IdP)。
使用用户名/密码的客户端的基本流程如下:
我知道步骤#2在将HTTP 401错误消息与通常与HTTP 3xx状态代码相关联的HTTP Location标头组合时有点不正统。我需要401状态代码,因为我的jQuery / AJAX客户端自动处理302重定向消息,没有任何机会可以重新定位重定向。
现在,系统需要使用外部IdP。 “内部”STS被定制为将身份验证请求转发到外部IdP处理从外部IdP格式到内部格式的声明转换。其中一个问题就是它暗示了“密码反模式”,但目前所有系统都是内部和值得信赖的。
WS Federation可以成为我的朋友吗?
以上基本流程适用于所有客户端,基于浏览器或不基于浏览器。但对于特定的浏览器客户端,我一直在研究联合安全方案,让最终的IdP / STS为客户端提供登录机制。我使用的STS(IdentityServer)可以配置为与符合WS-Federation的STS一起使用。因此,令牌被自动转移到目标令牌格式(在我的情况下,例如从外部STS的SAML令牌转移到内部JWT令牌)。 有了这个,我可以有某种SSO机制。
现在我的问题:
答案 0 :(得分:2)
我不认为你描述的是WS-Fed。 WS-Fed从不涉及401,也从不涉及身份验证标题。
WS-Fed有两个版本,被动和主动。
Passive适用于浏览器。它由302提供给身份提供者,身份提供者又将SAML令牌发送回呼叫者。然后,cookie支持验证。
Active适用于活动客户端(应用程序)。它包含一个SOAP响应,指示调用者转到令牌的身份提供者。来自身份提供者的SOAP响应包含一个令牌,然后将该令牌提供给服务。
我认为如果您的客户端不支持WCF联合身份验证绑定(wsTrustFeb2005),则活动方案非常复杂。你必须自己实现这个流程。
我想建议的是OAuth2流程。 OAuth2有4个不同的流,其中两个对应于WS-Federation的主动和被动:授权代码流用于基于浏览器的应用程序,隐式流程用于桌面/移动应用程序。
http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#authorization
OAuth2可以轻松地与WebAPI服务集成,并且在DotnetOpenAuth库中对它提供了很好的支持。
此Pro和其他身份验证/授权选项在Pro ASP.NET WebAPI安全手册
中有详细介绍http://www.amazon.com/Pro-ASP-NET-Web-API-Security/dp/1430257822
即使你不打算围绕WebAPI构建你的后端(而是你提到的RESTful WCF),本书将为你提供有关OAuth2的必要背景知识。
另一方面,如果您仍然坚持使用WS-Federation,这个免费的电子书将描述主动和被动场景: