为每个授权方使用单独的客户端证书
本文关键字：客户端 证书 单独 方使用 授权 | 更新日期: 2023-09-27 18:10:23
我正在阅读SSO，并使用此教程http://chris.59north.com/post/2013/04/09/Building-a-simple-custom-STS-using-VS2012-ASPNET-MVC.aspx创建自定义STS。
如果我理解正确的话，在STS机器上安装了证书。授权方发送x509签名的指纹。因此，信赖方只会接受持有适当证书的化粪池系统的索偿。这是正确的吗?
如果是这样，我想实现每个依赖方都向STS发送一个证书，STS也安装了。应请求，STS在其信任的依赖方列表中查找发送的证书是否为STS所知。
这个实现是一个好主意吗?这是一个好的实践吗?是否有一个好的资源来实现这一点?
谢谢
实现自定义STS是一项艰巨的工作。我建议你从windows azure ACS或Thinktecture free STS入手。
话虽如此，为依赖方提供单独的证书是一种常见的做法。但是，该证书的私钥通常存储在STS中的某个数据库中(ACS和Thinktecture都支持这一点)。依赖方只知道公钥。然后由ac使用安全令牌对安全令牌(SAML2或JWT)进行签名，依赖方可以使用公钥(或拇指指纹)来验证签名。还请注意，SAML2令牌也可以加密(在签名旁边)，并且您可以为此使用不同的证书。我个人建议使用单独的证书，如果STS(或您的组织)有某种网站，"任何人"都可以注册他们的应用程序作为依赖方。如果您的所有运行方都是"内部"应用程序，我至少会考虑使用单个证书来签署所有安全令牌。这样做的好处是，您可以在联邦元数据文档(位于FederationMetadata/2007-06/FederationMetadata.xml)中发布(公共)密钥。如果您希望更新密钥，可以在那里更新它(首先在那里发布新旧密钥，然后只发布新密钥)。然后，依赖方可以基于此元数据更新密钥(adfs使用类似的方法)。所以底线是:每个RP都有一个单独的证书是好的，但是只有一个证书(用于签名-而不是加密)更容易更新。