directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: Kerberos implementation questions
Date Mon, 02 Jul 2007 09:52:57 GMT
On 7/2/07, Enrique Rodriguez <> wrote:
> 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.

Do we need to create immutable Tickets ? We just produce Tickets in
the server, then send them to the client. What's the point to have
Immutable Tickets ? I may miss something ...

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.

The fact that this Modifier thing is used everywhere don't give me a
clue why we should use it. I agree that some classes might be hidden,
but we have to give a clear reason to do so.

There is obviously something we should take into account : we will
have a server side and a client side. It may be very important to
protect some elements on the client side, and not on the server side,
but we also have to explain the reasons behind those choices.

> 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.

May be... I don't really understand why it's important to have them in
the current codec (encoder or decoder ?), but my lack of knowledge of
the current code is mainly the reason I have those questions.

> > 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.

Ok, just fine. May be we can discuss the way we should do it. I like
the Factory pattern, but if we only have one kind of object we can
generate, it's a little but to heavy...

> 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.

Yes, I get your point. Again, I'm not at all against a TicketFactory,
and it can make perfect sense to keep it. I just don't have enough
element to make a point right now.

> > 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.

Ok, I gonna have a look at it. From the client side, we obviously must
work with Sun classes, but from server side, having our own classes
will help a lot (debug, logs, etc.). It can be done step by step, but
first we need to build integration tests to be sure that moving from
Sun to our own classes don't break everything.

This is what I find difficult atm : changing the code is risky,
because of the lack of tests.

Emmanuel L├ęcharny

View raw message