directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Internal vs. external lookups
Date Fri, 01 Jun 2007 23:27:28 GMT
Guys I have not abandoned this thread.  Just rebuilding dev env after a
failure.  I need to think about this more and review it.  Will get back to
you.  Enrique is this urgent?

Alex

On 5/31/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> 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