Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:SOAP is not enabled for (SP) :::

Thu Nov 23 05:35:46 EST 2017

Hi Tom,

Thanks for following up I didn't put all the metadata, and I agree with you that a signing certificate is necessary for the authentication. We do have a signing certificate in a <KeydEscriptor> element inside the <IDPSSODescriptor element> - This is how the 'standard' SAML authentication is working (no issues or questions around that. Our problem is with the <AttributeAuthorityDescriptor> (or the setup for the AttributeQuery end-point on the IDP side), because our AttributeQuery calls are failing to complete.

The Certificate in the KeyDescriptor is 'optional' in the AttributeAuthorityDescriptor (although that is rare). I actually am reading conflicting information on that topic:

e.g. paragraph 3.10 in https://www.ukfederation.org.uk/library/uploads/Documents/federation-technical-specifications.pdf
All <IDPSSODescriptor> and <AttributeAuthorityDescriptor> role descriptors
MUST include at least one <KeyDescriptor> suitable for signing use (with
use="signing" or absent).

e.g. https://wiki.shibboleth.net/confluence/display/CONCEPT/MetadataForIdP
For an <md:IDPSSODescriptor>:
<md:KeyDescriptor> (can be omitted, but rarely) <<<<<<<<<<<<<<<<<< This is present for our IDPSSODescriptor.
<md:ArtifactResolutionService> (only needed if supporting response by artifact)
<md:SingleLogoutService> (if any)
<md:NameIDFormat> (if any)
<md:SingleSignOnService> (always at least one)
<saml:Attribute> (rare today, but may be reasonable to include)
For an md:AttributeAuthorityDescriptor>:
<md:KeyDescriptor> (can be omitted, but rarely) <<<<<<<<<<<<<<<<<< This is what is omitted in our case (and attribute query still works in the QA test environment, not our production one)
<md:AttributeService> (always at least one)
<md:NameIDFormat> (if any)
<saml:Attribute> (rare today, but may be reasonable to include)

So it does not seem that there is anything drastically wrong, is there?
Our attributeQuery metadata (below) seems okay
<md:AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

<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>

Our IDP does not have a certificate to provide for the ' AttributeAuthorityDescriptor' element, they only have one for the 'IDPSSODescriptor' element...
We still need to check with the IDP - this seems to be our next step... - I know -

Cheers,
Christian.

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Tom Scavo
Sent: 22 November 2017 17:22
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 12:00 PM, Pruvost, Christian (ELS-OXF) <c.pruvost at elsevier.com> wrote:
>
> We actually use a connection over TLS , having exchanged our public
> certificate with the IDP for the AttributeQuery request...

Right, a signing certificate in metadata is used for SAML signing or back-channel TLS authentication. So all I'm saying is that you need at least one signing certificate in your metadata.

> AttributeAuthorityDescriptor for the QA environment:

That metadata looks fine except that <md:KeyDescriptor> should be <md:KeyDescriptor use="signing">.

> This was working absolutely fine, even after removing the
> <md:KeyDescriptor>**.

No, sorry, I don't believe that. Your SP can not authenticate the IdP without a certificate.

> Then we were using the following metadata initially for the production
> IDP
>
> [...]
>
> 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/. Authenticated identity=null").
> Highlighting clearly some authentication / certificate or signature
> issue  - not 100% sure what the trigger is here.

A signing certificate is needed in SP metadata.

> Subsequently we tried the following metadata for the production IDP
> (attempting to repeat access via port 9443)

1) You need to have a signing certificate in your metadata
2) The IdP needs to have a signing certificate in its metadata

Without that, it's a non-starter.

Did you ask the IdP to push attributes on the front channel? Most IdPs do, I'm not sure what the problem is here.

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.