directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [ApacheDS] Internal vs. external lookups
Date Thu, 31 May 2007 15:20:33 GMT
Hi guys,

I'm just wondering how it connects to http://www.ietf.org/rfc/rfc4370.txt.

wdyt ?

On 5/31/07, Quanah Gibson-Mount <quanah@zimbra.com> wrote:
> --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
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message