Hi Colm - a) Why does the SSOCookieFederationFilter not impose the same requirement?
I think it should - if not please file a JIRA and provide a patch if you like. b) IMO we should make the issuer configurable (it can default to "KNOXSSO"). That opens up the filter to work with third party JWT providers. WDYT? I can buy this but would need to see some proof that it works with others. There are many reasons that it should but there may be some semantic details that are unique to Knox. For instance, Knox evaluates the audience claims provided in the token against a configured list of acceptable audiences. If any match then it is accepted. If there are none configured on the SSOCookieProvider side then it is also accepted regardless of what is present in the token. This may have nuances to it that are Knox specific - not sure. Also, we only support one algorithm type at this point - shared secret signatures are not supported. JWE is also not tested/supported. So supporting 3rd parties will need to either: * be a subset of their supported capabilities * require a lot of testing to extend the above support With all of that said, I would not be opposed to making it configurable and I would be all for verifying that we can support tokens from 3rd parties! Thanks, --larry On Tue, May 23, 2017 at 12:39 PM, Colm O hEigeartaigh <[email protected]> wrote: > Hi all, > > The JWTFederationFilter mandates that the issuer of the JWT must be > "KNOXSSO". Two question on this: > > a) Why does the SSOCookieFederationFilter not impose the same requirement? > b) IMO we should make the issuer configurable (it can default to > "KNOXSSO"). That opens up the filter to work with third party JWT > providers. WDYT? > > Colm. > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
