Re: [ldapext] DBIS - new IETF drafts

Michael Ströder <michael@stroeder.com> Thu, 09 January 2014 20:40 UTC

Return-Path: <michael@stroeder.com>
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 414B61AE550 for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 12:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.839
X-Spam-Level:
X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
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 dOkPI7N4U7lF for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 12:40:28 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 52EED1AE16F for <ldapext@ietf.org>; Thu, 9 Jan 2014 12:40:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 1B4E56078D; Thu, 9 Jan 2014 21:40:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzbewO3S6lvO; Thu, 9 Jan 2014 21:40:12 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Str??der", Issuer "CA Cert Signing Authority" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 7BBA160702; Thu, 9 Jan 2014 20:40:11 +0000 (UTC)
Message-ID: <52CF0929.2020904@stroeder.com>
Date: Thu, 09 Jan 2014 21:40:09 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
MIME-Version: 1.0
To: Andrew Findlay <andrew.findlay@skills-1st.co.uk>, ldapext <ldapext@ietf.org>
References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <20140109180851.GW3938@slab.skills-1st.co.uk>
In-Reply-To: <20140109180851.GW3938@slab.skills-1st.co.uk>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060003000505070901040709"
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 20:40:30 -0000

Andrew Findlay wrote:
> 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

What you describe is rather assigning permissions to user groups. IMHO that's
not what people mean when they are talking about nested groups in general.

>> 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.]

Ok, let the server internally search all the group membership (like AD does
e.g. with tokenGroups attribute) would make things more effecient.

> 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.

Server-side resolving of nested groups were far beyond our former scope. But
we could try.

> 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.)

Aha, you're limiting to two levels... ;-)

Ciao, Michael.