AW: IDPv3.1.2: SAML2 AttributeQuery processing fails with Message context was not authenticated

[Guenther Schreiner]

Thanks, Scott, for your ideas!

> If the error is logged from an attribute query, the basic answer is that you don't have the backchannel
> configured correctly or the request is simply being made incorrectly and is in fact invalid (wrong key,
> whatever). 

 As the test SP works well with IDPv2.x the error is on the IDP side. In opposite to the IDPv2 we now
 have combined the 2nd port (8443) into the 443 ... this might lead to an error. 

> If you don't support attribute queries, you shouldn't have metadata indicating you do, and you then
> wouldn't be getting any queries at all. I can't tell if that's what you want or not.

 Attribute queries are working up to the point of throwing the non-auth'ed error message:

   2015-09-16 12:09:00,481 - INFO [Shibboleth-Audit.SSO:241] - 20150916T100900Z|
     urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_4c47d0938e36dba23ba764f8f710431a|
     https://testsp2.aai.dfn.de/shibboleth|http://shibboleth.net/ns/profiles/saml2/sso/browser|
     https://idp-pilot.smile.de/idp/shibboleth|
     urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_a387204906b510d0a4cb0281fe1f9f22|scgu0003|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||AAdzZWNyZXQx1puACU7dHqk2grDLiQloiw6fNLO87zuD8UpGYRJHgtgsh/7a8AhYT/TOEfIWLPHyEF+NCm3sd3MpQDyPGx271/eBsEnut4k64uLZh1pQ8QhoUomBfBRry9UfqLvcA2WjHiqIQ9Z5m3We/I39|_cf192f3c7eef776b72a682b4b6e22527
2015-09-16 12:09:00,913 - DEBUG [PROTOCOL_MESSAGE:121] -
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
        <samlp:AttributeQuery ID="_91b68011609d18549fb441f2a03b7928"
            IssueInstant="2015-09-16T10:09:00Z" 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://testsp2.aai.dfn.de/shibboleth</saml:Issuer>
            <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
                <saml2:NameID
                    Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                    NameQualifier="https://idp-pilot.smile.de/idp/shibboleth"
                    SPNameQualifier="https://testsp2.aai.dfn.de/shibboleth" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">AAdzZWNyZXQx1puACU7dHqk2grDLiQloiw6fNLO87zuD8UpGYRJHgtgsh/7a8AhYT/TOEfIWLPHyEF+NCm3sd3MpQDyPGx271/eBsEnut4k64uLZh1pQ8QhoUomBfBRry9UfqLvcA2WjHiqIQ9Z5m3We/I39</saml2:NameID>
            </saml:Subject>
        </samlp:AttributeQuery>
    </S:Body>
</S:Envelope>
2015-09-16 12:09:00,927 - WARN [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:182] - Profile Action WebFlowMessageHandlerAdaptor: Exception handling message
org.opensaml.messaging.handler.MessageHandlerException: Message context was not authenticated
        at org.opensaml.messaging.handler.impl.CheckMandatoryAuthentication.doInvoke(CheckMandatoryAuthentication.java:70)

> If you're asking why it's receiving a query, it's because you didn't supply any attributes to the SP 
> (and you claim you support queries in your metadata).

 This is a good point ... don't know why the IDPv3 refuses to deliver attributes in the 1st step. The
 config part within relying-party.xml looks well for me:

                <bean parent="SAML2.SSO"
			p:postAuthenticationFlows="attribute-release"
                        p:includeAttributeStatement="true" />

> If you're asking why a SAML 1 response includes attribute(s) but a SAML 2 response didn't, that
> would normally have to be caused by an issue with attribute encoders. Whatever you released 
> has SAML 1 encoders but not SAML 2 encoders attached in the resolver.

 Verified with resolvertest that all attributes are ready for SAML2.


 Two possible ways forward I can imagine:
 (a) dig into the reason, why the AttributeQuery is not auth'ed
 (b) analyze why the 1st SP contact does not delivered any attributes

 Regards,
-Guenther