Thanks again. Here are the two JIRAs: https://issues.apache.org/jira/browse/DIRKRB-431 https://issues.apache.org/jira/browse/DIRKRB-432
Colm. On Fri, Oct 9, 2015 at 3:39 AM, Li, Jiajia <[email protected]> wrote: > Hi Colm, > > >>A further question - is there any relation between the claims/subject of > the token and any subsequently issued kerberos token? Or are the claims of > the JWT just discarded? > > In AsRequest#checkClient(), we can get the subject from claims to create > client principal, and the audiences from token claim used in > TokenPreauth#verify(), and other claims discarded. > > >>Currently we only check the token expiration on processing. We should > also check the NotBeforeTime (adding a suitable leeway for clock skew). I > think we should also define a configurable time-to-live parameter, and > expire tokens based on the "iat" claim, if there is no NotBeforeTime. > > Good idea. > > Thanks > Jiajia > > -----Original Message----- > From: Colm O hEigeartaigh [mailto:[email protected]] > Sent: Friday, October 09, 2015 12:32 AM > To: Li, Jiajia > Cc: [email protected]; Zheng, Kai > Subject: Re: Token PreAuth > > Hi Jiajia, > > You are right, the test has not signed the token yet, I think the signature > > is necessary, so I will change the test in DIRKRB-429. > > > > Ok great. > > > > Thanks for your test and point out the issue, I think this feature is > > missed, the kdc need to check the issuer and I will implement in > DIRKRB-430. > > > > Cool. It sounds like this feature needs a lot of work :-) > > A further question - is there any relation between the claims/subject of > the token and any subsequently issued kerberos token? Or are the claims of > the JWT just discarded? > > Currently we only check the token expiration on processing. We should also > check the NotBeforeTime (adding a suitable leeway for clock skew). I think > we should also define a configurable time-to-live parameter, and expire > tokens based on the "iat" claim, if there is no NotBeforeTime. > > Colm. > > > > Thanks > > Jiajia > > > > -----Original Message----- > > From: Colm O hEigeartaigh [mailto:[email protected]] > > Sent: Tuesday, October 06, 2015 9:48 PM > > To: Zheng, Kai > > Cc: [email protected] > > Subject: Re: Token PreAuth > > > > Hi Kai, > > > > Thanks for your reply. > > > > Actually the TokenLoginTestBase tests were not actually run as part of > > the maven build as they don't end in "Test" - now fixed :-) > > > > I'm still not clear on a few points... > > > > > It's required the token must be verified via signature > > > > The JWT tokens themselves are not actually signed in the test though > > (using JWS). Are you referring to a different signature scheme? > > > > > and the issuer must be trusted as one of preconfigured issuers. > > > > Where is this configured? In the > > "TokenLoginWithTokenPreauthEnabledTest" I modified the issuer in the > "issueToken" method + the test still passed. > > > > Colm. > > > > On Wed, Sep 30, 2015 at 1:38 PM, Zheng, Kai <[email protected]> wrote: > > > > > Hi Colm, > > > > > > Yeah, you're right. It's required the token must be verified via > > > signature and the issuer must be trusted as one of preconfigured > issuers. > > > Please look at the end to end test TokenLoginTestBase.java codes to > > > see how it works. > > > Also to note, there must be an armor ticket to make it work, that's > > > why ANONYMOUS PKINIT is the next major goal to finish, because it > > > can help obtain a ticket to use for the purpose. > > > > > > Please feel free to fire issues, thanks for trying. We can get them > > > fixed in RC2 if any. > > > > > > Regards, > > > Kai > > > > > > -----Original Message----- > > > From: Colm O hEigeartaigh [mailto:[email protected]] > > > Sent: Wednesday, September 30, 2015 7:05 PM > > > To: [email protected] > > > Subject: Token PreAuth > > > > > > Hi all, > > > > > > I'm just playing around with the Token PreAuth functionality. I'm a > > > bit confused as to how this works on the KDC side. How does the KDC > > > verify that the JWT token is valid? I would have assumed that the > > > token must be signed by a trusted issuer to be accepted by the KDC. > > > > > > 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 > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
