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?
I'm just wondering how it connects to http://www.ietf.org/rfc/rfc4370.txt.
On 5/31/07, Quanah Gibson-Mount < email@example.com> wrote:
> --On Thursday, May 31, 2007 1:17 AM -0400 Alex Karasulu
> <firstname.lastname@example.org> wrote:
> > On 5/31/07, Quanah Gibson-Mount <email@example.com> wrote:
> > --On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez
> > < firstname.lastname@example.org> 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:
> 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...)
> 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 Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> Zimbra :: the leader in open source messaging and collaboration