Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:SOAP is not enabled for (SP) :::
Tom Scavo
trscavo at gmail.com
Thu Nov 23 10:52:22 EST 2017
On Thu, Nov 23, 2017 at 5:35 AM, Pruvost, Christian (ELS-OXF)
<c.pruvost at elsevier.com> wrote:
>
> So it does not seem that there is anything drastically wrong, is there?
I already told you what is wrong.
> Our attributeQuery metadata (below) seems okay
> <md:AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
> <!--md:AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.domain:9443/idp/attrsvc.ssaml2"/-->
> <md:AttributeService Location="https://idp.domain:9443/idp/attrsvc.ssaml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
> <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>
No, it's not okay. There is no KeyDescriptor and so the SP is unable
to authenticate the IdP. That's a showstopper.
> Our IDP does not have a certificate to provide for the ' AttributeAuthorityDescriptor' element, they only have one for the 'IDPSSODescriptor' element...
Then the IdP does not support attribute query. Instead of swimming
upstream, ask the IdP to push attributes on the front-channel instead.
Tom
More information about the users
mailing list