Kerberos PrincipalName

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

in order to facilitate the codec work, we may need to implement our
own PrincipalName instead of using
javax.security.auth.kerberos.KerberosPrincipal.

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 ?


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Kerberos PrincipalName

[Enrique Rodriguez <en...@gmail.com>]

On 7/2/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> in order to facilitate the codec work, we may need to implement our
> own PrincipalName instead of using
> javax.security.auth.kerberos.KerberosPrincipal.
> ...
> wdyt ?

I think this makes sense and you clearly reviewed the relevant RFC's
for the principal name.

In practice, the vast majority of principal names follow a very basic
form, which is probably why every one cuts corners in their impl.  It
will be good to have a strict interpretation.

Enrique

Re: Kerberos PrincipalName

[Emmanuel Lecharny <el...@apache.org>]

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
> javax.security.auth.kerberos.KerberosPrincipal.
>
> 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 ?
>
>