directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Kerberos PrincipalName
Date Mon, 02 Jul 2007 18:11:51 GMT
FYI, I have tried to implement a new PrincipalName. The KerberosName 
implementation form various sources (Sun, IBM, Harmony, MIT) is simply 
totally buggy. RFC 1964 par. 2.1 has simply been written for nothing...

Emmanuel Lecharny a écrit :

> Hi,
> in order to facilitate the codec work, we may need to implement our
> own PrincipalName instead of using
> We will have to define a new API for this class, which should be close
> to the existing KerberosPrincipal class. The main differences I see
> are :
> - Principal Type : we will have all the different types in an enum,
> outside of the PrincipalName (PN) class (KerberosPrincipal contains
> those types constant)
> - We should be able to construct a new PrincipalName by passing a
> KerberosPrincipal object as an argument. Also, as we may have more
> than a component into the name, we should be able to add some
> component to an existing PN and also to initialize a PN with a list of
> component names.
> - we have to implement RFC 1964, part 2.1
> - the getNameType() method will return a reference to the
> PrincipalType enum instead of an int
> - the getName() method should remain the same
> - we should add some getRealm() method
> - we should also add a getNameComponents() method, returning a lost of
> NameComponent (a list of String)
> - internally, instead of keeping the PN as a String, we should
> decompose it into a list of NameComponent and a REALM.
> wdyt ?

View raw message