为什么ADFS的SAML请求需要签名？
以下是发送给ADFS的SAML请求
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_84e533b7-4310-41de-8ec7-0af7afeb7979" Version="2.0" IssueInstant="2015-12-02T09:44:30Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Destination="https://XXXX.YYYY.ZZZZ/adfs/ls/" AssertionConsumerServiceURL="http://PPP.QQQ.RRR/SPDemo/Consume.aspx">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://XXXX.YYYY.ZZZZ/adfs/services/trust</saml:Issuer>
</samlp:AuthnRequest>
压缩并转换为Base64String后，它被重定向到ADFS。带有SAML请求的URL如下所示
https://XXXX.YYYY.ZZZZ/adfs/ls/?SAMLRequest=hZHNbsIwEIRfJfLdsfODAhZEouVQJKpGJO2hl8okS7Ga2KnXoTx+A0KLuncjrflmz3Bnkju6fcvohfqwjta561xc/IxjWESRbuExlHAaRxUQKdQJpTLfSL3sEtmyYx4b2BRGb0goc+JT0BSyk3rse36lx5mabbshz8jujyrpydejk1zpsmflc6uvpzqtqrhzgougjzaapxinz5vbg9o9gnihrzhr7cuvilfkiyot3wxswbwkwbwbwmaj/Qn/AO5N9R6Zqnx5tslkzwe2R1cIIT0qee+Yejcauzaudpaosxrebawaqe K3GTAJBA2PGUKC9W0BG20R7E9KS8U1NRFJCT3U/SjsVJOj+rxWVZ9oq/j8u/8CQdo/7XGYd2yJzt0M3Z1dR0eN3ePf0F
那么，为什么ADFS 2.0要求签名的SAML请求？
是否需要执行任何操作，以便不需要签署SAML请求，或者如果需要，将签署SAML请求的签名的值是多少？
共有1个答案
我能解决它。
问题是SAML请求中发行者设置错误。
设置适当的发行者后，即超文本传输协议：//PPP. QQQ. RRR/SPDemo，如以下SAML请求所示，我能够在没有任何ADFS错误的情况下进行SP启动的登录
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_bd613bda-e506-4747-91c7-96a4d75c67fc" Version="2.0" IssueInstant="2015-12-03T05:51:52Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Destination="https://XXXX.YYYY.ZZZZ/adfs/ls/" AssertionConsumerServiceURL="https://PPP.QQQ.RRR/SPDemo//Consume.aspx">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://PPP.QQQ.RRR/SPDemo</saml:Issuer>
</samlp:AuthnRequest>
以前使用的发卡机构错误http://XXXX.YYYY.ZZZZ/adfs/services/trust
-
我希望确认有效的已签名 SAML 注销请求是否需要 RelayState。 我们已经将微软的ADFS 2012 R2与甲骨文的身份联合会联合起来，其中ADFS是SP，OIF是IdP。作为基础，我们遵循将ADFS 2.0/3.0 SP与OIF IdP集成。 一切正常，除了注销。我们有另一个 SP 执行注销并与 OIF 合作。我们发现的一个区别是，ADFS 不会发送带有其签名注销请求的 RelaySt
-
在SSO场景中，我们使用ADFS 2.0作为IDP，使用Shibboleth作为SP。这是SP启动的登录。配置后，当我尝试在Shibboleth和ADFS 2.0之间建立通信（抛出浏览器重定向）时，ADFS 2.0抛出以下错误。 SAML消息签名验证失败。消息颁发者：<代码>http://sampleserver/adfs/services/trust异常详细信息：MSIS015:服务器需要签名的
-
> 。 有些帖子说x509是用来生成自签名证书的。 但使用时出错： 请告诉我哪条路是正确的。如果是正确的，如何解决错误？非常感激！
-
互联网是超文本标记语言(HTML)页面的集合，它们彼此链接以形成概念性信息网络。随着时间的推移，静态资源数量增加，图像等更丰富的项目开始成为Web结构的一部分。 高级服务器技术允许动态服务器页面 - 其内容基于查询生成的页面。 很快，需要拥有更多动态网页才能获得动态超文本标记语言(DHTML)。一切都归功于JavaScript。在接下来的几年中，我们看到了跨帧通信，试图避免页面重新加载，然后在帧内
-
当前信息时代，哪里都是应用程序。这些应用程序们不仅仅是运行人们工作场所的工具 - 它们现在正在经营人们的生活。 对即时响应的需求，完美的行为和更多的功能是前所未有的。 而且，当然，人们期望应用程序在不同类型的设备上运行平稳，特别是在移动设备上。 应用程序执行的速度与它所做的一样重要。 NGINX的核心功能，例如其具有高性能HTTP和反向代理服务器的大规模可扩展事件驱动架构，访问和带宽控制以及与各种
-
开发人员和运营工程师是两个不同的组织团队，如果发现这两个团队在错误的轨道上协作，则表明需要DevOps。以下是两个团队经常出现的一些问题： 在DevOps之前，开发和运营团队完全孤立。 测试和部署是在设计构建之后完成的独立活动。因此，他们比实际构建周期消耗更多时间。 在不使用DevOps的情况下，团队成员将大量时间花在测试，部署和设计上，而不是构建项目。 手动代码部署会导致生产中出现人为错误 编码