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
