You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kerby@directory.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2015/09/30 13:04:46 UTC
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
Re: Token PreAuth
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <ji...@intel.com> 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:coheigea@apache.org]
> Sent: Friday, October 09, 2015 12:32 AM
> To: Li, Jiajia
> Cc: kerby@directory.apache.org; 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:coheigea@apache.org]
> > Sent: Tuesday, October 06, 2015 9:48 PM
> > To: Zheng, Kai
> > Cc: kerby@directory.apache.org
> > 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 <ka...@intel.com> 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:coheigea@apache.org]
> > > Sent: Wednesday, September 30, 2015 7:05 PM
> > > To: kerby@directory.apache.org
> > > 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
RE: Token PreAuth
Posted by "Li, Jiajia" <ji...@intel.com>.
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:coheigea@apache.org]
Sent: Friday, October 09, 2015 12:32 AM
To: Li, Jiajia
Cc: kerby@directory.apache.org; 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:coheigea@apache.org]
> Sent: Tuesday, October 06, 2015 9:48 PM
> To: Zheng, Kai
> Cc: kerby@directory.apache.org
> 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 <ka...@intel.com> 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:coheigea@apache.org]
> > Sent: Wednesday, September 30, 2015 7:05 PM
> > To: kerby@directory.apache.org
> > 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
Re: Token PreAuth
Posted by Colm O hEigeartaigh <co...@apache.org>.
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:coheigea@apache.org]
> Sent: Tuesday, October 06, 2015 9:48 PM
> To: Zheng, Kai
> Cc: kerby@directory.apache.org
> 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 <ka...@intel.com> 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:coheigea@apache.org]
> > Sent: Wednesday, September 30, 2015 7:05 PM
> > To: kerby@directory.apache.org
> > 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
RE: Token PreAuth
Posted by "Li, Jiajia" <ji...@intel.com>.
Hi Colm,
>> 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?
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.
>> 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.
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.
Thanks
Jiajia
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, October 06, 2015 9:48 PM
To: Zheng, Kai
Cc: kerby@directory.apache.org
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 <ka...@intel.com> 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:coheigea@apache.org]
> Sent: Wednesday, September 30, 2015 7:05 PM
> To: kerby@directory.apache.org
> 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
Re: Token PreAuth
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <ka...@intel.com> 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:coheigea@apache.org]
> Sent: Wednesday, September 30, 2015 7:05 PM
> To: kerby@directory.apache.org
> 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
RE: Token PreAuth
Posted by "Zheng, Kai" <ka...@intel.com>.
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:coheigea@apache.org]
Sent: Wednesday, September 30, 2015 7:05 PM
To: kerby@directory.apache.org
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