我还没有完全掌握ADFS 2.0 / 3.0的依赖方令牌签名证书的功能.一旦发生自动自签名证书翻转(默认情况下),在某些情况下您必须手动将新的令牌签名证书交付给(通常)外部SSO应用程序提供商,以便他们将新证书放置在他们的结束,所以SSO将继续运作.
但是,这可以自动发生.我发现它在这里解释得最好：
AD FS and self-signed Token-Signing certificates | Kloud Blog
[ADFS] … can automatically renew self-signed certificates before expiry,and if a relying party trust is configured for automatic federation Metadata updates,automatically provide the new public key to the relying party. This automation makes for a resilient,low maintenance federation service in that a key certificate used by the service does not require periodic attention.
问题是;我如何知道是否为自动联合元数据更新配置了依赖方信任？这是简单的,只是信任的这个设置(感谢谷歌图像搜索)：
如果是这样,我如何确保更新成功(除了可能是’上次检查’日期)并且依赖方已自动获得新证书或其公钥？
SAML2和WS-federation信任中有多个证书.我将在这里忽略服务器的https url的TLS证书(ADFS将其称为通信证书). 每一方都可以拥有签名证书.该方发送的消息使用该证书的私钥进行签名. SAML2方经常签署请求和响应. WS-Federation被动不对请求进行签名(因此被动RP没有签名).签名证书将在元数据中发布.在翻车期间,可以有两个(旧的和新的). 每方都可以拥有加密证书.当请求或响应被发送到具有加密证书的一方时,则该证书的公钥可用于加密加密密钥.使除目标之外的所有人都无法读取该消息.加密证书发布在元数据中.大多数情况下,元数据中只发布一个加密证书.但是旧证书被接受了一段时间才能实现无缝翻转. ADFS的自动翻转很酷.我建议您保留这种方式或用自签名证书替换它,有效期为10年.如果ADFS具有其元数据的URL,ADFS将遵循其合作伙伴发布的元数据. WS-Fed领域的依赖方阅读Microsoft .NET(也称为WIF)应用程序.这取决于应用程序.应用程序可以发布他们的元数据,这对于ADFS管理员来说很好,因为他们不需要输入很多,减少带外错误通信等.每个人都是双赢的.因此每个应用程序都应发布其元数据对每个人都更好.但对于被动的WS-Fed依赖方,则不会有签名证书.可能有加密证书. .NET具有在System.IdentityModel.Metadata中读取和生成元数据“per-request”的类.互联网上有几个样本.其中一个例子是Thinktecture IdentityServer. 依赖方可以读取ADFS元数据.总是有一个预定的任务可用.它确实读取了ADFS元数据,然后更新了应用程序的web.config文件.我从来没有使用它,因为它有池循环的副作用(即使没有变化),它确实破坏了旧版web.config的目录.如果您在编写阅读器或编写器时遇到问题,请离线联系我.它可以为任何应用程序(也适用于SharePoint)完成.这是一个成本问题,手动(每年一次)或编写代码自动完成.
原文链接：https://www.f2er.com/javaschema/281736.html