Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 80039 invoked from network); 1 Jun 2007 23:27:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Jun 2007 23:27:56 -0000 Received: (qmail 17179 invoked by uid 500); 1 Jun 2007 23:28:00 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 17145 invoked by uid 500); 1 Jun 2007 23:28:00 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 17124 invoked by uid 99); 1 Jun 2007 23:28:00 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 16:28:00 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates 64.233.162.234 as permitted sender) Received: from [64.233.162.234] (HELO nz-out-0506.google.com) (64.233.162.234) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 16:27:54 -0700 Received: by nz-out-0506.google.com with SMTP id i1so583513nzh for ; Fri, 01 Jun 2007 16:27:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=GnEnu82JXYJ1Dl4QlZhgt+IMGqpZ5Jlf9uPGhx+zGbCxUE6KEIGSsUuxDv/hlBvq5246mCrUvJsT4CEIpxFf9eNP5+65ACFboRwPQD4XglMWQ3TYOdLDOo0xEGnLtO9hOuGSk6475hMeCpvF97BZyc5xpUsCs+fuZAGHIUA+rRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=B55KfPsyy7YtJfhGY0fjNzoWhc8jNRZ2EfkITuoE8JGiQL8gkH/F/txlw0u37Y+XasS+yuGfpRu4lFFVHy2c0/A5Vll321y+sHMf7mBMO14tKdILPgV37EVQnxv5rKUCFZ8tBqpSrc7/UBlIzeGcKK2oppDqFRXDpeFsuLVuZzw= Received: by 10.142.251.9 with SMTP id y9mr115506wfh.1180740448082; Fri, 01 Jun 2007 16:27:28 -0700 (PDT) Received: by 10.142.101.21 with HTTP; Fri, 1 Jun 2007 16:27:28 -0700 (PDT) Message-ID: Date: Fri, 1 Jun 2007 19:27:28 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" , elecharny@iktek.com Subject: Re: [ApacheDS] Internal vs. external lookups In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9908_990057.1180740448036" References: <568753d90705241516x75b659fdl3b08eba45817a4cc@mail.gmail.com> <568753d90705301217o6867503u1977425553370d4e@mail.gmail.com> <568753d90705301338u7214b4bm3b0c898ae1e869c6@mail.gmail.com> <568753d90705302211s2868cdc8r6d8b1a243d0799c2@mail.gmail.com> <32A295A87FAB485F61530852@192.168.1.3> <80C0BF5A65A69589761BBA92@192.168.1.3> X-Google-Sender-Auth: 16fcaacadde056f6 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_9908_990057.1180740448036 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 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 wrote: > > --On Thursday, May 31, 2007 1:17 AM -0400 Alex Karasulu > > wrote: > > > > > > > > > > > > > > On 5/31/07, Quanah Gibson-Mount wrote: > > > > > > --On Wednesday, May 30, 2007 10:11 PM -0700 Enrique Rodriguez > > > 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=3D1234,cn=3Dpeople,dc=3Dstanford,dc=3Dedu > > .... > > 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=3Dpeople,dc=3Dstanford,dc=3Dedu??suPrivilegeGroup=3DFERPA1 > > > > > > Now, normally, to create the population for this dynamic group, it > requires > > that the identity connection to the server (lets say "www") has at leas= t > > 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: > > > > > > > > --Quanah > > > > -- > > Quanah Gibson-Mount > > Principal Software Engineer > > Zimbra, Inc > > -------------------- > > Zimbra :: the leader in open source messaging and collaboration > > > > > -- > Regards, > Cordialement, > Emmanuel L=E9charny > www.iktek.com > ------=_Part_9908_990057.1180740448036 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 A= M -0400 Alex Karasulu
> <a= karasulu@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&quo= t; is attempting the authentication.
> >> The issue with what I want to do is that certain operatio= ns must NEVER
> >> be allowed to occur from outside the server.=   Basing this upon the
> >> bind principal does not h= elp since a bind principal can be
> >> compromised.  To avoid a security problem when = a principal is
> >> compromised, I must prevent certain operati= ons 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 p= rincipal is.
> >
> > This is something that matters consi= derably when considering dynamic group
> > expansion.  I= haven't followed whether or not Apache DS has implemented
> > (or
> > will implement) this, but that's certain= ly a place where I found that it
> > is
> > necessary to = have the concept of an internal ID acting on different
> > permiss= ions from the external ID making a request.
> >
> >
> >
> > This is interesting ca= n you elaborate or give an example of such a
> > situation?
>= ;
> Certainly. :)
>
> At Stanford, user groups were alway= s implemented via an attribute
> (suPrivilegeGroup).  Due to data policy restrictions bec= ause of US Law
> (FERPA, HIPAA), access to the attribute itself is hi= ghly 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= =3D1234,cn=3Dpeople,dc=3Dstanford,dc=3Dedu
> ....
> suPrivilegeGroup: FERPA1
> suPrivilegeGroup: FE= RPA2
> suPrivilegeGroup: WORLD1
> suPrivilegeGroup: WORLD2
&= gt;
>
> Dynamic groups work on the concept of evaluating an LDA= P URI to create the
> membership list.  So that might be something like (and t= his is off the top
> of my head for that rather arcane URI syntax...)=
>
> ldap:///cn=3Dpeople,dc=3Dstanford,dc=3Dedu??suPrivilegeGro= up=3DFERPA1
>
>
> Now, normally, to create the population for this dynam= ic group, it requires
> that the identity connection to the server (l= ets say "www") has at least
> search ability on the suPrivi= legeGroup 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&= quot; ID to be
> defined in the dynamic group object that is what per= forms the actual
> evaluation of the LDAP URI.  This way, t= he LDAP access to the group object
> can be allowed for the "www" identity, but it itself act= ually has no
> ability to search the user entries for suPrivilegeGrou= p values.
>
> There's an RFC on dynamic groups that is curr= ently draft that incorporates
> this idea, but has several serious flaws in it.  A discu= ssion about the
> draft and its current flaws can be found at:
>= ;
> < http://www.openldap.org/lists/ietf-ldapext/200702/threads.html>
&= gt;
> --Quanah
>
> --
> Quanah Gibson-Mount
>= Principal Software Engineer
> Zimbra, Inc
> ------------------= --
> Zimbra ::  the leader in open source messaging and colla= boration
>


--
Regards,
Cordialement,
Emmanuel L= =E9charny
www.iktek.com

------=_Part_9908_990057.1180740448036--