Re: [ldapext] DBIS - new IETF drafts

Andrew Findlay <andrew.findlay@skills-1st.co.uk> Thu, 09 January 2014 18:09 UTC

Return-Path: <andrew.findlay@skills-1st.co.uk>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6671ADFF3 for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 10:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzanDi5ruZq2 for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 10:09:03 -0800 (PST)
Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id AB12D1AE078 for <ldapext@ietf.org>; Thu, 9 Jan 2014 10:09:02 -0800 (PST)
Received: from 9.1.5.2.b.3.c.7.4.f.9.1.a.6.4.b.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:b46a:19f4:7c3b:2519] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1W1K2G-00063h-N5; Thu, 09 Jan 2014 18:08:52 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1W1K2F-0006Ca-Ub; Thu, 09 Jan 2014 18:08:51 +0000
Date: Thu, 9 Jan 2014 18:08:51 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Message-ID: <20140109180851.GW3938@slab.skills-1st.co.uk>
References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <52CEC4D5.1070703@stroeder.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Cc: ldapext@ietf.org
Subject: Re: [ldapext] DBIS - new IETF drafts
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 18:09:05 -0000

On Thu, Jan 09, 2014 at 04:48:37PM +0100, Michael Ströder wrote:

> > Nested groups are very important especially in large enterprises, and really
> > do assist with data management.
> 
> I am always getting told this but I have strong doubts about nested groups.

Groups are usually there to define permissions - the Authorisation
part of the AAA triple. Allowing nested groups helps to decouple
individual users from individual permissions. For example:

	The Helpdesk group contains a, b, c, d
	The SysManagers group contains e, f
	The PasswordRestKiosk group contains j, k, l, m
	The AccountProvisioning group contains p

I can now write permission rules like:

	Members of Helpdesk, PasswordRestKiosk, AccountProvisioning may set user passwords
	Members of SysManagers may set system-account passwords
	Members of Helpdesk, AccountProvisioning may change user contact data

where each of the rules is expressed as a group whose members are
other groups. It is easy to explain such rules, and easy to maintain
them as they are visibale as data in the LDAP tree.
I think this is a lot better than maintaining flat groups like:

	UserPasswordSetGroup contains a, b, c, d, j, k, l, m, p
	SysPasswordResetGroup contains e, f
	UserContactModifyGroup contains a, b, c, d, p

> >  Yes we'll get more search operations, but I
> > don't think this will be a problem.  I should be able to prove this will work
> > in my reference implementation.
> 
> Resolving nested group membership is a big performance cost. I can see this
> with a MS Sharepoint installation working with a OpenLDAP server. Sharepoint
> sends many search requests even though nested groups are not used in this
> deployment.

That is because there is no standard schema for nested groups, so
there is no server-side support to make them efficient. [In fact
many LDAP server implementations do define their own nesting
schemes, but I don't think any of them are shared with other
unrelated implementations.]

You and I started trying to sort this out after the first LDAP
conference, but the effort got bogged down. Maybe we should dust off
the drafts and see if anything can be salvaged.

> Also nested groups are a pain if you want to report all effective user rights
> to auditors (which is something banks have to do at least once per year). In
> this context even maintaining the group membership does not look that simple
> anymore.

I don't see that it adds much to the work. If the server supports
nested groups then it is a single query; otherwise it is a series of
derefs. (I am assuming a simple two-level nesting here as I can see
many uses for that without making the rules too complex.)

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------