Single Log out not working with Shibboleth IdP

Question

I have been trying to implement a WEB SSO Service provider in java. I am using Shibboleth Identity Provider. Things are working fine till authentication step and I am successfully able to create a session/set cookie for a user. But when I'm trying to use single sign out functionality I am getting an "RequestDenied" response from shibboleth IdP. I checked the logs and there it was written Inbound message issuer was not authenticated. The same issuer is working fine with log in step but giving error with log out step. Any configuration file to update for it, any pointer, suggestion? This is my log out request.

<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                     ID="jiojjcjckjaflbedlcjcpcnecigbjhaekalmfkcg"
                     IssueInstant="2014-02-24T23:30:25.257Z"
                     NotOnOrAfter="2014-02-24T23:35:25.257Z"
                     Version="2.0"
                     >
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://localhost/sp/shibboleth</saml:Issuer>
    <saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                 NameQualifier="urn:oasis:names:tc:SAML:2.0:assertion"
                 >rohit</saml:NameID>
    <samlp:SessionIndex/>
</samlp:LogoutRequest>

And this is what I'm getting in response.

<saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                       Destination="https://localhost:8091/SSO/consumer"
                       ID="_02a145f4992cb2e11a8fc4aa43a74096"
                       InResponseTo="jiojjcjckjaflbedlcjcpcnecigbjhaekalmfkcg"
                       IssueInstant="2014-02-24T23:30:25.334Z"
                       Version="2.0"
                       >
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                  Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
                  >https://localhost/shibboleth</saml2:Issuer>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
            <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" />
        </saml2p:StatusCode>
        <saml2p:StatusMessage>Message did not meet security requirements</saml2p:StatusMessage>
    </saml2p:Status>
</saml2p:LogoutResponse>

Answer 1

You have a setting called Mandatory Message Authentication for the SLO profile turned on.

You can usually find the setting in the bottom on relying party configuration file. It should look like this.

<security:SecurityPolicy id="shibboleth.SAML2SLOSecurityPolicy" xsi:type="security:SecurityPolicyType">
    <security:Rule xsi:type="samlsec:Replay"/>
    <security:Rule xsi:type="samlsec:IssueInstant"/>
    <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine"/>
    <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
    <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine"/>
    <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine"/>
    <security:Rule xsi:type="samlsec:MandatoryIssuer"/>
    <security:Rule xsi:type="security:MandatoryMessageAuthentication"/>
</security:SecurityPolicy>

Mandatory message authentication would require you to setup a way to verify the message came from a trusted peer. Usually this done with signed requests. SPs can sign their metadata and the expose a certificate for validation. Shibboleth can be setup to trust the cert from the SP.

A way to accomplish this is to setup a metadata filter for your SP with something like this in your metadata provider:

<metadata:MetadataFilter xsi:type="metadata:SignatureValidation"
                         trustEngineRef="shibboleth.MetadataTrustEngine"
                         requireSignedMetadata="true" />

This references a trust engine called shibboleth.MetadataTrustEngine . Trust engines can be used for signature verification.

Trust engines are also defined in the relying party configuration, so just look for it. The default setup looks like this:

<security:TrustEngine id="shibboleth.SignatureTrustEngine" xsi:type="security:SignatureChaining">
    <security:TrustEngine id="shibboleth.SignatureMetadataExplicitKeyTrustEngine" xsi:type="security:MetadataExplicitKeySignature" metadataProviderRef="ShibbolethMetadata"/>
    <security:TrustEngine id="shibboleth.SignatureMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXSignature" metadataProviderRef="ShibbolethMetadata"/>
</security:TrustEngine>

This should be sufficient if you've defined your metadata provider as part of the default chaining metadata provider.

Optionally, you can just turn off the message authentication policy by commenting out:

<security:Rule xsi:type="security:MandatoryMessageAuthentication"/>