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

[Cantor, Scott]

On 9/16/15, 6:14 AM, "users on behalf of Guenther Schreiner" <users-bounces at shibboleth.net on behalf of Guenther.Schreiner at hs-karlsruhe.de> wrote:



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

Well, yes. That means you would have to require every requester to sign its messages. They're not going to do that by default, and it's not going to work. You can't support the back channel like that without changing existing systems' behavior.

But that's not really the point here, you shouldn't be using queries.

> This is a good point ... don't know why the IDPv3 refuses to deliver attributes in the 1st step.

Your filter and resolver config aren't producing any.

> The config part within relying-party.xml looks well for me:
>
>                <bean parent="SAML2.SSO"
>			p:postAuthenticationFlows="attribute-release"
>                        p:includeAttributeStatement="true" />

The include property is redundant, that's the default for that profile.

>Verified with resolvertest that all attributes are ready for SAML2.

The only explanation for the behavior you wrote is the one I gave. If you get attributes for the same SP identity for SAML 1 and not SAML 2, it's an encoder problem. If it's a different SP, it's likely a filter problem.

>Two possible ways forward I can imagine:
> (a) dig into the reason, why the AttributeQuery is not auth'ed

You won't get attributes on the back channel you already didn't release on the front channel.

> (b) analyze why the 1st SP contact does not delivered any attributes

The only issue at hand. And do fix your metadata, you don't support tha backchannel so don't advertise it.

-- Scott