directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: Kerberos implementation questions
Date Mon, 02 Jul 2007 08:39:07 GMT
On 7/1/07, Emmanuel Lecharny <> wrote:
> Hi,
> I have some questions regarding the kerberos implementation :
> 1) We have a TicketModifier class. Is it really usefull ?

The Ticket has no attribute setters, so the intention is that you use
the modifier to create immutable Ticket's.  In earlier days of
ApacheDS we settled on the "modifier pattern" so we could have
immutable objects.  I still think we should have immutable objects,
but if you can think of a better way to create them, I would like to
hear your idea(s).  At a minimum some classes and methods should be
better hidden w.r.t. package private, etc.  Keep in mind these
modifiers are used *everywhere*, not just with Ticket, although the
practice is used inconsistently.

Also, the modifiers are really useful in the switch-statement-heavy
ASN.1 DER codecs currently in use.  In the move to your DER work, this
nicety would go away.

> 2) We have a TicketFactory class, but we have to instanciate it in
> order to create Tickets. Any rationnal for the factory's method not
> being static ?

No, they could be static.  When I started developing the Kerberos and
Change Password *clients* recently, I had some utility code for
bootstrapping the troubleshooting of the clients and I moved said
utility code into the new TicketFactory without much thought.  I
expect that pretty soon, once the clients stabilize, we can simply
delete TicketFactory.  It is not used server-side.

The problem I ran into that precipitated TicketFactory is that a
successful Change Password request requires a successful service
ticket request, which requires a successful TGT request.
TicketFactory contains largely boilerplate code for making one-off
tickets.  As such it is mostly a development aid.

> 3) We are using the standard, I
> just wonder if it wouldn't be a btter idea to have our own class, so
> that the Ticket class will store a realm, instead of asking the SUN
> class to return it for us (the idea is to stick as much as possible to
> the RFC names and structure)

I think that makes sense.  I think I mostly used the existing classes
in the interest of getting the server live and I haven't had the
chance to go back and clean it up.  I agree that the server-side
should be cleansed of Sun classes.  Right now it is a bit of a mix.

Keep in mind, however, that the Sun classes are more useful on the
client-side.  The issue I ran into is that on the client-side, users
of JAAS will need to work with  For
example, if you want to execute a client-side SASL GSSAPI bind using
Sun's JNDI, your Subject must be populated with KerberosTicket's,
which are created with KerberosPrincipals.  This goes for user's of
JGSS, as well.  For this reason, I went with the
classes in the new client code.  The server-side code is a bit of a
mix, since I started using our own classes but later ran into some
issues requiring the JAAS classes.  One of the utility methods on
TicketFactory converts between the two.


View raw message