SamlResponse issuer verification

[mauromol]

Currently SamlResponse during its validity check ensures that the issuer of the response and the issuer of the assertion (with the constraint that just one assertion is present) have both a value equal to the IdP entity id.
This is fine, however no check is made against the format of such issuers. Specification says that the issuer format must be urn:oasis:names:tc:SAML:2.0:nameid-format:entity and that, in this case, no qualifier must be specified. But what about a malicious/erroneous response?
Perhaps java-saml could add a check that ensures that the format is either omitted or urn:oasis:names:tc:SAML:2.0:nameid-format:entity? And perhaps that no qualifier (and maybe also no SP qualifier) is specified as well?

The Italian SPID specification requires the former check (the one about the format) is made, although we could say that this might be an excess of rigor.

What do you think?

[pitbulk]

I don't think this one gonna be required. At the end the toolkit make nothing with the "urn:oasis:names:tc:SAML:2.0:nameid-format:entity" format value

[mauromol]

True, there probably is no impact from a functional point of view. I'm just wondering about security implications... Could this missing check bring an issue? I really don't know. After all, why does SAML 2.0 specification require this?

What I can say is that if an implementation based on java-saml is required to pass some assessment control which requires a use case with a wrong issuer format to cause a failure in response processing, a patch (or an extension) is needed to make such an implementation fully compliant.

[pitbulk]

I dont think so, the format on the NameID, Attributes from the AttributeStatement, ... are used by the SP in order to know how to handle the value of such attribute, but in that specific case, we always assume the value is a string to be compared with the EntityID registered.

[mauromol]

What about an opt-in option "check response issuers format" configurable in settings, false by default?

[pitbulk]

I don't see justified on this case the addition of a new setting

[mauromol]

Ok, so do you prefer to just ignore this strict SAML compliance checking and let consumers implement it if desired?

With #318 and #352 that would be feasible.

[pitbulk]

Yes