You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2017/05/23 16:39:56 UTC
JWTFederationFilter issuer
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
Re: JWTFederationFilter issuer
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Larry,
I'd like to change the logic of AbstractJWTFilter.validateAudiences + I'm
wondering what your opinions are on this. Currently the JWT + SSOCookie
filters take an expected audience (or audiences if a comma-separated String
was specified) name from a configuration parameter. When parsing a received
token this logic is followed:
a) If no pre-configured audiences then validation is fine
b) Otherwise if the token has an audience that matches one of our
pre-configured audiences then validation passes.
c) Otherwise validation fails.
I'd like to change this logic to take into account the request URL. This is
what the AccessTokenFederationFilter does, although it doesn't check for
pre-configured audiences. I'm thinking validation logic along the following
lines....
a) The received Token must have an audience that matches a pre-configured
audience if one is specified
b) If no pre-configured audience is configured, then the token must have an
audience that matches the request URL
c) Otherwise validation fails.
If you feel that point (b) is too strict, I could add a new boolean
configuration property to control whether to enforce the request URL
matching or not.
WDYT?
Colm.
On Wed, May 24, 2017 at 3:33 PM, Colm O hEigeartaigh <co...@apache.org>
wrote:
> Thanks for the reply Larry.
>
> On Tue, May 23, 2017 at 6:10 PM, larry mccay <lm...@apache.org> wrote:
>
>>
>> I think it should - if not please file a JIRA and provide a patch if you
>> like.
>>
>
> Done (https://issues.apache.org/jira/browse/KNOX-948). I did some
> refactoring of the two JWT filters so that they share common code, and
> incorporated this as part of the patch.
>
>
>>
>> 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!
>>
>
> OK great. I will do some work in this area and do some interop testing
> while I'm at it.
>
> Colm.
>
>
>>
>> Thanks,
>>
>> --larry
>>
>>
>> On Tue, May 23, 2017 at 12:39 PM, Colm O hEigeartaigh <
>> coheigea@apache.org> 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
>>>
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: JWTFederationFilter issuer
Posted by Colm O hEigeartaigh <co...@apache.org>.
Thanks for the reply Larry.
On Tue, May 23, 2017 at 6:10 PM, larry mccay <lm...@apache.org> wrote:
>
> I think it should - if not please file a JIRA and provide a patch if you
> like.
>
Done (https://issues.apache.org/jira/browse/KNOX-948). I did some
refactoring of the two JWT filters so that they share common code, and
incorporated this as part of the patch.
>
> 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!
>
OK great. I will do some work in this area and do some interop testing
while I'm at it.
Colm.
>
> Thanks,
>
> --larry
>
>
> On Tue, May 23, 2017 at 12:39 PM, Colm O hEigeartaigh <coheigea@apache.org
> > 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
>>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: JWTFederationFilter issuer
Posted by larry mccay <lm...@apache.org>.
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 <co...@apache.org>
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
>