directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quanah Gibson-Mount <qua...@zimbra.com>
Subject Re: [ApacheDS] Internal vs. external lookups
Date Thu, 31 May 2007 05:28:11 GMT
--On Thursday, May 31, 2007 1:17 AM -0400 Alex Karasulu 
<akarasulu@apache.org> wrote:

>
>
>
> On 5/31/07, Quanah Gibson-Mount <quanah@zimbra.com> wrote:
>
> --On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez
> <enriquer9@gmail.com> wrote:
>
>> Actually, I very much care whether the request is internal vs.
>> external and much much less "who" is attempting the authentication.
>> The issue with what I want to do is that certain operations must NEVER
>> be allowed to occur from outside the server.  Basing this upon the
>> bind principal does not help since a bind principal can be
>> compromised.  To avoid a security problem when a principal is
>> compromised, I must prevent certain operations from ever occuring from
>> outside the server, and thus I must know whether a request is coming
>> from inside vs. outside the server and not who the bind principal is.
>
> This is something that matters considerably when considering dynamic group
> expansion.  I haven't followed whether or not Apache DS has implemented
> (or
> will implement) this, but that's certainly a place where I found that it
> is
> necessary to have the concept of an internal ID acting on different
> permissions from the external ID making a request.
>
>
>
> This is interesting can you elaborate or give an example of such a
> situation?

Certainly. :)

At Stanford, user groups were always implemented via an attribute 
(suPrivilegeGroup).  Due to data policy restrictions because of US Law 
(FERPA, HIPAA), access to the attribute itself is highly restricted.  The 
attribute is multi-valued, and may contain data that is not covered by US 
Law (and thus world readable).  Stanford desires to use the attribute 
values for authorization via groups.  So an example entry might have 
something like:

suregid=1234,cn=people,dc=stanford,dc=edu
....
suPrivilegeGroup: FERPA1
suPrivilegeGroup: FERPA2
suPrivilegeGroup: WORLD1
suPrivilegeGroup: WORLD2


Dynamic groups work on the concept of evaluating an LDAP URI to create the 
membership list.  So that might be something like (and this is off the top 
of my head for that rather arcane URI syntax...)

ldap:///cn=people,dc=stanford,dc=edu??suPrivilegeGroup=FERPA1


Now, normally, to create the population for this dynamic group, it requires 
that the identity connection to the server (lets say "www") has at least 
search ability on the suPrivilegeGroup attribute.  However, if Stanford 
grants search on that attribute to the "www" principal, any user on the www 
servers can potentially use the credentials of the www server (via CGI 
scripts or other methods) to find out what people are in particular groups. 
To fix this issue, the general idea is to allow an "internal" ID to be 
defined in the dynamic group object that is what performs the actual 
evaluation of the LDAP URI.  This way, the LDAP access to the group object 
can be allowed for the "www" identity, but it itself actually has no 
ability to search the user entries for suPrivilegeGroup values.

There's an RFC on dynamic groups that is currently draft that incorporates 
this idea, but has several serious flaws in it.  A discussion about the 
draft and its current flaws can be found at:

<http://www.openldap.org/lists/ietf-ldapext/200702/threads.html>

--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Mime
View raw message