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 (nike.apache.org: domain of akarasulu@gmail.com designates
 74.125.82.44 as permitted sender)
MIME-Version: 1.0
Sender: akarasulu@gmail.com
In-Reply-To: <4E1BF814.2030904@gmail.com>
References: <20110710212302.D0D4C23888FE@eris.apache.org>
	<4E1A9E6F.5020107@gmail.com>
	<CADwPi+FVDH-7ve7DPvYm94FQ-Wb=baxA=eLH9RhxgcJxx0WTeA@mail.gmail.com>
	<4E1BE163.2030501@apache.org>
	<CABzFU-erpo71Lcg+ZEhzE9v-m6XxAunYNLXf1LF3MkuMNWC_Mg@mail.gmail.com>
	<CADwPi+FcjYy8i7NuJWp12kTd4OeiEjk0h5SrkhQHTj5tNVOvxA@mail.gmail.com>
	<4E1BF814.2030904@gmail.com>
Date: Tue, 12 Jul 2011 11:00:57 +0300
Message-ID: 
 <CADwPi+GNjKmyDOKgM1vWfb+ZpfYbW2BZyCqXut8u5OPEiE8X5A@mail.gmail.com>
Subject: Re: svn commit: r1144962 -
 /directory/apacheds/trunk/core-api/src/main/java/org/apache/directory/server/core/LdapCoreSessionConnection.java
From: Alex Karasulu <akarasulu@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>,
 elecharny@apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 12, 2011 at 10:30 AM, Emmanuel Lecharny <elecharny@gmail.com> w=
rote:
> On 7/12/11 9:19 AM, Alex Karasulu wrote:
>>>
>>> =A0rather than
>>>
>>> this.session =3D 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 protect=
ed)
> 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 du=
e
> 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 ver=
y
> 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 pret=
ty
> 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 defa=
ult
> 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?

Alex