2

I am using Shibboleth SP for SAML authorization.

Recently IdP has changed the configuration and it now requires to sign the AuthRequest.

IdP's metadata has following parameter

<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
WantAuthnRequestsSigned="true"><md:KeyDescriptor use="signing">

SP's shibboleth2.xml file had following tag

<ApplicationDefaults entityID="...."
   REMOTE_USER="eppn persistent-id targeted-id email Email FirstName LastName NameID">

After IdP enforced AuthRequest signing, we changed our shibboleth2.xml file as following

<ApplicationDefaults entityID="..."
                         REMOTE_USER="eppn persistent-id targeted-id email 

Email FirstName LastName NameID" 
signing="true" encryption="true">

Basically, I added signing="true" and encryption="true".

After that the new Metadata generated has following attribute in tag

<md:SPSSODescriptor AuthnRequestsSigned="1" 
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol 
urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">

Earlier AuthnRequestsSigned="1" attribute was not present.

After this when I try to authenticate, it gives us following error,

<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/>
        <samlp:StatusMessage>Unable to verify the signature</samlp:StatusMessage>
    </samlp:Status>

Question 1: Do I need to give IdP this new metadata? Question 2: Any idea why this is happening? Question 3: Do I need to change anything else in the configuration?

P.S. Before enforcing AuthRequest signing, it was working, so I don't think there is any other issue in configuration.

Here is the sample AuthRequest which goes

<samlp:AuthnRequest
    AssertionConsumerServiceURL="https://...SP-host.../Shibboleth.sso/SAML2/POST"
    Destination="https://...idp-host.../marrsso/idp/SSO.saml2"
    ID="...some-id..." IssueInstant="2019-01-11T14:13:25Z"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://...entity-id.../shibboleth</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>

I believe signing info should go here as part of request. As http request, it goes as GET request, is that correct? When I see the request in network, I can see the Signature going as query param enter image description here The status code of the request is '200'

Akshay
  • 3,558
  • 4
  • 43
  • 77

1 Answers1

1

It is not unusual to send the signature as part of the query string. Its like a pre-signed URL.

  1. Just enabling "signing=true" on SP should not change the key that was originally generated. So re-sending the metadata is not a requirement. Check with IdP if the SP's metadata was originally imported in full or did they just add relying-party and other basic end points to integrate, that might work just fine if request signing is not required.

  2. If IdP is not able to verify the signature then they must be missing the certificate from SP. To be sure compare the two metadata files before and after enabling signing and encryption, they should match(specially around certificates) but for the additional attribute that you had already identified. Resend the metadata otherwise.

  3. No other configuration changes are required in this case.

stk
  • 114
  • 4