SAML 2 Redirect binding decoder should handle SAMLEncoding parameter
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
While reviewing the bindings spec for something else, I was reminded that the SAML 2 Redirect binding can carry an optional SAMLEncoding query param, to specify a different encoding scheme URI other than the default, which is the DEFLATE one.
Currently our decoder only supports the DEFLATE encoding, hardcoded in the impl.
We should check for the presence of the SAMLEncoding param and at a minimum, throw an appropriate exception if we don't support.
We could also choose to actually try and support alternate encodings in some fashion. One route is plugins, via an injected Map<String,Function> or similar. That's probably a bit of work for a essentially non-existent use case - the DEFLATE encoding is the only one defined so far - but we should at least consider it.
Environment
None
Activity
Brent Putman
February 3, 2017 at 11:30 PM
Fixed in r4605.
Brent Putman
November 14, 2016 at 9:21 PM
Actually, the name of the class is HTTPRedirectDeflateDecoder, so the encoding is right in the name, and in Javadoc is clearly documented to only support the DEFLATE mechanism. So I'd say for this decoder impl, it should just check and throw.
If we ever needed to support another encoding mechanism(s), that would just be a different decoder impl. And as Scott says, that is very low priority. And also very unlikely to see in the real world. One would probably also need a way to indicate the non-default encoding via metadata, as mentioned in the spec, probably via an extension attribute that is yet to be defined.
While reviewing the bindings spec for something else, I was reminded that the SAML 2 Redirect binding can carry an optional
SAMLEncoding
query param, to specify a different encoding scheme URI other than the default, which is the DEFLATE one.Currently our decoder only supports the DEFLATE encoding, hardcoded in the impl.
We should check for the presence of the
SAMLEncoding
param and at a minimum, throw an appropriate exception if we don't support.We could also choose to actually try and support alternate encodings in some fashion. One route is plugins, via an injected
Map<String,Function>
or similar. That's probably a bit of work for a essentially non-existent use case - the DEFLATE encoding is the only one defined so far - but we should at least consider it.