Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:SOAP is not enabled for (SP) :::
Pruvost, Christian (ELS-OXF)
c.pruvost at elsevier.com
Wed Nov 22 12:00:31 EST 2017
Thank Tom,
We actually use a connection over TLS , having exchanged our public certificate with the IDP for the AttributeQuery request, and this was working fine in our respective QA environments. The binding was occurring over port 9443 and the section of the IDP Metadata for attribute query on the SP side is as follow
AttributeAuthorityDescriptor for the QA environment:
<md:EntityDescriptor (...)
(...)
<md:AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE
CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE
CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE
CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE
CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE
CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE CERTIFICATE
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://qa-idp.domain:9443/idp/attrsvc.ssaml2"/>
<md:AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://qa-idp.domain:9443/idp/attrsvc.ssaml2"/>
<md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
</md:AttributeAuthorityDescriptor>
(...)
</md:EntityDescriptor>
This was working absolutely fine, even after removing the <md:KeyDescriptor>**. I suspect because we are using a non-default port (i.e. other than 443), as stated in the note on this page (https://wiki.shibboleth.net/confluence/display/IDP30/SAML2AttributeQueryConfiguration)
** We tried to remove it to check if it was still working. The reason was that for the production IDP we were not provided with any KeyDescriptor element either.
THEN WE MOVE TO PRODUCTION RELEASE
Then we were using the following metadata initially for the production IDP
<md:EntityDescriptor (...)
(...)
<md:AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<md:AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.domain/idp/attrsvc.ssaml2"/> <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
</md:AttributeAuthorityDescriptor>
(...)
</md:EntityDescriptor>
With this setup, we were getting the error HTTP/1.1 401 "SOAP client request not properly authenticated. SAML message Issuer=(SP) ::: https://sdauth.sciencedirect.com/<https://urldefense.proofpoint.com/v2/url?u=https-3A__sdauth.sciencedirect.com_&d=DwMGaQ&c=9fZnZOgPWmHmvevlab4V4DSjtBMjorSlbQYfK_MauDg&r=MZGJbzAhCaLlmrt9tbpOJ3A09ZiEtpJF4NTACWTkEx4&m=_r64VGnOR4XtV6O1d6uLbb9iFU3BZDRZNpyPMOs9GxU&s=BXUlVOEM6ZnCwu_XWPYqV7XmC20qX6UXqJxXFJ2Yum4&e=>. Authenticated identity=null").
Highlighting clearly some authentication / certificate or signature issue - not 100% sure what the trigger is here.
Subsequently we tried the following metadata for the production IDP (attempting to repeat access via port 9443)
<md:EntityDescriptor (...)
(...)
<md:AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<md:AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.domain:9443/idp/attrsvc.ssaml2"/> <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
</md:AttributeAuthorityDescriptor>
(...)
</md:EntityDescriptor>
The error we are getting now is a server HTTP 500:
HTTP/1.1 500 Server Error
Date: Wed, 22 Nov 2017 16:15:20 GMT
Content-Security-Policy: referrer origin
Cache-Control: no-cache, no-store
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/xml;charset=utf-8
Set-Cookie: PF=WeEOsMOySt2lQs3OPBkZnh;Path=/;Secure;HttpOnly
Transfer-Encoding: chunked
171
<S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"><S11:Body><S11:Fault><faultcode xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">soapenv:Server</faultcode><faultstring>Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:SOAP is not enabled for (SP) ::: https://sdauth.sciencedirect.com/</faultstring></S11:Fault></S11:Body></S11:Envelope<https://sdauth.sciencedirect.com/%3c/faultstring%3e%3c/S11:Fault%3e%3c/S11:Body%3e%3c/S11:Envelope>>
0
We suspect that we should be able to sort this out by adjusting the IDP configuration. But our issue is still on-going...
Cheers,
Christian.
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Tom Scavo
Sent: 22 November 2017 14:43
To: Shib Users <users at shibboleth.net>
Subject: Re: Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:SOAP is not enabled for (SP) :::
*** External email: use caution ***
On Wed, Nov 22, 2017 at 9:32 AM, Pruvost, Christian (ELS-OXF) <c.pruvost at elsevier.com> wrote:
> Yes, that's what I mean. But I think the answer I received directly clearly point to what I suspected.
> A misconfiguration in SP metadata for that IDP or the IDP not being configured for such binding with our SP...
The latter is very likely in my experience. IdPs routinely publish AttributeService endpoints (and other back-channel endpoints) that are untested and in some cases obviously broken.
Since SP metadata does not indicate whether the SP is willing or able to send an AttributeQuery, SP metadata is not the issue here. The only thing you need in metadata is a signing key, which is used by your SOAP client to authenticate to the IdP.
> (...)
> as the error message says, the IdP doesn't have a SOAP endpoint
> location for the SP - check your SP metadata etc to ensure you have
> one existing and then ensure that the IdP has that line entry for your
> SP entity - this will have to be done for every IdP (which is where
> federations come in useful as you just update your metadata in the
> main metadata file and all IdPs get updated
> (...)
That makes no sense.
Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
________________________________
Elsevier Limited. Registered Office: The Boulevard, Langford Lane, Kidlington, Oxford, OX5 1GB, United Kingdom, Registration No. 1982084, Registered in England and Wales.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171122/20f3f8c6/attachment-0001.html>
More information about the users
mailing list