>>
>> 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:[email protected]]
Sent: Wednesday, June 28, 2017 5:41 PM
To: Li, Jiajia <[email protected]>
Cc: [email protected]
Subject: Re: Kerby JWT support
Hi Jiajia,
On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <[email protected]> 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:[email protected]]
> Sent: Monday, June 19, 2017 8:24 PM
> To: [email protected]
> 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
