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 2017/06/19 12:24:27 UTC
Kerby JWT support
Hi all,
I'd like to resurrect some of the issues surrounding the JWT support in
Kerby. If nothing else we can hopefully agree on what the outstanding
issues are and then put them into JIRA so that we have a record of what
needs to be done. Some of the tasks are fairly trivial and could be
addressed for the next release.
1) There was a proposal last year to move the TokenAuthLoginModule from the
"integration-test" module into the "kerb-client" module in a separate
package like 'jaas'.
2) I'd like to make the credential cache configuration item in the
TokenAuthLoginModule optional to simplify the configuration. It's not
actually needed as we just keep the TgtTicket internally in the LoginModule
anyway.
3) Right now, we need an armor cache to then get a TGT using a JWT.
However, I think we should also support configuring the KDC with a private
decryption key. If the incoming JWT token is encrypted to the KDC then we
should be able to skip the armor cache step.
4) For the access token case, make it possible to put claims from the JWT
token into the authorization data of the ticket. I've done some work on
this last year that could be re-used.
5) To test (4), I'd like to be able to query the authorization data of the
issued service ticket. However, using the Kerby API, the following returns
null?
tkt.getTicket().getEncPart() (.getAuthorizationData())
Is there a way for me to access the authorization data of the ticket using
the Kerby API in some way to check that it's actually getting inserted
properly?
Thoughts? Am I missing anything else?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby JWT support
Posted by Colm O hEigeartaigh <co...@apache.org>.
I've merged a fix for DIRKRB-632 + added some tests for it. For now my work
on this topic (JWT access tokens) is complete, until such time as someone
implements GSS support for the access token case.
Jiajia, could you take a look at the email I sent regarding the anonymous
pkinit support? There are a few issues I need to clarify there to finish
with the "identity" token use-case.
Colm.
On Wed, Jul 5, 2017 at 12:36 PM, Colm O hEigeartaigh <co...@apache.org>
wrote:
> Ok this is done, please take a look and let me know what you think.
>
> Colm.
>
> On Wed, Jul 5, 2017 at 12:12 AM, Li, Jiajia <ji...@intel.com> wrote:
>
>> > Maybe we could create a new class in kerb-core that encapsulates some
>> of these things that could
>> > be used instead?
>>
>> It's a good idea.
>>
>> Thanks
>> Jiajia
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: Tuesday, July 4, 2017 9:54 PM
>> To: kerby@directory.apache.org
>> Subject: Re: Kerby JWT support
>>
>> The problem with this is that it might be too restrictive. What if you
>> wanted access to the client principal or the client address etc. when
>> creating the AuthorizationData? Maybe we could create a new class in
>> kerb-core that encapsulates some of these things that could be used instead?
>>
>> Colm.
>>
>> On Tue, Jul 4, 2017 at 1:38 PM, Li, Jiajia <ji...@intel.com> wrote:
>>
>> > > Currently I'm using "kdcRequest.isToken()" and
>> "kdcRequest.getToken()".
>> > I guess we could change
>> > > the method to just take the kdcRequest.getToken()?
>> >
>> > Yes, set the AuthToken as the parameter of
>> > getIdentityAuthorizationData is a good choice.
>> >
>> > Thanks
>> > Jiajia
>> >
>> > -----Original Message-----
>> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> > Sent: Tuesday, July 4, 2017 4:03 PM
>> > To: kerby@directory.apache.org
>> > Subject: Re: Kerby JWT support
>> >
>> > On Tue, Jul 4, 2017 at 3:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>> >
>> > >
>> > > Which information in KdcRequest is used? I think the KdcRequest can
>> > > be replaced by some class really used in getting AuthorizationData.
>> > >
>> >
>> > Currently I'm using "kdcRequest.isToken()" and
>> > "kdcRequest.getToken()". I guess we could change the method to just
>> take the kdcRequest.getToken()?
>> >
>> > Colm.
>> >
>> >
>> > >
>> > > >b) In my tests, I'm just defining a custom AuthorizationType
>> > > (AD_TOKEN(256)). What should I use here instead? I don't think the
>> > > spec defines what it should be...
>> > >
>> > > I think the AD token type is a new type which undefined in
>> > > spec(RFC4120->7.5.4. Authorization Data Types), I think this new
>> > > type name is ok.
>> > >
>> > > Thanks
>> > > Jiajia
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> > > Sent: Monday, July 3, 2017 6:18 PM
>> > > To: kerby@directory.apache.org
>> > > Subject: Re: Kerby JWT support
>> > >
>> > > OK thanks, I managed to figure it out anyway. I have two more
>> > > questions on this topic WRT DIRKRB-632:
>> > >
>> > > a) I want to add the authorization data in the relevant method in
>> > > AbstractIdentityBackend. However, the problem here is that the
>> > > kerb-identity module does not have kerb-server as a dependency, and
>> > > hence I can't reference KdcRequest. The AbstractIdentityBackend gets
>> > > around this by using "Object" instead of KdcRequest in the method
>> > > signature, which is not a great idea really.
>> > >
>> > > What is the best way of handling this?
>> > >
>> > > b) In my tests, I'm just defining a custom AuthorizationType
>> > > (AD_TOKEN(256)). What should I use here instead? I don't think the
>> > > spec defines what it should be...
>> > >
>> > > Colm.
>> > >
>> > >
>> > > On Mon, Jul 3, 2017 at 1:49 AM, Li, Jiajia <ji...@intel.com>
>> wrote:
>> > >
>> > > > >The question I have here is that the KrbToken needs to call the
>> > > > >following
>> > > > code internally somehow:
>> > > >
>> > > > >this.innerToken =
>> > > > >getTokenDecoder().decodeFromBytes(getTokenValue());
>> > > > >setTokenType();
>> > > >
>> > > > >There is a commented out "decode(ByteBuffer)" method that
>> > > > >contains code
>> > > > that does this for a supplied ByteBuffer value. Should this method
>> > > > be called implicitly by
>> > > > >the AdToken code somehow? Or is it up to the client code to call
>> > > > >decode
>> > > > on KrbToken?
>> > > >
>> > > > I'm not very sure, I think it's up to the client code to call to
>> > > > decode the KrbToken.
>> > > >
>> > > > Thanks
>> > > > Jiajia
>> > > >
>> > > >
>> > > > -----Original Message-----
>> > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> > > > Sent: Friday, June 30, 2017 5:46 PM
>> > > > To: kerby@directory.apache.org
>> > > > Subject: Re: Kerby JWT support
>> > > >
>> > > > On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com>
>> > wrote:
>> > > >
>> > > > >
>> > > > > Yes, agree with you, credential cache it not really needed.
>> > > > >
>> > > > >
>> > > > OK I have committed this fix.
>> > > >
>> > > >
>> > > > > The EncTicketPart should be unseal, I think the following code
>> > > > > could help you.
>> > > > >
>> > > > > Ticket ticket = apReq.getTicket();
>> > > > > EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
>> > > > > etEncryptedEncPart(),
>> > > > > encKey, KeyUsage.KDC_REP_TICKET,
>> > EncTicketPart.class);
>> > > > > ticket.setEncPart(encPart);
>> > > > >
>> > > >
>> > > > It does, thanks! I have it kind of working now with a few hacks. I
>> > > > can get the KrbToken from the AuthorizationData now as follows:
>> > > >
>> > > > AuthorizationData authzData = encPart.getAuthorizationData();
>> > > > AuthorizationDataEntry dataEntry = authzData.getElements().
>> > > > iterator().next();
>> > > > AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
>> > > > KrbToken decodedKrbToken = token.getToken();
>> > > >
>> > > > The question I have here is that the KrbToken needs to call the
>> > > > following code internally somehow:
>> > > >
>> > > > this.innerToken =
>> > > > getTokenDecoder().decodeFromBytes(getTokenValue());
>> > > > setTokenType();
>> > > >
>> > > > There is a commented out "decode(ByteBuffer)" method that contains
>> > > > code that does this for a supplied ByteBuffer value. Should this
>> > > > method be called implicitly by the AdToken code somehow? Or is it
>> > > > up to the client code to call decode on KrbToken?
>> > > >
>> > > > Colm.
>> > > >
>> > > >
>> > > >
>> > > > >
>> > > > > Thanks
>> > > > > Jiajia
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> > > > > Sent: Wednesday, June 28, 2017 5:41 PM
>> > > > > To: Li, Jiajia <ji...@intel.com>
>> > > > > Cc: kerby@directory.apache.org
>> > > > > Subject: Re: Kerby JWT support
>> > > > >
>> > > > > Hi Jiajia,
>> > > > >
>> > > > > On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia
>> > > > > <ji...@intel.com>
>> > > wrote:
>> > > > >
>> > > > > >
>> > > > > > 2) Do you mean if the credential cache is null or not set, we
>> > > > > > can skip the step to store the TGT ticket to credential cache?
>> > > > > >
>> > > > >
>> > > > > Yes exactly. "tgtTicket" is stored as a variable in the
>> > > > > TokenAuthLoginModule so we may not need the credential cache at
>> all.
>> > > > > If you agree I will fix this.
>> > > > >
>> > > > >
>> > > > > > 3) We get the armor key from armor cache, do you mean to set
>> > > > > > the armor key in client and KDC to replace the armor cache?
>> > > > > >
>> > > > >
>> > > > > No, I want to find a way to avoid having an armor key at all. If
>> > > > > the purpose of the armor key is to encrypt the communication
>> > > > > with the KDC, then if the JWT token is encrypted this
>> > > > > requirement is not
>> > > necessary.
>> > > > > But perhaps it's not possible to skip this step?
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > 4) I thinks it's great to put claims from the JWT token into
>> > > > > > the authorization data of the ticket, that will be an
>> > > > > > important
>> > feature.
>> > > > > >
>> > > > >
>> > > > > OK I have created a JIRA for this.
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > 5) Actually, AuthorizationData is not really set in the
>> > > > > > EncTicketPart, in AbstractIdentityBackend with the following
>> > > > > implementation:
>> > > > > > protected AuthorizationData doGetIdentityAuthorizationData(
>> > > > > > Object kdcRequest, EncTicketPart encTicketPart)
>> > > > > > throws KrbException {
>> > > > > > return null;
>> > > > > > }
>> > > > > >
>> > > > >
>> > > > > Right, but I am doing this locally. The problem is on the client
>> > > > > side that "tkt.getTicket().getEncPart()" is null. How can I see
>> > > > > what the authorization data of the ticket is on the client side,
>> > > > > so that I can test that it was inserted correctly?
>> > > > >
>> > > > > Colm.
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > Thanks
>> > > > > > Jiajia
>> > > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> > > > > > Sent: Monday, June 19, 2017 8:24 PM
>> > > > > > To: kerby@directory.apache.org
>> > > > > > Subject: Kerby JWT support
>> > > > > >
>> > > > > > Hi all,
>> > > > > >
>> > > > > > I'd like to resurrect some of the issues surrounding the JWT
>> > > > > > support in Kerby. If nothing else we can hopefully agree on
>> > > > > > what the outstanding issues are and then put them into JIRA so
>> > > > > > that we have a record of what needs to be done. Some of the
>> > > > > > tasks are fairly trivial and could be addressed for the next
>> release.
>> > > > > >
>> > > > > > 1) There was a proposal last year to move the
>> > > > > > TokenAuthLoginModule from the "integration-test" module into
>> > > > > > the "kerb-client" module in a separate package like 'jaas'.
>> > > > > >
>> > > > > > 2) I'd like to make the credential cache configuration item in
>> > > > > > the TokenAuthLoginModule optional to simplify the configuration.
>> > > > > > It's not actually needed as we just keep the TgtTicket
>> > > > > > internally in the LoginModule anyway.
>> > > > > >
>> > > > > > 3) Right now, we need an armor cache to then get a TGT using a
>> JWT.
>> > > > > > However, I think we should also support configuring the KDC
>> > > > > > with a private decryption key. If the incoming JWT token is
>> > > > > > encrypted to the KDC then we should be able to skip the armor
>> cache step.
>> > > > > >
>> > > > > > 4) For the access token case, make it possible to put claims
>> > > > > > from the JWT token into the authorization data of the ticket.
>> > > > > > I've done some work on this last year that could be re-used.
>> > > > > >
>> > > > > > 5) To test (4), I'd like to be able to query the authorization
>> > > > > > data of the issued service ticket. However, using the Kerby
>> > > > > > API, the following returns null?
>> > > > > >
>> > > > > > tkt.getTicket().getEncPart() (.getAuthorizationData())
>> > > > > >
>> > > > > > Is there a way for me to access the authorization data of the
>> > > > > > ticket using the Kerby API in some way to check that it's
>> > > > > > actually getting inserted properly?
>> > > > > >
>> > > > > > Thoughts? Am I missing anything else?
>> > > > > >
>> > > > > > 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
>> > >
>> >
>> >
>> >
>> > --
>> > 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: Kerby JWT support
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok this is done, please take a look and let me know what you think.
Colm.
On Wed, Jul 5, 2017 at 12:12 AM, Li, Jiajia <ji...@intel.com> wrote:
> > Maybe we could create a new class in kerb-core that encapsulates some of
> these things that could
> > be used instead?
>
> It's a good idea.
>
> Thanks
> Jiajia
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Tuesday, July 4, 2017 9:54 PM
> To: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> The problem with this is that it might be too restrictive. What if you
> wanted access to the client principal or the client address etc. when
> creating the AuthorizationData? Maybe we could create a new class in
> kerb-core that encapsulates some of these things that could be used instead?
>
> Colm.
>
> On Tue, Jul 4, 2017 at 1:38 PM, Li, Jiajia <ji...@intel.com> wrote:
>
> > > Currently I'm using "kdcRequest.isToken()" and "kdcRequest.getToken()".
> > I guess we could change
> > > the method to just take the kdcRequest.getToken()?
> >
> > Yes, set the AuthToken as the parameter of
> > getIdentityAuthorizationData is a good choice.
> >
> > Thanks
> > Jiajia
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Tuesday, July 4, 2017 4:03 PM
> > To: kerby@directory.apache.org
> > Subject: Re: Kerby JWT support
> >
> > On Tue, Jul 4, 2017 at 3:16 AM, Li, Jiajia <ji...@intel.com> wrote:
> >
> > >
> > > Which information in KdcRequest is used? I think the KdcRequest can
> > > be replaced by some class really used in getting AuthorizationData.
> > >
> >
> > Currently I'm using "kdcRequest.isToken()" and
> > "kdcRequest.getToken()". I guess we could change the method to just take
> the kdcRequest.getToken()?
> >
> > Colm.
> >
> >
> > >
> > > >b) In my tests, I'm just defining a custom AuthorizationType
> > > (AD_TOKEN(256)). What should I use here instead? I don't think the
> > > spec defines what it should be...
> > >
> > > I think the AD token type is a new type which undefined in
> > > spec(RFC4120->7.5.4. Authorization Data Types), I think this new
> > > type name is ok.
> > >
> > > Thanks
> > > Jiajia
> > >
> > >
> > > -----Original Message-----
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Monday, July 3, 2017 6:18 PM
> > > To: kerby@directory.apache.org
> > > Subject: Re: Kerby JWT support
> > >
> > > OK thanks, I managed to figure it out anyway. I have two more
> > > questions on this topic WRT DIRKRB-632:
> > >
> > > a) I want to add the authorization data in the relevant method in
> > > AbstractIdentityBackend. However, the problem here is that the
> > > kerb-identity module does not have kerb-server as a dependency, and
> > > hence I can't reference KdcRequest. The AbstractIdentityBackend gets
> > > around this by using "Object" instead of KdcRequest in the method
> > > signature, which is not a great idea really.
> > >
> > > What is the best way of handling this?
> > >
> > > b) In my tests, I'm just defining a custom AuthorizationType
> > > (AD_TOKEN(256)). What should I use here instead? I don't think the
> > > spec defines what it should be...
> > >
> > > Colm.
> > >
> > >
> > > On Mon, Jul 3, 2017 at 1:49 AM, Li, Jiajia <ji...@intel.com>
> wrote:
> > >
> > > > >The question I have here is that the KrbToken needs to call the
> > > > >following
> > > > code internally somehow:
> > > >
> > > > >this.innerToken =
> > > > >getTokenDecoder().decodeFromBytes(getTokenValue());
> > > > >setTokenType();
> > > >
> > > > >There is a commented out "decode(ByteBuffer)" method that
> > > > >contains code
> > > > that does this for a supplied ByteBuffer value. Should this method
> > > > be called implicitly by
> > > > >the AdToken code somehow? Or is it up to the client code to call
> > > > >decode
> > > > on KrbToken?
> > > >
> > > > I'm not very sure, I think it's up to the client code to call to
> > > > decode the KrbToken.
> > > >
> > > > Thanks
> > > > Jiajia
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > Sent: Friday, June 30, 2017 5:46 PM
> > > > To: kerby@directory.apache.org
> > > > Subject: Re: Kerby JWT support
> > > >
> > > > On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com>
> > wrote:
> > > >
> > > > >
> > > > > Yes, agree with you, credential cache it not really needed.
> > > > >
> > > > >
> > > > OK I have committed this fix.
> > > >
> > > >
> > > > > The EncTicketPart should be unseal, I think the following code
> > > > > could help you.
> > > > >
> > > > > Ticket ticket = apReq.getTicket();
> > > > > EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> > > > > etEncryptedEncPart(),
> > > > > encKey, KeyUsage.KDC_REP_TICKET,
> > EncTicketPart.class);
> > > > > ticket.setEncPart(encPart);
> > > > >
> > > >
> > > > It does, thanks! I have it kind of working now with a few hacks. I
> > > > can get the KrbToken from the AuthorizationData now as follows:
> > > >
> > > > AuthorizationData authzData = encPart.getAuthorizationData();
> > > > AuthorizationDataEntry dataEntry = authzData.getElements().
> > > > iterator().next();
> > > > AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
> > > > KrbToken decodedKrbToken = token.getToken();
> > > >
> > > > The question I have here is that the KrbToken needs to call the
> > > > following code internally somehow:
> > > >
> > > > this.innerToken =
> > > > getTokenDecoder().decodeFromBytes(getTokenValue());
> > > > setTokenType();
> > > >
> > > > There is a commented out "decode(ByteBuffer)" method that contains
> > > > code that does this for a supplied ByteBuffer value. Should this
> > > > method be called implicitly by the AdToken code somehow? Or is it
> > > > up to the client code to call decode on KrbToken?
> > > >
> > > > Colm.
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks
> > > > > Jiajia
> > > > >
> > > > > -----Original Message-----
> > > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > > Sent: Wednesday, June 28, 2017 5:41 PM
> > > > > To: Li, Jiajia <ji...@intel.com>
> > > > > Cc: kerby@directory.apache.org
> > > > > Subject: Re: Kerby JWT support
> > > > >
> > > > > Hi Jiajia,
> > > > >
> > > > > On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia
> > > > > <ji...@intel.com>
> > > wrote:
> > > > >
> > > > > >
> > > > > > 2) Do you mean if the credential cache is null or not set, we
> > > > > > can skip the step to store the TGT ticket to credential cache?
> > > > > >
> > > > >
> > > > > Yes exactly. "tgtTicket" is stored as a variable in the
> > > > > TokenAuthLoginModule so we may not need the credential cache at
> all.
> > > > > If you agree I will fix this.
> > > > >
> > > > >
> > > > > > 3) We get the armor key from armor cache, do you mean to set
> > > > > > the armor key in client and KDC to replace the armor cache?
> > > > > >
> > > > >
> > > > > No, I want to find a way to avoid having an armor key at all. If
> > > > > the purpose of the armor key is to encrypt the communication
> > > > > with the KDC, then if the JWT token is encrypted this
> > > > > requirement is not
> > > necessary.
> > > > > But perhaps it's not possible to skip this step?
> > > > >
> > > > >
> > > > > >
> > > > > > 4) I thinks it's great to put claims from the JWT token into
> > > > > > the authorization data of the ticket, that will be an
> > > > > > important
> > feature.
> > > > > >
> > > > >
> > > > > OK I have created a JIRA for this.
> > > > >
> > > > >
> > > > > >
> > > > > > 5) Actually, AuthorizationData is not really set in the
> > > > > > EncTicketPart, in AbstractIdentityBackend with the following
> > > > > implementation:
> > > > > > protected AuthorizationData doGetIdentityAuthorizationData(
> > > > > > Object kdcRequest, EncTicketPart encTicketPart)
> > > > > > throws KrbException {
> > > > > > return null;
> > > > > > }
> > > > > >
> > > > >
> > > > > Right, but I am doing this locally. The problem is on the client
> > > > > side that "tkt.getTicket().getEncPart()" is null. How can I see
> > > > > what the authorization data of the ticket is on the client side,
> > > > > so that I can test that it was inserted correctly?
> > > > >
> > > > > Colm.
> > > > >
> > > > >
> > > > > >
> > > > > > Thanks
> > > > > > Jiajia
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > > > Sent: Monday, June 19, 2017 8:24 PM
> > > > > > To: kerby@directory.apache.org
> > > > > > Subject: Kerby JWT support
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I'd like to resurrect some of the issues surrounding the JWT
> > > > > > support in Kerby. If nothing else we can hopefully agree on
> > > > > > what the outstanding issues are and then put them into JIRA so
> > > > > > that we have a record of what needs to be done. Some of the
> > > > > > tasks are fairly trivial and could be addressed for the next
> release.
> > > > > >
> > > > > > 1) There was a proposal last year to move the
> > > > > > TokenAuthLoginModule from the "integration-test" module into
> > > > > > the "kerb-client" module in a separate package like 'jaas'.
> > > > > >
> > > > > > 2) I'd like to make the credential cache configuration item in
> > > > > > the TokenAuthLoginModule optional to simplify the configuration.
> > > > > > It's not actually needed as we just keep the TgtTicket
> > > > > > internally in the LoginModule anyway.
> > > > > >
> > > > > > 3) Right now, we need an armor cache to then get a TGT using a
> JWT.
> > > > > > However, I think we should also support configuring the KDC
> > > > > > with a private decryption key. If the incoming JWT token is
> > > > > > encrypted to the KDC then we should be able to skip the armor
> cache step.
> > > > > >
> > > > > > 4) For the access token case, make it possible to put claims
> > > > > > from the JWT token into the authorization data of the ticket.
> > > > > > I've done some work on this last year that could be re-used.
> > > > > >
> > > > > > 5) To test (4), I'd like to be able to query the authorization
> > > > > > data of the issued service ticket. However, using the Kerby
> > > > > > API, the following returns null?
> > > > > >
> > > > > > tkt.getTicket().getEncPart() (.getAuthorizationData())
> > > > > >
> > > > > > Is there a way for me to access the authorization data of the
> > > > > > ticket using the Kerby API in some way to check that it's
> > > > > > actually getting inserted properly?
> > > > > >
> > > > > > Thoughts? Am I missing anything else?
> > > > > >
> > > > > > 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
> > >
> >
> >
> >
> > --
> > 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: Kerby JWT support
Posted by "Li, Jiajia" <ji...@intel.com>.
> Maybe we could create a new class in kerb-core that encapsulates some of these things that could
> be used instead?
It's a good idea.
Thanks
Jiajia
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, July 4, 2017 9:54 PM
To: kerby@directory.apache.org
Subject: Re: Kerby JWT support
The problem with this is that it might be too restrictive. What if you wanted access to the client principal or the client address etc. when creating the AuthorizationData? Maybe we could create a new class in kerb-core that encapsulates some of these things that could be used instead?
Colm.
On Tue, Jul 4, 2017 at 1:38 PM, Li, Jiajia <ji...@intel.com> wrote:
> > Currently I'm using "kdcRequest.isToken()" and "kdcRequest.getToken()".
> I guess we could change
> > the method to just take the kdcRequest.getToken()?
>
> Yes, set the AuthToken as the parameter of
> getIdentityAuthorizationData is a good choice.
>
> Thanks
> Jiajia
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Tuesday, July 4, 2017 4:03 PM
> To: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> On Tue, Jul 4, 2017 at 3:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> >
> > Which information in KdcRequest is used? I think the KdcRequest can
> > be replaced by some class really used in getting AuthorizationData.
> >
>
> Currently I'm using "kdcRequest.isToken()" and
> "kdcRequest.getToken()". I guess we could change the method to just take the kdcRequest.getToken()?
>
> Colm.
>
>
> >
> > >b) In my tests, I'm just defining a custom AuthorizationType
> > (AD_TOKEN(256)). What should I use here instead? I don't think the
> > spec defines what it should be...
> >
> > I think the AD token type is a new type which undefined in
> > spec(RFC4120->7.5.4. Authorization Data Types), I think this new
> > type name is ok.
> >
> > Thanks
> > Jiajia
> >
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, July 3, 2017 6:18 PM
> > To: kerby@directory.apache.org
> > Subject: Re: Kerby JWT support
> >
> > OK thanks, I managed to figure it out anyway. I have two more
> > questions on this topic WRT DIRKRB-632:
> >
> > a) I want to add the authorization data in the relevant method in
> > AbstractIdentityBackend. However, the problem here is that the
> > kerb-identity module does not have kerb-server as a dependency, and
> > hence I can't reference KdcRequest. The AbstractIdentityBackend gets
> > around this by using "Object" instead of KdcRequest in the method
> > signature, which is not a great idea really.
> >
> > What is the best way of handling this?
> >
> > b) In my tests, I'm just defining a custom AuthorizationType
> > (AD_TOKEN(256)). What should I use here instead? I don't think the
> > spec defines what it should be...
> >
> > Colm.
> >
> >
> > On Mon, Jul 3, 2017 at 1:49 AM, Li, Jiajia <ji...@intel.com> wrote:
> >
> > > >The question I have here is that the KrbToken needs to call the
> > > >following
> > > code internally somehow:
> > >
> > > >this.innerToken =
> > > >getTokenDecoder().decodeFromBytes(getTokenValue());
> > > >setTokenType();
> > >
> > > >There is a commented out "decode(ByteBuffer)" method that
> > > >contains code
> > > that does this for a supplied ByteBuffer value. Should this method
> > > be called implicitly by
> > > >the AdToken code somehow? Or is it up to the client code to call
> > > >decode
> > > on KrbToken?
> > >
> > > I'm not very sure, I think it's up to the client code to call to
> > > decode the KrbToken.
> > >
> > > Thanks
> > > Jiajia
> > >
> > >
> > > -----Original Message-----
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Friday, June 30, 2017 5:46 PM
> > > To: kerby@directory.apache.org
> > > Subject: Re: Kerby JWT support
> > >
> > > On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com>
> wrote:
> > >
> > > >
> > > > Yes, agree with you, credential cache it not really needed.
> > > >
> > > >
> > > OK I have committed this fix.
> > >
> > >
> > > > The EncTicketPart should be unseal, I think the following code
> > > > could help you.
> > > >
> > > > Ticket ticket = apReq.getTicket();
> > > > EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> > > > etEncryptedEncPart(),
> > > > encKey, KeyUsage.KDC_REP_TICKET,
> EncTicketPart.class);
> > > > ticket.setEncPart(encPart);
> > > >
> > >
> > > It does, thanks! I have it kind of working now with a few hacks. I
> > > can get the KrbToken from the AuthorizationData now as follows:
> > >
> > > AuthorizationData authzData = encPart.getAuthorizationData();
> > > AuthorizationDataEntry dataEntry = authzData.getElements().
> > > iterator().next();
> > > AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
> > > KrbToken decodedKrbToken = token.getToken();
> > >
> > > The question I have here is that the KrbToken needs to call the
> > > following code internally somehow:
> > >
> > > this.innerToken =
> > > getTokenDecoder().decodeFromBytes(getTokenValue());
> > > setTokenType();
> > >
> > > There is a commented out "decode(ByteBuffer)" method that contains
> > > code that does this for a supplied ByteBuffer value. Should this
> > > method be called implicitly by the AdToken code somehow? Or is it
> > > up to the client code to call decode on KrbToken?
> > >
> > > Colm.
> > >
> > >
> > >
> > > >
> > > > Thanks
> > > > Jiajia
> > > >
> > > > -----Original Message-----
> > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > Sent: Wednesday, June 28, 2017 5:41 PM
> > > > To: Li, Jiajia <ji...@intel.com>
> > > > Cc: kerby@directory.apache.org
> > > > Subject: Re: Kerby JWT support
> > > >
> > > > Hi Jiajia,
> > > >
> > > > On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia
> > > > <ji...@intel.com>
> > wrote:
> > > >
> > > > >
> > > > > 2) Do you mean if the credential cache is null or not set, we
> > > > > can skip the step to store the TGT ticket to credential cache?
> > > > >
> > > >
> > > > Yes exactly. "tgtTicket" is stored as a variable in the
> > > > TokenAuthLoginModule so we may not need the credential cache at all.
> > > > If you agree I will fix this.
> > > >
> > > >
> > > > > 3) We get the armor key from armor cache, do you mean to set
> > > > > the armor key in client and KDC to replace the armor cache?
> > > > >
> > > >
> > > > No, I want to find a way to avoid having an armor key at all. If
> > > > the purpose of the armor key is to encrypt the communication
> > > > with the KDC, then if the JWT token is encrypted this
> > > > requirement is not
> > necessary.
> > > > But perhaps it's not possible to skip this step?
> > > >
> > > >
> > > > >
> > > > > 4) I thinks it's great to put claims from the JWT token into
> > > > > the authorization data of the ticket, that will be an
> > > > > important
> feature.
> > > > >
> > > >
> > > > OK I have created a JIRA for this.
> > > >
> > > >
> > > > >
> > > > > 5) Actually, AuthorizationData is not really set in the
> > > > > EncTicketPart, in AbstractIdentityBackend with the following
> > > > implementation:
> > > > > protected AuthorizationData doGetIdentityAuthorizationData(
> > > > > Object kdcRequest, EncTicketPart encTicketPart)
> > > > > throws KrbException {
> > > > > return null;
> > > > > }
> > > > >
> > > >
> > > > Right, but I am doing this locally. The problem is on the client
> > > > side that "tkt.getTicket().getEncPart()" is null. How can I see
> > > > what the authorization data of the ticket is on the client side,
> > > > so that I can test that it was inserted correctly?
> > > >
> > > > Colm.
> > > >
> > > >
> > > > >
> > > > > Thanks
> > > > > Jiajia
> > > > >
> > > > > -----Original Message-----
> > > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > > Sent: Monday, June 19, 2017 8:24 PM
> > > > > To: kerby@directory.apache.org
> > > > > Subject: Kerby JWT support
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I'd like to resurrect some of the issues surrounding the JWT
> > > > > support in Kerby. If nothing else we can hopefully agree on
> > > > > what the outstanding issues are and then put them into JIRA so
> > > > > that we have a record of what needs to be done. Some of the
> > > > > tasks are fairly trivial and could be addressed for the next release.
> > > > >
> > > > > 1) There was a proposal last year to move the
> > > > > TokenAuthLoginModule from the "integration-test" module into
> > > > > the "kerb-client" module in a separate package like 'jaas'.
> > > > >
> > > > > 2) I'd like to make the credential cache configuration item in
> > > > > the TokenAuthLoginModule optional to simplify the configuration.
> > > > > It's not actually needed as we just keep the TgtTicket
> > > > > internally in the LoginModule anyway.
> > > > >
> > > > > 3) Right now, we need an armor cache to then get a TGT using a JWT.
> > > > > However, I think we should also support configuring the KDC
> > > > > with a private decryption key. If the incoming JWT token is
> > > > > encrypted to the KDC then we should be able to skip the armor cache step.
> > > > >
> > > > > 4) For the access token case, make it possible to put claims
> > > > > from the JWT token into the authorization data of the ticket.
> > > > > I've done some work on this last year that could be re-used.
> > > > >
> > > > > 5) To test (4), I'd like to be able to query the authorization
> > > > > data of the issued service ticket. However, using the Kerby
> > > > > API, the following returns null?
> > > > >
> > > > > tkt.getTicket().getEncPart() (.getAuthorizationData())
> > > > >
> > > > > Is there a way for me to access the authorization data of the
> > > > > ticket using the Kerby API in some way to check that it's
> > > > > actually getting inserted properly?
> > > > >
> > > > > Thoughts? Am I missing anything else?
> > > > >
> > > > > 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
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby JWT support
Posted by Colm O hEigeartaigh <co...@apache.org>.
The problem with this is that it might be too restrictive. What if you
wanted access to the client principal or the client address etc. when
creating the AuthorizationData? Maybe we could create a new class in
kerb-core that encapsulates some of these things that could be used instead?
Colm.
On Tue, Jul 4, 2017 at 1:38 PM, Li, Jiajia <ji...@intel.com> wrote:
> > Currently I'm using "kdcRequest.isToken()" and "kdcRequest.getToken()".
> I guess we could change
> > the method to just take the kdcRequest.getToken()?
>
> Yes, set the AuthToken as the parameter of getIdentityAuthorizationData is
> a good choice.
>
> Thanks
> Jiajia
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Tuesday, July 4, 2017 4:03 PM
> To: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> On Tue, Jul 4, 2017 at 3:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> >
> > Which information in KdcRequest is used? I think the KdcRequest can be
> > replaced by some class really used in getting AuthorizationData.
> >
>
> Currently I'm using "kdcRequest.isToken()" and "kdcRequest.getToken()". I
> guess we could change the method to just take the kdcRequest.getToken()?
>
> Colm.
>
>
> >
> > >b) In my tests, I'm just defining a custom AuthorizationType
> > (AD_TOKEN(256)). What should I use here instead? I don't think the
> > spec defines what it should be...
> >
> > I think the AD token type is a new type which undefined in
> > spec(RFC4120->7.5.4. Authorization Data Types), I think this new type
> > name is ok.
> >
> > Thanks
> > Jiajia
> >
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, July 3, 2017 6:18 PM
> > To: kerby@directory.apache.org
> > Subject: Re: Kerby JWT support
> >
> > OK thanks, I managed to figure it out anyway. I have two more
> > questions on this topic WRT DIRKRB-632:
> >
> > a) I want to add the authorization data in the relevant method in
> > AbstractIdentityBackend. However, the problem here is that the
> > kerb-identity module does not have kerb-server as a dependency, and
> > hence I can't reference KdcRequest. The AbstractIdentityBackend gets
> > around this by using "Object" instead of KdcRequest in the method
> > signature, which is not a great idea really.
> >
> > What is the best way of handling this?
> >
> > b) In my tests, I'm just defining a custom AuthorizationType
> > (AD_TOKEN(256)). What should I use here instead? I don't think the
> > spec defines what it should be...
> >
> > Colm.
> >
> >
> > On Mon, Jul 3, 2017 at 1:49 AM, Li, Jiajia <ji...@intel.com> wrote:
> >
> > > >The question I have here is that the KrbToken needs to call the
> > > >following
> > > code internally somehow:
> > >
> > > >this.innerToken =
> > > >getTokenDecoder().decodeFromBytes(getTokenValue());
> > > >setTokenType();
> > >
> > > >There is a commented out "decode(ByteBuffer)" method that contains
> > > >code
> > > that does this for a supplied ByteBuffer value. Should this method
> > > be called implicitly by
> > > >the AdToken code somehow? Or is it up to the client code to call
> > > >decode
> > > on KrbToken?
> > >
> > > I'm not very sure, I think it's up to the client code to call to
> > > decode the KrbToken.
> > >
> > > Thanks
> > > Jiajia
> > >
> > >
> > > -----Original Message-----
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Friday, June 30, 2017 5:46 PM
> > > To: kerby@directory.apache.org
> > > Subject: Re: Kerby JWT support
> > >
> > > On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com>
> wrote:
> > >
> > > >
> > > > Yes, agree with you, credential cache it not really needed.
> > > >
> > > >
> > > OK I have committed this fix.
> > >
> > >
> > > > The EncTicketPart should be unseal, I think the following code
> > > > could help you.
> > > >
> > > > Ticket ticket = apReq.getTicket();
> > > > EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> > > > etEncryptedEncPart(),
> > > > encKey, KeyUsage.KDC_REP_TICKET,
> EncTicketPart.class);
> > > > ticket.setEncPart(encPart);
> > > >
> > >
> > > It does, thanks! I have it kind of working now with a few hacks. I
> > > can get the KrbToken from the AuthorizationData now as follows:
> > >
> > > AuthorizationData authzData = encPart.getAuthorizationData();
> > > AuthorizationDataEntry dataEntry = authzData.getElements().
> > > iterator().next();
> > > AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
> > > KrbToken decodedKrbToken = token.getToken();
> > >
> > > The question I have here is that the KrbToken needs to call the
> > > following code internally somehow:
> > >
> > > this.innerToken =
> > > getTokenDecoder().decodeFromBytes(getTokenValue());
> > > setTokenType();
> > >
> > > There is a commented out "decode(ByteBuffer)" method that contains
> > > code that does this for a supplied ByteBuffer value. Should this
> > > method be called implicitly by the AdToken code somehow? Or is it up
> > > to the client code to call decode on KrbToken?
> > >
> > > Colm.
> > >
> > >
> > >
> > > >
> > > > Thanks
> > > > Jiajia
> > > >
> > > > -----Original Message-----
> > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > Sent: Wednesday, June 28, 2017 5:41 PM
> > > > To: Li, Jiajia <ji...@intel.com>
> > > > Cc: kerby@directory.apache.org
> > > > Subject: Re: Kerby JWT support
> > > >
> > > > Hi Jiajia,
> > > >
> > > > On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com>
> > wrote:
> > > >
> > > > >
> > > > > 2) Do you mean if the credential cache is null or not set, we
> > > > > can skip the step to store the TGT ticket to credential cache?
> > > > >
> > > >
> > > > Yes exactly. "tgtTicket" is stored as a variable in the
> > > > TokenAuthLoginModule so we may not need the credential cache at all.
> > > > If you agree I will fix this.
> > > >
> > > >
> > > > > 3) We get the armor key from armor cache, do you mean to set the
> > > > > armor key in client and KDC to replace the armor cache?
> > > > >
> > > >
> > > > No, I want to find a way to avoid having an armor key at all. If
> > > > the purpose of the armor key is to encrypt the communication with
> > > > the KDC, then if the JWT token is encrypted this requirement is
> > > > not
> > necessary.
> > > > But perhaps it's not possible to skip this step?
> > > >
> > > >
> > > > >
> > > > > 4) I thinks it's great to put claims from the JWT token into the
> > > > > authorization data of the ticket, that will be an important
> feature.
> > > > >
> > > >
> > > > OK I have created a JIRA for this.
> > > >
> > > >
> > > > >
> > > > > 5) Actually, AuthorizationData is not really set in the
> > > > > EncTicketPart, in AbstractIdentityBackend with the following
> > > > implementation:
> > > > > protected AuthorizationData doGetIdentityAuthorizationData(
> > > > > Object kdcRequest, EncTicketPart encTicketPart)
> > > > > throws KrbException {
> > > > > return null;
> > > > > }
> > > > >
> > > >
> > > > Right, but I am doing this locally. The problem is on the client
> > > > side that "tkt.getTicket().getEncPart()" is null. How can I see
> > > > what the authorization data of the ticket is on the client side,
> > > > so that I can test that it was inserted correctly?
> > > >
> > > > Colm.
> > > >
> > > >
> > > > >
> > > > > Thanks
> > > > > Jiajia
> > > > >
> > > > > -----Original Message-----
> > > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > > Sent: Monday, June 19, 2017 8:24 PM
> > > > > To: kerby@directory.apache.org
> > > > > Subject: Kerby JWT support
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I'd like to resurrect some of the issues surrounding the JWT
> > > > > support in Kerby. If nothing else we can hopefully agree on what
> > > > > the outstanding issues are and then put them into JIRA so that
> > > > > we have a record of what needs to be done. Some of the tasks are
> > > > > fairly trivial and could be addressed for the next release.
> > > > >
> > > > > 1) There was a proposal last year to move the
> > > > > TokenAuthLoginModule from the "integration-test" module into the
> > > > > "kerb-client" module in a separate package like 'jaas'.
> > > > >
> > > > > 2) I'd like to make the credential cache configuration item in
> > > > > the TokenAuthLoginModule optional to simplify the configuration.
> > > > > It's not actually needed as we just keep the TgtTicket
> > > > > internally in the LoginModule anyway.
> > > > >
> > > > > 3) Right now, we need an armor cache to then get a TGT using a JWT.
> > > > > However, I think we should also support configuring the KDC with
> > > > > a private decryption key. If the incoming JWT token is encrypted
> > > > > to the KDC then we should be able to skip the armor cache step.
> > > > >
> > > > > 4) For the access token case, make it possible to put claims
> > > > > from the JWT token into the authorization data of the ticket.
> > > > > I've done some work on this last year that could be re-used.
> > > > >
> > > > > 5) To test (4), I'd like to be able to query the authorization
> > > > > data of the issued service ticket. However, using the Kerby API,
> > > > > the following returns null?
> > > > >
> > > > > tkt.getTicket().getEncPart() (.getAuthorizationData())
> > > > >
> > > > > Is there a way for me to access the authorization data of the
> > > > > ticket using the Kerby API in some way to check that it's
> > > > > actually getting inserted properly?
> > > > >
> > > > > Thoughts? Am I missing anything else?
> > > > >
> > > > > 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
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby JWT support
Posted by "Li, Jiajia" <ji...@intel.com>.
> Currently I'm using "kdcRequest.isToken()" and "kdcRequest.getToken()". I guess we could change
> the method to just take the kdcRequest.getToken()?
Yes, set the AuthToken as the parameter of getIdentityAuthorizationData is a good choice.
Thanks
Jiajia
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, July 4, 2017 4:03 PM
To: kerby@directory.apache.org
Subject: Re: Kerby JWT support
On Tue, Jul 4, 2017 at 3:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> Which information in KdcRequest is used? I think the KdcRequest can be
> replaced by some class really used in getting AuthorizationData.
>
Currently I'm using "kdcRequest.isToken()" and "kdcRequest.getToken()". I guess we could change the method to just take the kdcRequest.getToken()?
Colm.
>
> >b) In my tests, I'm just defining a custom AuthorizationType
> (AD_TOKEN(256)). What should I use here instead? I don't think the
> spec defines what it should be...
>
> I think the AD token type is a new type which undefined in
> spec(RFC4120->7.5.4. Authorization Data Types), I think this new type
> name is ok.
>
> Thanks
> Jiajia
>
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Monday, July 3, 2017 6:18 PM
> To: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> OK thanks, I managed to figure it out anyway. I have two more
> questions on this topic WRT DIRKRB-632:
>
> a) I want to add the authorization data in the relevant method in
> AbstractIdentityBackend. However, the problem here is that the
> kerb-identity module does not have kerb-server as a dependency, and
> hence I can't reference KdcRequest. The AbstractIdentityBackend gets
> around this by using "Object" instead of KdcRequest in the method
> signature, which is not a great idea really.
>
> What is the best way of handling this?
>
> b) In my tests, I'm just defining a custom AuthorizationType
> (AD_TOKEN(256)). What should I use here instead? I don't think the
> spec defines what it should be...
>
> Colm.
>
>
> On Mon, Jul 3, 2017 at 1:49 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> > >The question I have here is that the KrbToken needs to call the
> > >following
> > code internally somehow:
> >
> > >this.innerToken =
> > >getTokenDecoder().decodeFromBytes(getTokenValue());
> > >setTokenType();
> >
> > >There is a commented out "decode(ByteBuffer)" method that contains
> > >code
> > that does this for a supplied ByteBuffer value. Should this method
> > be called implicitly by
> > >the AdToken code somehow? Or is it up to the client code to call
> > >decode
> > on KrbToken?
> >
> > I'm not very sure, I think it's up to the client code to call to
> > decode the KrbToken.
> >
> > Thanks
> > Jiajia
> >
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Friday, June 30, 2017 5:46 PM
> > To: kerby@directory.apache.org
> > Subject: Re: Kerby JWT support
> >
> > On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com> wrote:
> >
> > >
> > > Yes, agree with you, credential cache it not really needed.
> > >
> > >
> > OK I have committed this fix.
> >
> >
> > > The EncTicketPart should be unseal, I think the following code
> > > could help you.
> > >
> > > Ticket ticket = apReq.getTicket();
> > > EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> > > etEncryptedEncPart(),
> > > encKey, KeyUsage.KDC_REP_TICKET, EncTicketPart.class);
> > > ticket.setEncPart(encPart);
> > >
> >
> > It does, thanks! I have it kind of working now with a few hacks. I
> > can get the KrbToken from the AuthorizationData now as follows:
> >
> > AuthorizationData authzData = encPart.getAuthorizationData();
> > AuthorizationDataEntry dataEntry = authzData.getElements().
> > iterator().next();
> > AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
> > KrbToken decodedKrbToken = token.getToken();
> >
> > The question I have here is that the KrbToken needs to call the
> > following code internally somehow:
> >
> > this.innerToken =
> > getTokenDecoder().decodeFromBytes(getTokenValue());
> > setTokenType();
> >
> > There is a commented out "decode(ByteBuffer)" method that contains
> > code that does this for a supplied ByteBuffer value. Should this
> > method be called implicitly by the AdToken code somehow? Or is it up
> > to the client code to call decode on KrbToken?
> >
> > Colm.
> >
> >
> >
> > >
> > > Thanks
> > > Jiajia
> > >
> > > -----Original Message-----
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Wednesday, June 28, 2017 5:41 PM
> > > To: Li, Jiajia <ji...@intel.com>
> > > Cc: kerby@directory.apache.org
> > > Subject: Re: Kerby JWT support
> > >
> > > Hi Jiajia,
> > >
> > > On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com>
> wrote:
> > >
> > > >
> > > > 2) Do you mean if the credential cache is null or not set, we
> > > > can skip the step to store the TGT ticket to credential cache?
> > > >
> > >
> > > Yes exactly. "tgtTicket" is stored as a variable in the
> > > TokenAuthLoginModule so we may not need the credential cache at all.
> > > If you agree I will fix this.
> > >
> > >
> > > > 3) We get the armor key from armor cache, do you mean to set the
> > > > armor key in client and KDC to replace the armor cache?
> > > >
> > >
> > > No, I want to find a way to avoid having an armor key at all. If
> > > the purpose of the armor key is to encrypt the communication with
> > > the KDC, then if the JWT token is encrypted this requirement is
> > > not
> necessary.
> > > But perhaps it's not possible to skip this step?
> > >
> > >
> > > >
> > > > 4) I thinks it's great to put claims from the JWT token into the
> > > > authorization data of the ticket, that will be an important feature.
> > > >
> > >
> > > OK I have created a JIRA for this.
> > >
> > >
> > > >
> > > > 5) Actually, AuthorizationData is not really set in the
> > > > EncTicketPart, in AbstractIdentityBackend with the following
> > > implementation:
> > > > protected AuthorizationData doGetIdentityAuthorizationData(
> > > > Object kdcRequest, EncTicketPart encTicketPart)
> > > > throws KrbException {
> > > > return null;
> > > > }
> > > >
> > >
> > > Right, but I am doing this locally. The problem is on the client
> > > side that "tkt.getTicket().getEncPart()" is null. How can I see
> > > what the authorization data of the ticket is on the client side,
> > > so that I can test that it was inserted correctly?
> > >
> > > Colm.
> > >
> > >
> > > >
> > > > Thanks
> > > > Jiajia
> > > >
> > > > -----Original Message-----
> > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > Sent: Monday, June 19, 2017 8:24 PM
> > > > To: kerby@directory.apache.org
> > > > Subject: Kerby JWT support
> > > >
> > > > Hi all,
> > > >
> > > > I'd like to resurrect some of the issues surrounding the JWT
> > > > support in Kerby. If nothing else we can hopefully agree on what
> > > > the outstanding issues are and then put them into JIRA so that
> > > > we have a record of what needs to be done. Some of the tasks are
> > > > fairly trivial and could be addressed for the next release.
> > > >
> > > > 1) There was a proposal last year to move the
> > > > TokenAuthLoginModule from the "integration-test" module into the
> > > > "kerb-client" module in a separate package like 'jaas'.
> > > >
> > > > 2) I'd like to make the credential cache configuration item in
> > > > the TokenAuthLoginModule optional to simplify the configuration.
> > > > It's not actually needed as we just keep the TgtTicket
> > > > internally in the LoginModule anyway.
> > > >
> > > > 3) Right now, we need an armor cache to then get a TGT using a JWT.
> > > > However, I think we should also support configuring the KDC with
> > > > a private decryption key. If the incoming JWT token is encrypted
> > > > to the KDC then we should be able to skip the armor cache step.
> > > >
> > > > 4) For the access token case, make it possible to put claims
> > > > from the JWT token into the authorization data of the ticket.
> > > > I've done some work on this last year that could be re-used.
> > > >
> > > > 5) To test (4), I'd like to be able to query the authorization
> > > > data of the issued service ticket. However, using the Kerby API,
> > > > the following returns null?
> > > >
> > > > tkt.getTicket().getEncPart() (.getAuthorizationData())
> > > >
> > > > Is there a way for me to access the authorization data of the
> > > > ticket using the Kerby API in some way to check that it's
> > > > actually getting inserted properly?
> > > >
> > > > Thoughts? Am I missing anything else?
> > > >
> > > > 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
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby JWT support
Posted by Colm O hEigeartaigh <co...@apache.org>.
On Tue, Jul 4, 2017 at 3:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> Which information in KdcRequest is used? I think the KdcRequest can be
> replaced by some class really used in getting AuthorizationData.
>
Currently I'm using "kdcRequest.isToken()" and "kdcRequest.getToken()". I
guess we could change the method to just take the kdcRequest.getToken()?
Colm.
>
> >b) In my tests, I'm just defining a custom AuthorizationType
> (AD_TOKEN(256)). What should I use here instead? I don't think the spec
> defines what it should be...
>
> I think the AD token type is a new type which undefined in
> spec(RFC4120->7.5.4. Authorization Data Types), I think this new type name
> is ok.
>
> Thanks
> Jiajia
>
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Monday, July 3, 2017 6:18 PM
> To: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> OK thanks, I managed to figure it out anyway. I have two more questions on
> this topic WRT DIRKRB-632:
>
> a) I want to add the authorization data in the relevant method in
> AbstractIdentityBackend. However, the problem here is that the
> kerb-identity module does not have kerb-server as a dependency, and hence I
> can't reference KdcRequest. The AbstractIdentityBackend gets around this by
> using "Object" instead of KdcRequest in the method signature, which is not
> a great idea really.
>
> What is the best way of handling this?
>
> b) In my tests, I'm just defining a custom AuthorizationType
> (AD_TOKEN(256)). What should I use here instead? I don't think the spec
> defines what it should be...
>
> Colm.
>
>
> On Mon, Jul 3, 2017 at 1:49 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> > >The question I have here is that the KrbToken needs to call the
> > >following
> > code internally somehow:
> >
> > >this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
> > >setTokenType();
> >
> > >There is a commented out "decode(ByteBuffer)" method that contains
> > >code
> > that does this for a supplied ByteBuffer value. Should this method be
> > called implicitly by
> > >the AdToken code somehow? Or is it up to the client code to call
> > >decode
> > on KrbToken?
> >
> > I'm not very sure, I think it's up to the client code to call to
> > decode the KrbToken.
> >
> > Thanks
> > Jiajia
> >
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Friday, June 30, 2017 5:46 PM
> > To: kerby@directory.apache.org
> > Subject: Re: Kerby JWT support
> >
> > On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com> wrote:
> >
> > >
> > > Yes, agree with you, credential cache it not really needed.
> > >
> > >
> > OK I have committed this fix.
> >
> >
> > > The EncTicketPart should be unseal, I think the following code could
> > > help you.
> > >
> > > Ticket ticket = apReq.getTicket();
> > > EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> > > etEncryptedEncPart(),
> > > encKey, KeyUsage.KDC_REP_TICKET, EncTicketPart.class);
> > > ticket.setEncPart(encPart);
> > >
> >
> > It does, thanks! I have it kind of working now with a few hacks. I can
> > get the KrbToken from the AuthorizationData now as follows:
> >
> > AuthorizationData authzData = encPart.getAuthorizationData();
> > AuthorizationDataEntry dataEntry = authzData.getElements().
> > iterator().next();
> > AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
> > KrbToken decodedKrbToken = token.getToken();
> >
> > The question I have here is that the KrbToken needs to call the
> > following code internally somehow:
> >
> > this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
> > setTokenType();
> >
> > There is a commented out "decode(ByteBuffer)" method that contains
> > code that does this for a supplied ByteBuffer value. Should this
> > method be called implicitly by the AdToken code somehow? Or is it up
> > to the client code to call decode on KrbToken?
> >
> > Colm.
> >
> >
> >
> > >
> > > Thanks
> > > Jiajia
> > >
> > > -----Original Message-----
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Wednesday, June 28, 2017 5:41 PM
> > > To: Li, Jiajia <ji...@intel.com>
> > > Cc: kerby@directory.apache.org
> > > Subject: Re: Kerby JWT support
> > >
> > > Hi Jiajia,
> > >
> > > On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com>
> wrote:
> > >
> > > >
> > > > 2) Do you mean if the credential cache is null or not set, we can
> > > > skip the step to store the TGT ticket to credential cache?
> > > >
> > >
> > > Yes exactly. "tgtTicket" is stored as a variable in the
> > > TokenAuthLoginModule so we may not need the credential cache at all.
> > > If you agree I will fix this.
> > >
> > >
> > > > 3) We get the armor key from armor cache, do you mean to set the
> > > > armor key in client and KDC to replace the armor cache?
> > > >
> > >
> > > No, I want to find a way to avoid having an armor key at all. If the
> > > purpose of the armor key is to encrypt the communication with the
> > > KDC, then if the JWT token is encrypted this requirement is not
> necessary.
> > > But perhaps it's not possible to skip this step?
> > >
> > >
> > > >
> > > > 4) I thinks it's great to put claims from the JWT token into the
> > > > authorization data of the ticket, that will be an important feature.
> > > >
> > >
> > > OK I have created a JIRA for this.
> > >
> > >
> > > >
> > > > 5) Actually, AuthorizationData is not really set in the
> > > > EncTicketPart, in AbstractIdentityBackend with the following
> > > implementation:
> > > > protected AuthorizationData doGetIdentityAuthorizationData(
> > > > Object kdcRequest, EncTicketPart encTicketPart)
> > > > throws KrbException {
> > > > return null;
> > > > }
> > > >
> > >
> > > Right, but I am doing this locally. The problem is on the client
> > > side that "tkt.getTicket().getEncPart()" is null. How can I see what
> > > the authorization data of the ticket is on the client side, so that
> > > I can test that it was inserted correctly?
> > >
> > > Colm.
> > >
> > >
> > > >
> > > > Thanks
> > > > Jiajia
> > > >
> > > > -----Original Message-----
> > > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > > Sent: Monday, June 19, 2017 8:24 PM
> > > > To: kerby@directory.apache.org
> > > > Subject: Kerby JWT support
> > > >
> > > > Hi all,
> > > >
> > > > I'd like to resurrect some of the issues surrounding the JWT
> > > > support in Kerby. If nothing else we can hopefully agree on what
> > > > the outstanding issues are and then put them into JIRA so that we
> > > > have a record of what needs to be done. Some of the tasks are
> > > > fairly trivial and could be addressed for the next release.
> > > >
> > > > 1) There was a proposal last year to move the TokenAuthLoginModule
> > > > from the "integration-test" module into the "kerb-client" module
> > > > in a separate package like 'jaas'.
> > > >
> > > > 2) I'd like to make the credential cache configuration item in the
> > > > TokenAuthLoginModule optional to simplify the configuration. It's
> > > > not actually needed as we just keep the TgtTicket internally in
> > > > the LoginModule anyway.
> > > >
> > > > 3) Right now, we need an armor cache to then get a TGT using a JWT.
> > > > However, I think we should also support configuring the KDC with a
> > > > private decryption key. If the incoming JWT token is encrypted to
> > > > the KDC then we should be able to skip the armor cache step.
> > > >
> > > > 4) For the access token case, make it possible to put claims from
> > > > the JWT token into the authorization data of the ticket. I've done
> > > > some work on this last year that could be re-used.
> > > >
> > > > 5) To test (4), I'd like to be able to query the authorization
> > > > data of the issued service ticket. However, using the Kerby API,
> > > > the following returns null?
> > > >
> > > > tkt.getTicket().getEncPart() (.getAuthorizationData())
> > > >
> > > > Is there a way for me to access the authorization data of the
> > > > ticket using the Kerby API in some way to check that it's actually
> > > > getting inserted properly?
> > > >
> > > > Thoughts? Am I missing anything else?
> > > >
> > > > 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
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby JWT support
Posted by "Li, Jiajia" <ji...@intel.com>.
>a) I want to add the authorization data in the relevant method in AbstractIdentityBackend. However, the problem here is that the kerb-identity module does not
>have kerb-server as a dependency, and hence I can't reference KdcRequest. The AbstractIdentityBackend gets around this by using "Object" instead of KdcRequest in
>the method signature, which is not a great idea really.
>What is the best way of handling this?
Which information in KdcRequest is used? I think the KdcRequest can be replaced by some class really used in getting AuthorizationData.
>b) In my tests, I'm just defining a custom AuthorizationType (AD_TOKEN(256)). What should I use here instead? I don't think the spec defines what it should be...
I think the AD token type is a new type which undefined in spec(RFC4120->7.5.4. Authorization Data Types), I think this new type name is ok.
Thanks
Jiajia
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Monday, July 3, 2017 6:18 PM
To: kerby@directory.apache.org
Subject: Re: Kerby JWT support
OK thanks, I managed to figure it out anyway. I have two more questions on this topic WRT DIRKRB-632:
a) I want to add the authorization data in the relevant method in AbstractIdentityBackend. However, the problem here is that the kerb-identity module does not have kerb-server as a dependency, and hence I can't reference KdcRequest. The AbstractIdentityBackend gets around this by using "Object" instead of KdcRequest in the method signature, which is not a great idea really.
What is the best way of handling this?
b) In my tests, I'm just defining a custom AuthorizationType (AD_TOKEN(256)). What should I use here instead? I don't think the spec defines what it should be...
Colm.
On Mon, Jul 3, 2017 at 1:49 AM, Li, Jiajia <ji...@intel.com> wrote:
> >The question I have here is that the KrbToken needs to call the
> >following
> code internally somehow:
>
> >this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
> >setTokenType();
>
> >There is a commented out "decode(ByteBuffer)" method that contains
> >code
> that does this for a supplied ByteBuffer value. Should this method be
> called implicitly by
> >the AdToken code somehow? Or is it up to the client code to call
> >decode
> on KrbToken?
>
> I'm not very sure, I think it's up to the client code to call to
> decode the KrbToken.
>
> Thanks
> Jiajia
>
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, June 30, 2017 5:46 PM
> To: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> >
> > Yes, agree with you, credential cache it not really needed.
> >
> >
> OK I have committed this fix.
>
>
> > The EncTicketPart should be unseal, I think the following code could
> > help you.
> >
> > Ticket ticket = apReq.getTicket();
> > EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> > etEncryptedEncPart(),
> > encKey, KeyUsage.KDC_REP_TICKET, EncTicketPart.class);
> > ticket.setEncPart(encPart);
> >
>
> It does, thanks! I have it kind of working now with a few hacks. I can
> get the KrbToken from the AuthorizationData now as follows:
>
> AuthorizationData authzData = encPart.getAuthorizationData();
> AuthorizationDataEntry dataEntry = authzData.getElements().
> iterator().next();
> AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
> KrbToken decodedKrbToken = token.getToken();
>
> The question I have here is that the KrbToken needs to call the
> following code internally somehow:
>
> this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
> setTokenType();
>
> There is a commented out "decode(ByteBuffer)" method that contains
> code that does this for a supplied ByteBuffer value. Should this
> method be called implicitly by the AdToken code somehow? Or is it up
> to the client code to call decode on KrbToken?
>
> Colm.
>
>
>
> >
> > Thanks
> > Jiajia
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, June 28, 2017 5:41 PM
> > To: Li, Jiajia <ji...@intel.com>
> > Cc: kerby@directory.apache.org
> > Subject: Re: Kerby JWT support
> >
> > Hi Jiajia,
> >
> > On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com> wrote:
> >
> > >
> > > 2) Do you mean if the credential cache is null or not set, we can
> > > skip the step to store the TGT ticket to credential cache?
> > >
> >
> > Yes exactly. "tgtTicket" is stored as a variable in the
> > TokenAuthLoginModule so we may not need the credential cache at all.
> > If you agree I will fix this.
> >
> >
> > > 3) We get the armor key from armor cache, do you mean to set the
> > > armor key in client and KDC to replace the armor cache?
> > >
> >
> > No, I want to find a way to avoid having an armor key at all. If the
> > purpose of the armor key is to encrypt the communication with the
> > KDC, then if the JWT token is encrypted this requirement is not necessary.
> > But perhaps it's not possible to skip this step?
> >
> >
> > >
> > > 4) I thinks it's great to put claims from the JWT token into the
> > > authorization data of the ticket, that will be an important feature.
> > >
> >
> > OK I have created a JIRA for this.
> >
> >
> > >
> > > 5) Actually, AuthorizationData is not really set in the
> > > EncTicketPart, in AbstractIdentityBackend with the following
> > implementation:
> > > protected AuthorizationData doGetIdentityAuthorizationData(
> > > Object kdcRequest, EncTicketPart encTicketPart)
> > > throws KrbException {
> > > return null;
> > > }
> > >
> >
> > Right, but I am doing this locally. The problem is on the client
> > side that "tkt.getTicket().getEncPart()" is null. How can I see what
> > the authorization data of the ticket is on the client side, so that
> > I can test that it was inserted correctly?
> >
> > Colm.
> >
> >
> > >
> > > Thanks
> > > Jiajia
> > >
> > > -----Original Message-----
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Monday, June 19, 2017 8:24 PM
> > > To: kerby@directory.apache.org
> > > Subject: Kerby JWT support
> > >
> > > Hi all,
> > >
> > > I'd like to resurrect some of the issues surrounding the JWT
> > > support in Kerby. If nothing else we can hopefully agree on what
> > > the outstanding issues are and then put them into JIRA so that we
> > > have a record of what needs to be done. Some of the tasks are
> > > fairly trivial and could be addressed for the next release.
> > >
> > > 1) There was a proposal last year to move the TokenAuthLoginModule
> > > from the "integration-test" module into the "kerb-client" module
> > > in a separate package like 'jaas'.
> > >
> > > 2) I'd like to make the credential cache configuration item in the
> > > TokenAuthLoginModule optional to simplify the configuration. It's
> > > not actually needed as we just keep the TgtTicket internally in
> > > the LoginModule anyway.
> > >
> > > 3) Right now, we need an armor cache to then get a TGT using a JWT.
> > > However, I think we should also support configuring the KDC with a
> > > private decryption key. If the incoming JWT token is encrypted to
> > > the KDC then we should be able to skip the armor cache step.
> > >
> > > 4) For the access token case, make it possible to put claims from
> > > the JWT token into the authorization data of the ticket. I've done
> > > some work on this last year that could be re-used.
> > >
> > > 5) To test (4), I'd like to be able to query the authorization
> > > data of the issued service ticket. However, using the Kerby API,
> > > the following returns null?
> > >
> > > tkt.getTicket().getEncPart() (.getAuthorizationData())
> > >
> > > Is there a way for me to access the authorization data of the
> > > ticket using the Kerby API in some way to check that it's actually
> > > getting inserted properly?
> > >
> > > Thoughts? Am I missing anything else?
> > >
> > > 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: Kerby JWT support
Posted by Colm O hEigeartaigh <co...@apache.org>.
OK thanks, I managed to figure it out anyway. I have two more questions on
this topic WRT DIRKRB-632:
a) I want to add the authorization data in the relevant method in
AbstractIdentityBackend. However, the problem here is that the
kerb-identity module does not have kerb-server as a dependency, and hence I
can't reference KdcRequest. The AbstractIdentityBackend gets around this by
using "Object" instead of KdcRequest in the method signature, which is not
a great idea really.
What is the best way of handling this?
b) In my tests, I'm just defining a custom AuthorizationType
(AD_TOKEN(256)). What should I use here instead? I don't think the spec
defines what it should be...
Colm.
On Mon, Jul 3, 2017 at 1:49 AM, Li, Jiajia <ji...@intel.com> wrote:
> >The question I have here is that the KrbToken needs to call the following
> code internally somehow:
>
> >this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
> >setTokenType();
>
> >There is a commented out "decode(ByteBuffer)" method that contains code
> that does this for a supplied ByteBuffer value. Should this method be
> called implicitly by
> >the AdToken code somehow? Or is it up to the client code to call decode
> on KrbToken?
>
> I'm not very sure, I think it's up to the client code to call to decode
> the KrbToken.
>
> Thanks
> Jiajia
>
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, June 30, 2017 5:46 PM
> To: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> >
> > Yes, agree with you, credential cache it not really needed.
> >
> >
> OK I have committed this fix.
>
>
> > The EncTicketPart should be unseal, I think the following code could
> > help you.
> >
> > Ticket ticket = apReq.getTicket();
> > EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> > etEncryptedEncPart(),
> > encKey, KeyUsage.KDC_REP_TICKET, EncTicketPart.class);
> > ticket.setEncPart(encPart);
> >
>
> It does, thanks! I have it kind of working now with a few hacks. I can get
> the KrbToken from the AuthorizationData now as follows:
>
> AuthorizationData authzData = encPart.getAuthorizationData();
> AuthorizationDataEntry dataEntry = authzData.getElements().
> iterator().next();
> AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
> KrbToken decodedKrbToken = token.getToken();
>
> The question I have here is that the KrbToken needs to call the following
> code internally somehow:
>
> this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
> setTokenType();
>
> There is a commented out "decode(ByteBuffer)" method that contains code
> that does this for a supplied ByteBuffer value. Should this method be
> called implicitly by the AdToken code somehow? Or is it up to the client
> code to call decode on KrbToken?
>
> Colm.
>
>
>
> >
> > Thanks
> > Jiajia
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, June 28, 2017 5:41 PM
> > To: Li, Jiajia <ji...@intel.com>
> > Cc: kerby@directory.apache.org
> > Subject: Re: Kerby JWT support
> >
> > Hi Jiajia,
> >
> > On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com> wrote:
> >
> > >
> > > 2) Do you mean if the credential cache is null or not set, we can
> > > skip the step to store the TGT ticket to credential cache?
> > >
> >
> > Yes exactly. "tgtTicket" is stored as a variable in the
> > TokenAuthLoginModule so we may not need the credential cache at all.
> > If you agree I will fix this.
> >
> >
> > > 3) We get the armor key from armor cache, do you mean to set the
> > > armor key in client and KDC to replace the armor cache?
> > >
> >
> > No, I want to find a way to avoid having an armor key at all. If the
> > purpose of the armor key is to encrypt the communication with the KDC,
> > then if the JWT token is encrypted this requirement is not necessary.
> > But perhaps it's not possible to skip this step?
> >
> >
> > >
> > > 4) I thinks it's great to put claims from the JWT token into the
> > > authorization data of the ticket, that will be an important feature.
> > >
> >
> > OK I have created a JIRA for this.
> >
> >
> > >
> > > 5) Actually, AuthorizationData is not really set in the
> > > EncTicketPart, in AbstractIdentityBackend with the following
> > implementation:
> > > protected AuthorizationData doGetIdentityAuthorizationData(
> > > Object kdcRequest, EncTicketPart encTicketPart)
> > > throws KrbException {
> > > return null;
> > > }
> > >
> >
> > Right, but I am doing this locally. The problem is on the client side
> > that "tkt.getTicket().getEncPart()" is null. How can I see what the
> > authorization data of the ticket is on the client side, so that I can
> > test that it was inserted correctly?
> >
> > Colm.
> >
> >
> > >
> > > Thanks
> > > Jiajia
> > >
> > > -----Original Message-----
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Monday, June 19, 2017 8:24 PM
> > > To: kerby@directory.apache.org
> > > Subject: Kerby JWT support
> > >
> > > Hi all,
> > >
> > > I'd like to resurrect some of the issues surrounding the JWT support
> > > in Kerby. If nothing else we can hopefully agree on what the
> > > outstanding issues are and then put them into JIRA so that we have a
> > > record of what needs to be done. Some of the tasks are fairly
> > > trivial and could be addressed for the next release.
> > >
> > > 1) There was a proposal last year to move the TokenAuthLoginModule
> > > from the "integration-test" module into the "kerb-client" module in
> > > a separate package like 'jaas'.
> > >
> > > 2) I'd like to make the credential cache configuration item in the
> > > TokenAuthLoginModule optional to simplify the configuration. It's
> > > not actually needed as we just keep the TgtTicket internally in the
> > > LoginModule anyway.
> > >
> > > 3) Right now, we need an armor cache to then get a TGT using a JWT.
> > > However, I think we should also support configuring the KDC with a
> > > private decryption key. If the incoming JWT token is encrypted to
> > > the KDC then we should be able to skip the armor cache step.
> > >
> > > 4) For the access token case, make it possible to put claims from
> > > the JWT token into the authorization data of the ticket. I've done
> > > some work on this last year that could be re-used.
> > >
> > > 5) To test (4), I'd like to be able to query the authorization data
> > > of the issued service ticket. However, using the Kerby API, the
> > > following returns null?
> > >
> > > tkt.getTicket().getEncPart() (.getAuthorizationData())
> > >
> > > Is there a way for me to access the authorization data of the ticket
> > > using the Kerby API in some way to check that it's actually getting
> > > inserted properly?
> > >
> > > Thoughts? Am I missing anything else?
> > >
> > > 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: Kerby JWT support
Posted by "Li, Jiajia" <ji...@intel.com>.
>The question I have here is that the KrbToken needs to call the following code internally somehow:
>this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
>setTokenType();
>There is a commented out "decode(ByteBuffer)" method that contains code that does this for a supplied ByteBuffer value. Should this method be called implicitly by
>the AdToken code somehow? Or is it up to the client code to call decode on KrbToken?
I'm not very sure, I think it's up to the client code to call to decode the KrbToken.
Thanks
Jiajia
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, June 30, 2017 5:46 PM
To: kerby@directory.apache.org
Subject: Re: Kerby JWT support
On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> Yes, agree with you, credential cache it not really needed.
>
>
OK I have committed this fix.
> The EncTicketPart should be unseal, I think the following code could
> help you.
>
> Ticket ticket = apReq.getTicket();
> EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> etEncryptedEncPart(),
> encKey, KeyUsage.KDC_REP_TICKET, EncTicketPart.class);
> ticket.setEncPart(encPart);
>
It does, thanks! I have it kind of working now with a few hacks. I can get the KrbToken from the AuthorizationData now as follows:
AuthorizationData authzData = encPart.getAuthorizationData(); AuthorizationDataEntry dataEntry = authzData.getElements().iterator().next();
AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
KrbToken decodedKrbToken = token.getToken();
The question I have here is that the KrbToken needs to call the following code internally somehow:
this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
setTokenType();
There is a commented out "decode(ByteBuffer)" method that contains code that does this for a supplied ByteBuffer value. Should this method be called implicitly by the AdToken code somehow? Or is it up to the client code to call decode on KrbToken?
Colm.
>
> Thanks
> Jiajia
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, June 28, 2017 5:41 PM
> To: Li, Jiajia <ji...@intel.com>
> Cc: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> Hi Jiajia,
>
> On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> >
> > 2) Do you mean if the credential cache is null or not set, we can
> > skip the step to store the TGT ticket to credential cache?
> >
>
> Yes exactly. "tgtTicket" is stored as a variable in the
> TokenAuthLoginModule so we may not need the credential cache at all.
> If you agree I will fix this.
>
>
> > 3) We get the armor key from armor cache, do you mean to set the
> > armor key in client and KDC to replace the armor cache?
> >
>
> No, I want to find a way to avoid having an armor key at all. If the
> purpose of the armor key is to encrypt the communication with the KDC,
> then if the JWT token is encrypted this requirement is not necessary.
> But perhaps it's not possible to skip this step?
>
>
> >
> > 4) I thinks it's great to put claims from the JWT token into the
> > authorization data of the ticket, that will be an important feature.
> >
>
> OK I have created a JIRA for this.
>
>
> >
> > 5) Actually, AuthorizationData is not really set in the
> > EncTicketPart, in AbstractIdentityBackend with the following
> implementation:
> > protected AuthorizationData doGetIdentityAuthorizationData(
> > Object kdcRequest, EncTicketPart encTicketPart)
> > throws KrbException {
> > return null;
> > }
> >
>
> Right, but I am doing this locally. The problem is on the client side
> that "tkt.getTicket().getEncPart()" is null. How can I see what the
> authorization data of the ticket is on the client side, so that I can
> test that it was inserted correctly?
>
> Colm.
>
>
> >
> > Thanks
> > Jiajia
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, June 19, 2017 8:24 PM
> > To: kerby@directory.apache.org
> > Subject: Kerby JWT support
> >
> > Hi all,
> >
> > I'd like to resurrect some of the issues surrounding the JWT support
> > in Kerby. If nothing else we can hopefully agree on what the
> > outstanding issues are and then put them into JIRA so that we have a
> > record of what needs to be done. Some of the tasks are fairly
> > trivial and could be addressed for the next release.
> >
> > 1) There was a proposal last year to move the TokenAuthLoginModule
> > from the "integration-test" module into the "kerb-client" module in
> > a separate package like 'jaas'.
> >
> > 2) I'd like to make the credential cache configuration item in the
> > TokenAuthLoginModule optional to simplify the configuration. It's
> > not actually needed as we just keep the TgtTicket internally in the
> > LoginModule anyway.
> >
> > 3) Right now, we need an armor cache to then get a TGT using a JWT.
> > However, I think we should also support configuring the KDC with a
> > private decryption key. If the incoming JWT token is encrypted to
> > the KDC then we should be able to skip the armor cache step.
> >
> > 4) For the access token case, make it possible to put claims from
> > the JWT token into the authorization data of the ticket. I've done
> > some work on this last year that could be re-used.
> >
> > 5) To test (4), I'd like to be able to query the authorization data
> > of the issued service ticket. However, using the Kerby API, the
> > following returns null?
> >
> > tkt.getTicket().getEncPart() (.getAuthorizationData())
> >
> > Is there a way for me to access the authorization data of the ticket
> > using the Kerby API in some way to check that it's actually getting
> > inserted properly?
> >
> > Thoughts? Am I missing anything else?
> >
> > 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: Kerby JWT support
Posted by Colm O hEigeartaigh <co...@apache.org>.
On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> Yes, agree with you, credential cache it not really needed.
>
>
OK I have committed this fix.
> The EncTicketPart should be unseal, I think the following code could help
> you.
>
> Ticket ticket = apReq.getTicket();
> EncTicketPart encPart = EncryptionUtil.unseal(ticket.g
> etEncryptedEncPart(),
> encKey, KeyUsage.KDC_REP_TICKET, EncTicketPart.class);
> ticket.setEncPart(encPart);
>
It does, thanks! I have it kind of working now with a few hacks. I can get
the KrbToken from the AuthorizationData now as follows:
AuthorizationData authzData = encPart.getAuthorizationData();
AuthorizationDataEntry dataEntry =
authzData.getElements().iterator().next();
AdToken token = dataEntry.getAuthzDataAs(AdToken.class);
KrbToken decodedKrbToken = token.getToken();
The question I have here is that the KrbToken needs to call the following
code internally somehow:
this.innerToken = getTokenDecoder().decodeFromBytes(getTokenValue());
setTokenType();
There is a commented out "decode(ByteBuffer)" method that contains code
that does this for a supplied ByteBuffer value. Should this method be
called implicitly by the AdToken code somehow? Or is it up to the client
code to call decode on KrbToken?
Colm.
>
> Thanks
> Jiajia
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, June 28, 2017 5:41 PM
> To: Li, Jiajia <ji...@intel.com>
> Cc: kerby@directory.apache.org
> Subject: Re: Kerby JWT support
>
> Hi Jiajia,
>
> On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> >
> > 2) Do you mean if the credential cache is null or not set, we can skip
> > the step to store the TGT ticket to credential cache?
> >
>
> Yes exactly. "tgtTicket" is stored as a variable in the
> TokenAuthLoginModule so we may not need the credential cache at all. If you
> agree I will fix this.
>
>
> > 3) We get the armor key from armor cache, do you mean to set the armor
> > key in client and KDC to replace the armor cache?
> >
>
> No, I want to find a way to avoid having an armor key at all. If the
> purpose of the armor key is to encrypt the communication with the KDC, then
> if the JWT token is encrypted this requirement is not necessary. But
> perhaps it's not possible to skip this step?
>
>
> >
> > 4) I thinks it's great to put claims from the JWT token into the
> > authorization data of the ticket, that will be an important feature.
> >
>
> OK I have created a JIRA for this.
>
>
> >
> > 5) Actually, AuthorizationData is not really set in the
> > EncTicketPart, in AbstractIdentityBackend with the following
> implementation:
> > protected AuthorizationData doGetIdentityAuthorizationData(
> > Object kdcRequest, EncTicketPart encTicketPart)
> > throws KrbException {
> > return null;
> > }
> >
>
> Right, but I am doing this locally. The problem is on the client side that
> "tkt.getTicket().getEncPart()" is null. How can I see what the
> authorization data of the ticket is on the client side, so that I can test
> that it was inserted correctly?
>
> Colm.
>
>
> >
> > Thanks
> > Jiajia
> >
> > -----Original Message-----
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, June 19, 2017 8:24 PM
> > To: kerby@directory.apache.org
> > Subject: Kerby JWT support
> >
> > Hi all,
> >
> > I'd like to resurrect some of the issues surrounding the JWT support
> > in Kerby. If nothing else we can hopefully agree on what the
> > outstanding issues are and then put them into JIRA so that we have a
> > record of what needs to be done. Some of the tasks are fairly trivial
> > and could be addressed for the next release.
> >
> > 1) There was a proposal last year to move the TokenAuthLoginModule
> > from the "integration-test" module into the "kerb-client" module in a
> > separate package like 'jaas'.
> >
> > 2) I'd like to make the credential cache configuration item in the
> > TokenAuthLoginModule optional to simplify the configuration. It's not
> > actually needed as we just keep the TgtTicket internally in the
> > LoginModule anyway.
> >
> > 3) Right now, we need an armor cache to then get a TGT using a JWT.
> > However, I think we should also support configuring the KDC with a
> > private decryption key. If the incoming JWT token is encrypted to the
> > KDC then we should be able to skip the armor cache step.
> >
> > 4) For the access token case, make it possible to put claims from the
> > JWT token into the authorization data of the ticket. I've done some
> > work on this last year that could be re-used.
> >
> > 5) To test (4), I'd like to be able to query the authorization data of
> > the issued service ticket. However, using the Kerby API, the following
> > returns null?
> >
> > tkt.getTicket().getEncPart() (.getAuthorizationData())
> >
> > Is there a way for me to access the authorization data of the ticket
> > using the Kerby API in some way to check that it's actually getting
> > inserted properly?
> >
> > Thoughts? Am I missing anything else?
> >
> > 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: Kerby JWT support
Posted by "Li, Jiajia" <ji...@intel.com>.
>>
>> 2) Do you mean if the credential cache is null or not set, we can skip
>> the step to store the TGT ticket to credential cache?
>>
> Yes exactly. "tgtTicket" is stored as a variable in the TokenAuthLoginModule so we may not need the credential cache at all. If you agree I will fix this.
Yes, agree with you, credential cache it not really needed.
>> 3) We get the armor key from armor cache, do you mean to set the armor
>> key in client and KDC to replace the armor cache?
>>
> No, I want to find a way to avoid having an armor key at all. If the purpose of the armor key is to encrypt the communication with the KDC,
> then if the JWT token is encrypted this requirement is not necessary. But perhaps it's not possible to skip this step?
The armor credential's key with two usages:
1. Used as the client key:
line194#ArmoredRequest:
EncryptedData authnData = EncryptionUtil.seal(authenticator,
credential.getKey(), KeyUsage.AP_REQ_AUTH);
2. Used as armor key for FX_FAST padata:
Line205#ArmoredRequest:
private EncryptionKey makeArmorKey(EncryptionKey subKey, EncryptionKey armorCacheKey)
throws KrbException {
EncryptionKey armorKey = FastUtil.makeArmorKey(subKey, armorCacheKey);
return armorKey;
In my opinion, the encrypted JWT token can be used in second usage, we can create one new type padata, such as "EncryptedToken" padata, and set the encrypted JWT token in to the new type padata entry. When the kdc receive this padata entry, it can decrypt with the configured private decryption key.
>>
>> 5) Actually, AuthorizationData is not really set in the
> >EncTicketPart, in AbstractIdentityBackend with the following implementation:
>> protected AuthorizationData doGetIdentityAuthorizationData(
>> Object kdcRequest, EncTicketPart encTicketPart)
>> throws KrbException {
>> return null;
> > }
>>
> Right, but I am doing this locally. The problem is on the client side that "tkt.getTicket().getEncPart()" is null. How can I see what the authorization data of the ticket is on
> the client side, so that I can test that it was inserted correctly?
The EncTicketPart should be unseal, I think the following code could help you.
Ticket ticket = apReq.getTicket();
EncTicketPart encPart = EncryptionUtil.unseal(ticket.getEncryptedEncPart(),
encKey, KeyUsage.KDC_REP_TICKET, EncTicketPart.class);
ticket.setEncPart(encPart);
Thanks
Jiajia
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, June 28, 2017 5:41 PM
To: Li, Jiajia <ji...@intel.com>
Cc: kerby@directory.apache.org
Subject: Re: Kerby JWT support
Hi Jiajia,
On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> 2) Do you mean if the credential cache is null or not set, we can skip
> the step to store the TGT ticket to credential cache?
>
Yes exactly. "tgtTicket" is stored as a variable in the TokenAuthLoginModule so we may not need the credential cache at all. If you agree I will fix this.
> 3) We get the armor key from armor cache, do you mean to set the armor
> key in client and KDC to replace the armor cache?
>
No, I want to find a way to avoid having an armor key at all. If the purpose of the armor key is to encrypt the communication with the KDC, then if the JWT token is encrypted this requirement is not necessary. But perhaps it's not possible to skip this step?
>
> 4) I thinks it's great to put claims from the JWT token into the
> authorization data of the ticket, that will be an important feature.
>
OK I have created a JIRA for this.
>
> 5) Actually, AuthorizationData is not really set in the
> EncTicketPart, in AbstractIdentityBackend with the following implementation:
> protected AuthorizationData doGetIdentityAuthorizationData(
> Object kdcRequest, EncTicketPart encTicketPart)
> throws KrbException {
> return null;
> }
>
Right, but I am doing this locally. The problem is on the client side that "tkt.getTicket().getEncPart()" is null. How can I see what the authorization data of the ticket is on the client side, so that I can test that it was inserted correctly?
Colm.
>
> Thanks
> Jiajia
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Monday, June 19, 2017 8:24 PM
> To: kerby@directory.apache.org
> Subject: Kerby JWT support
>
> Hi all,
>
> I'd like to resurrect some of the issues surrounding the JWT support
> in Kerby. If nothing else we can hopefully agree on what the
> outstanding issues are and then put them into JIRA so that we have a
> record of what needs to be done. Some of the tasks are fairly trivial
> and could be addressed for the next release.
>
> 1) There was a proposal last year to move the TokenAuthLoginModule
> from the "integration-test" module into the "kerb-client" module in a
> separate package like 'jaas'.
>
> 2) I'd like to make the credential cache configuration item in the
> TokenAuthLoginModule optional to simplify the configuration. It's not
> actually needed as we just keep the TgtTicket internally in the
> LoginModule anyway.
>
> 3) Right now, we need an armor cache to then get a TGT using a JWT.
> However, I think we should also support configuring the KDC with a
> private decryption key. If the incoming JWT token is encrypted to the
> KDC then we should be able to skip the armor cache step.
>
> 4) For the access token case, make it possible to put claims from the
> JWT token into the authorization data of the ticket. I've done some
> work on this last year that could be re-used.
>
> 5) To test (4), I'd like to be able to query the authorization data of
> the issued service ticket. However, using the Kerby API, the following
> returns null?
>
> tkt.getTicket().getEncPart() (.getAuthorizationData())
>
> Is there a way for me to access the authorization data of the ticket
> using the Kerby API in some way to check that it's actually getting
> inserted properly?
>
> Thoughts? Am I missing anything else?
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby JWT support
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Jiajia,
On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <ji...@intel.com> wrote:
>
> 2) Do you mean if the credential cache is null or not set, we can skip the
> step to store the TGT ticket to credential cache?
>
Yes exactly. "tgtTicket" is stored as a variable in the
TokenAuthLoginModule so we may not need the credential cache at all. If you
agree I will fix this.
> 3) We get the armor key from armor cache, do you mean to set the armor key
> in client and KDC to replace the armor cache?
>
No, I want to find a way to avoid having an armor key at all. If the
purpose of the armor key is to encrypt the communication with the KDC, then
if the JWT token is encrypted this requirement is not necessary. But
perhaps it's not possible to skip this step?
>
> 4) I thinks it's great to put claims from the JWT token into the
> authorization data of the ticket, that will be an important feature.
>
OK I have created a JIRA for this.
>
> 5) Actually, AuthorizationData is not really set in the EncTicketPart, in
> AbstractIdentityBackend with the following implementation:
> protected AuthorizationData doGetIdentityAuthorizationData(
> Object kdcRequest, EncTicketPart encTicketPart)
> throws KrbException {
> return null;
> }
>
Right, but I am doing this locally. The problem is on the client side that
"tkt.getTicket().getEncPart()" is null. How can I see what the
authorization data of the ticket is on the client side, so that I can test
that it was inserted correctly?
Colm.
>
> Thanks
> Jiajia
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Monday, June 19, 2017 8:24 PM
> To: kerby@directory.apache.org
> Subject: Kerby JWT support
>
> Hi all,
>
> I'd like to resurrect some of the issues surrounding the JWT support in
> Kerby. If nothing else we can hopefully agree on what the outstanding
> issues are and then put them into JIRA so that we have a record of what
> needs to be done. Some of the tasks are fairly trivial and could be
> addressed for the next release.
>
> 1) There was a proposal last year to move the TokenAuthLoginModule from
> the "integration-test" module into the "kerb-client" module in a separate
> package like 'jaas'.
>
> 2) I'd like to make the credential cache configuration item in the
> TokenAuthLoginModule optional to simplify the configuration. It's not
> actually needed as we just keep the TgtTicket internally in the LoginModule
> anyway.
>
> 3) Right now, we need an armor cache to then get a TGT using a JWT.
> However, I think we should also support configuring the KDC with a private
> decryption key. If the incoming JWT token is encrypted to the KDC then we
> should be able to skip the armor cache step.
>
> 4) For the access token case, make it possible to put claims from the JWT
> token into the authorization data of the ticket. I've done some work on
> this last year that could be re-used.
>
> 5) To test (4), I'd like to be able to query the authorization data of the
> issued service ticket. However, using the Kerby API, the following returns
> null?
>
> tkt.getTicket().getEncPart() (.getAuthorizationData())
>
> Is there a way for me to access the authorization data of the ticket using
> the Kerby API in some way to check that it's actually getting inserted
> properly?
>
> Thoughts? Am I missing anything else?
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby JWT support
Posted by "Li, Jiajia" <ji...@intel.com>.
Hi Colm,
1) Agree with you, I can do it soon.
2) Do you mean if the credential cache is null or not set, we can skip the step to store the TGT ticket to credential cache?
3) We get the armor key from armor cache, do you mean to set the armor key in client and KDC to replace the armor cache?
4) I thinks it's great to put claims from the JWT token into the authorization data of the ticket, that will be an important feature.
5) Actually, AuthorizationData is not really set in the EncTicketPart, in AbstractIdentityBackend with the following implementation:
protected AuthorizationData doGetIdentityAuthorizationData(
Object kdcRequest, EncTicketPart encTicketPart)
throws KrbException {
return null;
}
Thanks
Jiajia
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Monday, June 19, 2017 8:24 PM
To: kerby@directory.apache.org
Subject: Kerby JWT support
Hi all,
I'd like to resurrect some of the issues surrounding the JWT support in Kerby. If nothing else we can hopefully agree on what the outstanding issues are and then put them into JIRA so that we have a record of what needs to be done. Some of the tasks are fairly trivial and could be addressed for the next release.
1) There was a proposal last year to move the TokenAuthLoginModule from the "integration-test" module into the "kerb-client" module in a separate package like 'jaas'.
2) I'd like to make the credential cache configuration item in the TokenAuthLoginModule optional to simplify the configuration. It's not actually needed as we just keep the TgtTicket internally in the LoginModule anyway.
3) Right now, we need an armor cache to then get a TGT using a JWT.
However, I think we should also support configuring the KDC with a private decryption key. If the incoming JWT token is encrypted to the KDC then we should be able to skip the armor cache step.
4) For the access token case, make it possible to put claims from the JWT token into the authorization data of the ticket. I've done some work on this last year that could be re-used.
5) To test (4), I'd like to be able to query the authorization data of the issued service ticket. However, using the Kerby API, the following returns null?
tkt.getTicket().getEncPart() (.getAuthorizationData())
Is there a way for me to access the authorization data of the ticket using the Kerby API in some way to check that it's actually getting inserted properly?
Thoughts? Am I missing anything else?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com