This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 53%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EES%3C/text%3E%3C/svg%3E)
I'm trying to integrate ADFS with our Service Provider (SP). I've enabled the Artifact Resolution (SOAP) mechanism in ADFS and ADFS does response to an ArtifactRequest message with an ArtifactResponse message, but the ArtifactResponse is missing a ds:Signature element (signature on the ArtifactResponse). It does include a signature inside the Response, but the SAML protocol specification (e.g. http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html#5.1.2.SP-Initiated%20SSO:%20%20Redirect/POST%20Bindings|outline) says that the ArtifactResponse should look like:
<samlp:ArtifactResponsexmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="identifier_3"
InResponseTo="identifier_2"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
<!-- an ArtifactResponse message SHOULD be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<samlp:Responsexmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ... > ...</samlp:Response>
</samlp:ArtifactResponse>
The response from ADFS is missing the ds:Signature element here. Consequently, the SAML library in our SP is rejecting the ArtifactResponse as "unauthenticated".
Is there some setting in ADFS required to provide the required signature? I haven't been able to find one.
Thanks.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 85%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDS%3C/text%3E%3C/svg%3E)
Hi @Eric Swenson , were you able to find a resolution for this?
We are running into the same issue on our Server 2012 instance of ADFS
I have never seen an application using this feature as of today :) May I ask what they used it for? I am curious.
Also, I am sure that's something you've checked, but Artifact Resolution requires a SQL backend (it is not supported with a WID backend). Not sure if that explains anything though.
Artifact Binding is an alternative to HTTP-POST or HTTP-REDIRECT. Some customers prefer to use Artifact binding as part of their SAML SSO configuration for security purposes; artifact binding passes information through a SOAP backchannel instead of through the browser. This is a pretty good primer: https://everything1know.wordpress.com/2019/02/19/saml-2-0-artifact-binding/
Unfortunately we are definitely using a SQL backend, so WID is not the issue. Even specifying the Set-AdfsRelyingPartyTrust -SamlResponseSignature "MessageAndAssertion" does not fix this issue (which you think it would)
Thanks! I know what Artifact Resolution is. What I am curious about is what is that sensitive information that you are expecting to retrieve through that channel (not how). By default, AD is the only attribute store, so everything is pretty much public already.
Is there a way to have ADFS sign the backchannel messages?
The only information we are expecting to receive is the ArtifactResponse - containing a set of assertions. Signing it would further insure that it hasn't been tampered with.
Also, this signing is based on the OASIS spec (as Eric mentioned). This has become a problem for us since ADFS is not following it and therefore has become incompatible with frameworks like Pac4J