SAML2 Request - "Destination" XML attribute.

Paul Hethmon paul.hethmon at
Fri Aug 10 08:31:36 EDT 2012

Short answer is your ADFS friend is wrong. Their set up is broke in some

As long as their metadata is correct and it specifies the correct
endpoint, then putting that endpoint as the Destination is perfectly valid.

I have set up a system interoperating with ADFS that does send
Destination. The only difference I see is that I used Redirect to send the
AuthnRequest to them vs POST binding as in your example.

Every time I have had to work with ADFS, the typical first answer is your
XML is broke. Remove this attribute, change that attribute, or even alter
the name space declarations. I've had them ask me to make changes which
would make the XML invalid.

Unfortunately, I don't have any specific recommendations. Getting good
error messages out of ADFS appears to be a hard thing to do. Understanding
them even harder.


On 8/10/12 6:05 AM, "Friedrich Clausen" <fred at> wrote:

>Hi All,
>We are interoperating, via SAML2, with an ADFS (Active Directory
>Federation Services) IdP (aka Account federation server) and it
>appears to go well until redirection back to the SP where we receive
>the following error
>SAML response contained an error.
>Error from identity provider:
>Status: urn:oasis:names:tc:SAML:2.0:status:Responder
>Which I believe is an error returned by the ADFS IdP [1]. I have been
>working with the administrator on the ADFS side and he says
>> It also looks like the SAML request has
>> This should not be necessary and is causing an error on our end.
>> Other systems we work with do not include this tag.
>is this a valid concern? How can I prevent the SP (native Shibboleth
>SP with Apache and Tomcat) from sending the "Destination" XML
>attribute in the SAML2 request? FYI, the full request is at
>Many thanks!
>To unsubscribe from this list send an email to
>users-unsubscribe at

More information about the users mailing list