Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
From: "Endi Sukma Dewata" <endisd@vergenet.com>
To: "'Apache Directory Developers List'" <dev@directory.apache.org>
Subject: RE: Access to LdapPrincipal constructor
Date: Tue, 3 May 2005 11:26:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <42778748.60006@bellsouth.net>
Thread-Index: AcVP7Df7yDCb1viUTzKmq28x0rSRzQADrLwQ
Message-Id: <20050503160649.9A50013FF4@mail.vergenet.com>


Alex Karasulu wrote:

> Hmmmm.  So to create an LdapPrincipal all you need to do is extend it.
> I should have made it final.  This sounds like the same security
> problem.  But you are right we do need something temporary.  Making the
> constructor public is the same thing.  WDYT should I do this just for now?

Actually what I meant is add the method in the AbstractAuthenticator.

    protected LdapPrincipal createLdapPrincipal( String dn ) {
        LdapName principalDn = new LdapName( dn );
        return new LdapPrincipal( principalDn );
    }

This method would only be available to the subclasses of
AbstractAuthenticator, i.e. the custom Authenticators.

See the sample program for custom Authenticator:
http://directory.apache.org/subprojects/apacheds/users/authentication.html

The authenticate() method now can be implemented this way:

    public LdapPrincipal authenticate( ServerContext ctx ) {
        ...
        return createLdapPrincipal( dn );
    }

This way you can keep LdapPrincipal final and private to the package, but
the custom Authenticators can still use it.

--
Endi S. Dewata