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
