On Fri, Jun 30, 2017 at 4:16 AM, Li, Jiajia <[email protected]> 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:[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 > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
