You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Endi Sukma Dewata <en...@vergenet.com> on 2005/04/30 04:24:24 UTC
Access to LdapPrincipal constructor
Hi,
I just found out that the access to LdapPrincipal constructor has been
restricted to the package only. This is a problem because any custom
Authenticator would need to create and return an LdapPrincipal object in the
authenticate() method. See the example under Custom Authenticator:
http://directory.apache.org/subprojects/apacheds/users/authentication.html.
Is there a specific example where making the constructor publicly accessible
would pose a security problem? Any suggestions on how to resolve this?
Thanks a lot.
--
Endi S. Dewata
Re: Access to LdapPrincipal constructor
Posted by Alex Karasulu <ao...@bellsouth.net>.
Niclas Hedhman wrote:
>On Saturday 30 April 2005 11:02, Alex Karasulu wrote:
>
>
>>Ahh yeah I thought I confronted this at some point. I have to refresh
>>myself. Basically LdapPrincipal can only be created by the Auth service
>>you are right. This is for security reasons and the reason while we
>>keep it package friendly. I know I made some kind of changes to
>>accommodate a way for your Authenticators to be ok with this.
>>
>>
>
>Alex, I don't know if you have thought about how the ApacheDS is secured over
>all. Protecting fields, methods and constructors is no real protection at
>all, unless combined with proper security policies and the use of
>AccessController.doPriviliged().
>
>If no such thoughts has been spent on the subject, perhaps it is soon time to
>start a security review of the entire system.
>
>
Yah that's long overdue. Of course I've thought about using privledged
actions. Field protection is just minimal since we did not do all the
needed work for securiting it. Basically we should have a Permission
for being able to create such a principal to protect creation of an
LdapPrincipal.
We need more hands here to do this additional work. Otherwise I'm going
to have to get to it when I can.
FYI privledged actions will be key when we have code used for stored
procedures in the server. Can't take the next big leap without it.
Alex
RE: Access to LdapPrincipal constructor
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> Noel J. Bergman wrote:
> > > If no such thoughts has been spent on the subject, perhaps it
> > > is soon time to start a security review of the entire system.
> > Do you want to make that review a project for yourself?
> Thinking about it, but I definately need some tough peer reviews
> to make it water tight.
I don't expect that to be a problem. :-)
--- Noel
Re: Access to LdapPrincipal constructor
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 02 May 2005 23:16, Noel J. Bergman wrote:
> > If no such thoughts has been spent on the subject, perhaps it is soon
> > time to start a security review of the entire system.
>
> Do you want to make that review a project for yourself?
Thinking about it, but I definately need some tough peer reviews to make it
water tight.
Cheers
Niclas
RE: Access to LdapPrincipal constructor
Posted by "Noel J. Bergman" <no...@devtech.com>.
Niclas Hedhman wrote:
> Protecting fields, methods and constructors is no real protection at
> all, unless combined with proper security policies and the use of
> AccessController.doPriviliged().
This is not necessarily an issue for the core code, although it could be if
we want to provide maximum control to administrators, but should be applied
to all pluggable code.
> If no such thoughts has been spent on the subject, perhaps it is soon
> time to start a security review of the entire system.
Do you want to make that review a project for yourself?
--- Noel
Re: Access to LdapPrincipal constructor
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 30 April 2005 11:02, Alex Karasulu wrote:
> Ahh yeah I thought I confronted this at some point. I have to refresh
> myself. Basically LdapPrincipal can only be created by the Auth service
> you are right. This is for security reasons and the reason while we
> keep it package friendly. I know I made some kind of changes to
> accommodate a way for your Authenticators to be ok with this.
Alex, I don't know if you have thought about how the ApacheDS is secured over
all. Protecting fields, methods and constructors is no real protection at
all, unless combined with proper security policies and the use of
AccessController.doPriviliged().
If no such thoughts has been spent on the subject, perhaps it is soon time to
start a security review of the entire system.
Cheers
Niclas
RE: Access to LdapPrincipal constructor
Posted by Endi Sukma Dewata <en...@vergenet.com>.
> Alex Karasulu wrote:
>
> I added the changes a little while ago in following commit...
>
> http://svn.apache.org/viewcvs?rev=167943&view=rev*
>
> I updated the jars have in the maven repo.
>
> Thanks,
> Alex
>
> *
Thanks! It works great now.
--
Endi S. Dewata
Re: Access to LdapPrincipal constructor
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alex Karasulu wrote:
> Endi Sukma Dewata wrote:
>
>> This method would only be available to the subclasses of
>> AbstractAuthenticator, i.e. the custom Authenticators.
>>
> This is perfect! Keeps things safe. Good tip.
<snip/>
> Excellent I will add this right now.
I added the changes a little while ago in following commit...
http://svn.apache.org/viewcvs?rev=167943&view=rev*
I updated the jars have in the maven repo.
Thanks,
Alex
*
Re: Access to LdapPrincipal constructor
Posted by Alex Karasulu <ao...@bellsouth.net>.
Endi Sukma Dewata wrote:
>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.
>
>
This is perfect! Keeps things safe. Good tip.
>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.
>
>
Excellent I will add this right now.
Alex
RE: Access to LdapPrincipal constructor
Posted by Endi Sukma Dewata <en...@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
Re: Access to LdapPrincipal constructor
Posted by Alex Karasulu <ao...@bellsouth.net>.
Endi Sukma Dewata wrote:
>Hi Alex,
>
>How about adding a protected method in the AbstractAuthenticator that
>creates the LdapPrincipal? This way the constructor can remain private, but
>the subclasses can still call this method to create the LdapPrincipal
>instance. This at least can be a temporary solution until we figure out a
>better way to do it. Thanks.
>
>
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?
<snip/>
>>Ahh yeah I thought I confronted this at some point. I have to refresh
>>myself. Basically LdapPrincipal can only be created by the Auth
>>service you are right. This is for security reasons and the reason
>>while we keep it package friendly. I know I made some kind of changes
>>to accommodate a way for your Authenticators to be ok with this.
>>
>>Will post back in a bit....
>>
>>
>
>Yah looks like my fix was to move the SimpleAuthenticator into the authn
>package where the LdapPrincipal is. Not very good if you want to write
>your own Authenticator is it. Even if you put your Authenticator impl
>into the authn package it should not be able to work unless you
>repackage the jars. Hmmm I really worry about making the LdapPrincipal
>constructor public. Gotta figure something out though.
>
>Alex
>
>
>
>
>
RE: Access to LdapPrincipal constructor
Posted by Endi Sukma Dewata <en...@vergenet.com>.
Hi Alex,
How about adding a protected method in the AbstractAuthenticator that
creates the LdapPrincipal? This way the constructor can remain private, but
the subclasses can still call this method to create the LdapPrincipal
instance. This at least can be a temporary solution until we figure out a
better way to do it. Thanks.
--
Endi S. Dewata
-----Original Message-----
From: Alex Karasulu [mailto:aok123@bellsouth.net]
Sent: Friday, April 29, 2005 10:17 PM
To: Apache Directory Developers List
Subject: Re: Access to LdapPrincipal constructor
Alex Karasulu wrote:
> Endi Sukma Dewata wrote:
>
>> Hi,
>>
>>
>>
>> I just found out that the access to LdapPrincipal constructor has
>> been restricted to the package only. This is a problem because any
>> custom Authenticator would need to create and return an LdapPrincipal
>> object in the authenticate() method. See the example under Custom
>> Authenticator:
>>
>>
>>
>>
http://directory.apache.org/subprojects/apacheds/users/authentication.html.
>>
>>
>>
>>
>> Is there a specific example where making the constructor publicly
>> accessible would pose a security problem? Any suggestions on how to
>> resolve this? Thanks a lot.
>>
> Ahh yeah I thought I confronted this at some point. I have to refresh
> myself. Basically LdapPrincipal can only be created by the Auth
> service you are right. This is for security reasons and the reason
> while we keep it package friendly. I know I made some kind of changes
> to accommodate a way for your Authenticators to be ok with this.
>
> Will post back in a bit....
Yah looks like my fix was to move the SimpleAuthenticator into the authn
package where the LdapPrincipal is. Not very good if you want to write
your own Authenticator is it. Even if you put your Authenticator impl
into the authn package it should not be able to work unless you
repackage the jars. Hmmm I really worry about making the LdapPrincipal
constructor public. Gotta figure something out though.
Alex
Re: Access to LdapPrincipal constructor
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alex Karasulu wrote:
> Endi Sukma Dewata wrote:
>
>> Hi,
>>
>>
>>
>> I just found out that the access to LdapPrincipal constructor has
>> been restricted to the package only. This is a problem because any
>> custom Authenticator would need to create and return an LdapPrincipal
>> object in the authenticate() method. See the example under Custom
>> Authenticator:
>>
>>
>>
>> http://directory.apache.org/subprojects/apacheds/users/authentication.html.
>>
>>
>>
>>
>> Is there a specific example where making the constructor publicly
>> accessible would pose a security problem? Any suggestions on how to
>> resolve this? Thanks a lot.
>>
> Ahh yeah I thought I confronted this at some point. I have to refresh
> myself. Basically LdapPrincipal can only be created by the Auth
> service you are right. This is for security reasons and the reason
> while we keep it package friendly. I know I made some kind of changes
> to accommodate a way for your Authenticators to be ok with this.
>
> Will post back in a bit....
Yah looks like my fix was to move the SimpleAuthenticator into the authn
package where the LdapPrincipal is. Not very good if you want to write
your own Authenticator is it. Even if you put your Authenticator impl
into the authn package it should not be able to work unless you
repackage the jars. Hmmm I really worry about making the LdapPrincipal
constructor public. Gotta figure something out though.
Alex
Re: Access to LdapPrincipal constructor
Posted by Alex Karasulu <ao...@bellsouth.net>.
Endi Sukma Dewata wrote:
> Hi,
>
>
>
> I just found out that the access to LdapPrincipal constructor has been
> restricted to the package only. This is a problem because any custom
> Authenticator would need to create and return an LdapPrincipal object
> in the authenticate() method. See the example under Custom Authenticator:
>
>
>
> http://directory.apache.org/subprojects/apacheds/users/authentication.html.
>
>
>
> Is there a specific example where making the constructor publicly
> accessible would pose a security problem? Any suggestions on how to
> resolve this? Thanks a lot.
>
Ahh yeah I thought I confronted this at some point. I have to refresh
myself. Basically LdapPrincipal can only be created by the Auth service
you are right. This is for security reasons and the reason while we
keep it package friendly. I know I made some kind of changes to
accommodate a way for your Authenticators to be ok with this.
Will post back in a bit....
Alex