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 <jiajia...@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:cohei...@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 <jiajia...@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:cohei...@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 <jiajia...@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:cohei...@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 <jiajia...@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:cohei...@apache.org] > > > > Sent: Wednesday, June 28, 2017 5:41 PM > > > > To: Li, Jiajia <jiajia...@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 <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 > > > > > > > > > > > > > > > > -- > > > 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
