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

[Tom Scavo]

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