Hi Jiajia,
On Tue, Jun 27, 2017 at 9:37 AM, Li, Jiajia <jiajia...@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:cohei...@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
