Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 5271 invoked from network); 2 Jul 2007 18:12:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Jul 2007 18:12:15 -0000 Received: (qmail 23323 invoked by uid 500); 2 Jul 2007 18:12:17 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 23270 invoked by uid 500); 2 Jul 2007 18:12:17 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 23220 invoked by uid 99); 2 Jul 2007 18:12:17 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jul 2007 11:12:17 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [212.27.42.35] (HELO smtp5-g19.free.fr) (212.27.42.35) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jul 2007 11:12:13 -0700 Received: from [192.168.0.1] (vol75-3-82-66-216-176.fbx.proxad.net [82.66.216.176]) by smtp5-g19.free.fr (Postfix) with ESMTP id 1278E45480; Mon, 2 Jul 2007 20:11:52 +0200 (CEST) Message-ID: <46893FE7.7010107@apache.org> Date: Mon, 02 Jul 2007 20:11:51 +0200 From: Emmanuel Lecharny User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: fr, en MIME-Version: 1.0 To: elecharny@iktek.com CC: Apache Directory Developers List Subject: Re: Kerberos PrincipalName References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on 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 ? > >