You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kerby@directory.apache.org by Bryan Bende <bb...@gmail.com> on 2023/05/24 18:37:33 UTC

KerberosTicket refresh

Hello,

I've been using Kerby to integrate with some existing JAAS based code
that expects to end up with a Subject having a KerberosTicket, and
I've been basing the work off this example from the Kerby code base
[1].

Everything works correctly for the initial login, but now I want to be
able to issue a renewal. Currently we do this by finding the
KerberosTicket inside the Subject and calling the ticket's refresh()
method. This creates an instance of sun.security.krb5.Credentials
using all of the available fields from the KerberosTicket and then
calls renew() on the credentials instance, which then does the
following:

return new KrbTgsReq(options,
                     this,
                     server,
                     serverAlias,
                     null, // from
                     null, // till
                     null, // rtime
                     null, // eTypes
                     cAddr,
                     null,
                     null,
                     null).sendAndGetCreds();

The issue here is that passing in null for rtime (which it could have
passed in the existing value for), causes a code path to go into some
static JAAS stuff in Config and read a renew time from /etc/krb5.conf,
which is not the krb5.conf that was originally used to create this
ticket, so it can cause an error depending on the differences in the
renew lifetime between the two configs.

I realize the above is JDK code and can't be controlled by anyone
here, but I wanted to see if anyone that has worked with Kerby knows
of another way to do this, or in general how to refresh a
KerberosTicket that was created from a KerbyClient.

My first attempt was to create a sub-class of KerberosTicket and
override the refresh method, however it relies on calling an init
method that is private so there is no way for a sub-class to modify
the state after creation.

My second attempt was to allow for using a different type of ticket
interface, instead of KerberosTicket, but then other code that uses
the Subject like SASL stuff will expect to look for KerberosTicket in
the Subject. So it seems like it has to produce KerberosTicket.

Thanks for any ideas.

- Bryan

[1] https://github.com/apache/directory-kerby/blob/trunk/kerby-kerb/kerb-client/src/main/java/org/apache/kerby/kerberos/kerb/client/jaas/TokenAuthLoginModule.java#L154

---------------------------------------------------------------------
To unsubscribe, e-mail: kerby-unsubscribe@directory.apache.org
For additional commands, e-mail: kerby-help@directory.apache.org


Re: KerberosTicket refresh

Posted by Bryan Bende <bb...@gmail.com>.
I will add a follow-up question...

Putting aside any of the JDK KerberosTicket stuff, is there a way in
Kerby to perform a renewal for a TGT?

All calls for requestTgt go through a code path that expects to create
one of the following:

if (requestOptions.contains(KrbOption.USE_PASSWD)) {
    asRequest = new AsRequestWithPasswd(context);
} else if (requestOptions.contains(KrbOption.USE_KEYTAB)) {
    asRequest = new AsRequestWithKeytab(context);
} else if (requestOptions.contains(PkinitOption.USE_ANONYMOUS)) {
    asRequest = new AsRequestWithCert(context);
} else if (requestOptions.contains(PkinitOption.USE_PKINIT)) {
    asRequest = new AsRequestWithCert(context);
} else if (requestOptions.contains(TokenOption.USE_TOKEN)) {
    asRequest = new AsRequestWithToken(context);
} else if (requestOptions.contains(TokenOption.USER_ID_TOKEN)) {
    asRequest = new AsRequestWithToken(context);
}

But shouldn't there be a request where you could send a TGT with RENEW
without having the original keytab/password/etc?

Otherwise if you are sending the password or keytab again then it is
really just a new ticket.



On Wed, May 24, 2023 at 2:37 PM Bryan Bende <bb...@gmail.com> wrote:
>
> Hello,
>
> I've been using Kerby to integrate with some existing JAAS based code
> that expects to end up with a Subject having a KerberosTicket, and
> I've been basing the work off this example from the Kerby code base
> [1].
>
> Everything works correctly for the initial login, but now I want to be
> able to issue a renewal. Currently we do this by finding the
> KerberosTicket inside the Subject and calling the ticket's refresh()
> method. This creates an instance of sun.security.krb5.Credentials
> using all of the available fields from the KerberosTicket and then
> calls renew() on the credentials instance, which then does the
> following:
>
> return new KrbTgsReq(options,
>                      this,
>                      server,
>                      serverAlias,
>                      null, // from
>                      null, // till
>                      null, // rtime
>                      null, // eTypes
>                      cAddr,
>                      null,
>                      null,
>                      null).sendAndGetCreds();
>
> The issue here is that passing in null for rtime (which it could have
> passed in the existing value for), causes a code path to go into some
> static JAAS stuff in Config and read a renew time from /etc/krb5.conf,
> which is not the krb5.conf that was originally used to create this
> ticket, so it can cause an error depending on the differences in the
> renew lifetime between the two configs.
>
> I realize the above is JDK code and can't be controlled by anyone
> here, but I wanted to see if anyone that has worked with Kerby knows
> of another way to do this, or in general how to refresh a
> KerberosTicket that was created from a KerbyClient.
>
> My first attempt was to create a sub-class of KerberosTicket and
> override the refresh method, however it relies on calling an init
> method that is private so there is no way for a sub-class to modify
> the state after creation.
>
> My second attempt was to allow for using a different type of ticket
> interface, instead of KerberosTicket, but then other code that uses
> the Subject like SASL stuff will expect to look for KerberosTicket in
> the Subject. So it seems like it has to produce KerberosTicket.
>
> Thanks for any ideas.
>
> - Bryan
>
> [1] https://github.com/apache/directory-kerby/blob/trunk/kerby-kerb/kerb-client/src/main/java/org/apache/kerby/kerberos/kerb/client/jaas/TokenAuthLoginModule.java#L154

---------------------------------------------------------------------
To unsubscribe, e-mail: kerby-unsubscribe@directory.apache.org
For additional commands, e-mail: kerby-help@directory.apache.org