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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > --On Thursday, May 31, 2007 1:17 AM -0400 Alex Karasulu > <[EMAIL PROTECTED]> wrote: > > > > > > > > > On 5/31/07, Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: > > > > --On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez > > <[EMAIL PROTECTED]> 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
