directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: svn commit: r1144962 - /directory/apacheds/trunk/core-api/src/main/java/org/apache/directory/server/core/
Date Tue, 12 Jul 2011 08:00:57 GMT
On Tue, Jul 12, 2011 at 10:30 AM, Emmanuel Lecharny <> wrote:
> On 7/12/11 9:19 AM, Alex Karasulu wrote:
>>>  rather than
>>> this.session = directoryService.getAdminSession(); in
>>> setDirectoryService())
>>> what we already know is that DS is available and user/app can do
>>> anything if has got access to, but more important is
>>> the usage from an app developer's POV, if I have a web app that allows
>>> users to connect to the server using LdapCoreSessionConnection
>>> then assigning admin session by default during initialization will be
>>> a serious security issue.
>> LDAP applications rarely align their authorization schema with LDAP
>> security. Most applications just connect as admin and handle lookups
>> on behalf of their users.
> Yes. This is very true, and usually, because such apps are using a
> connection pool. It's also safe as it's protected (well, suposely protected)
> by the application : one can't access to this part unless already
> identified. Although I do think it's not necessarily a good idea, it's due
> to the fact it's costly to establish a physical connection. Now, one can
> still use an already existing connection, and bind with a different user,
> instead of using an admin session... Misconceptions are always spread very
> quickly, and are hard to fix...
>> But I think you and Emmanuel both make a good case here. We need to
>> solve this better since some applications like the self service
>> applications we've spoken about writing might use direct LDAP
>> security. However I think we don't just go with an anonymous session
>> or a admin session. We need a means to make this decision better.
> LDAP specify that you can do operation without being bound, and in this
> case, the session will be anonymous. Defaulting to anonymous is then pretty
> natural. Now, you may have something different in mind, can you elaborate ?
> (Of course, the server might reject such operations done on a anonymous
> session, and I can see that as a major issue if we default to anonymous)

You're right we should either go anonymous or take the approach below
which IMO is better. See below...

>> We should require a bind to set the exact session.
> That's an option : if the server reject anonymous operations, then
> obviously, the user *must* bind. I would say that it *should* be the default
> mode...

So you're saying allow anonymous then if there is a failure then allow
user to bind? Or by default force the user to bind?


View raw message