Grouper Users - Open Discussion List

[David Langenberg <>]

+1 to Gettes’ idea.  Faux data is a recipe for long-term confusion at best.  Far better to implement better exception handling for adding members to non-existent groups / removing groups where you haven’t yet seen the remove-member calls.  An alternate would be implementing a queue+delay mechanism.  We have a similar process here internally which had problems with out-of-order event processing.  Our solution was to queue & delay within the app until the object received no more updates for a pre-determined amount of time (5 seconds was enough in our process), then calculate and batch update the object in target system.  I’m not sure my alternate approach would be practical for grouper, esp if there’s a lot of changes going on, but it’s an idea.

 

Dave

 

-- 

David Langenberg

Asst Director, Identity Management

The University of Chicago

 

From: <> on behalf of "Michael R. Gettes" <>
Date: Friday, January 13, 2017 at 9:18 PM
To: John Gasper <>
Cc: Bert Lindgren <>, "" <>
Subject: Re: [grouper-users] PSPNG: Handling groups that require a member

 

ok.  Thanks John, I am better appreciating the perspective.  Nonetheless, don’t do the faux-member, please.  a faux member, to me, is unclean, apps won’t understand, users will be confused, it’s just not right.

 

Is the issue really the saving of the create-group request?  If so, then handle the create group in error handling of adding a member.  don’t process create group requests.  You attempt to add a member to a group and get back “no such object”.  Create the group based on what is inside Grouper and then either re-prime the add member function or call it directly from the error processing.  Is this somehow a bad idea?  For those who have directory environments where a group can exist without members, then the create group is processed when seen and you don’t delete the group with no members and only on a remove group request.  I am sure I am missing something here so please edumacate me.  Bert, my apologies for not appreciating your original explanation.

 

/mrg

 

On Jan 11, 2017, at 15:55, John Gasper <> wrote:

 

I’m not saying it is right or wrong, but while X.500/RFC256 does require at least one membership to be assigned when creating a group, this requirement has been removed in directories such as 389-ds and Active Directory (and as Bert points out AD does its own thing, but functionally the requirement is removed). And even in directories (e.g. OpenLDAP) that require a member, it does not require a member value to be present. So while the attribute is required, no value is required. Go figure. I’ve seen suggestions on the OpenLDAP list for folks to change the schema to change uniqueMember, etc to be a MAY instead of a MUST to accommodate this issue that Bert is discussing.

 

I don’t like the faux member approach, but from a transactional system and even queuing system standpoint I see where Bert is coming from. It requires extra work to save a create-group request until a add-new-member request comes through. One can either do that extra work, or create a faux member. But it would also require extra work to then remove the faux member when a real member comes around, or when deleting the last member in a group adding the faux member back in. Unless the consensus was to just leave it around forever.

 

The PSP was able to overcome this problem but at great complexity.  My vote is for whatever makes for the relatively easiest coding and relatively easiest admin configuration which should make for better long-term sustainability of this module. Maybe the faux member is just the empty member referenced above.

 

Or just require adopters to change their schema… What no other takers on that? OK, nevermind.

 

-- 

John Gasper
IAM Consultant
Unicon, Inc.
PGP/GPG Key: 0xbafee3ef

 

 

From: <> on behalf of Michael R Gettes <>
Date: Wednesday, January 11, 2017 at 10:40 AM
To: Bert Lindgren <>
Cc: "" <>
Subject: Re: [grouper-users] PSPNG: Handling groups that require a member

 

Hi Bert,

 

I am afraid I am not appreciating the reasoning for the “faux” member approach.  The LDAP standard has been around for quite some time and whether using groupOfNames or groupOfUniqueNames objects, one membership is required to create the group object and if there are no members, then remove the group object.  Why should we be taking an alternate approach?

 

Thanks

 

/mrg

 

On Jan 11, 2017, at 11:54 AM, Bee-Lindgren, Bert <> wrote:

 

Hello,

 

I'm trying to start a discussion and get to a decision about how PSPNG should handle LDAP groups where the schema requires a value for the membership attribute. This will eventually lead to a solution for GRP-1376.

 

TL;DR: We would like to extend PSPNG's existing group-provisioning process to support group schemas that require members. However, we believe that this will require a pspng-configuration option that will enable persistent maintenance of a faux group member.

 

I don't know if any background is needed, but let's summarize by saying there are three flavors of group schemas in how they require or don't require memberships:

1) Standard LDAP Group objectclasses (rfc 2256) that require at least one member

2) Directory servers that have redefined the "standard" LDAP Group objectclasses in their default schemas. They don't require members

3) Directory servers (Active Directory) that have their own schemas that don't require members.

 

This thread is about how Grouper should support provisioning to (1).

 

In general, here are some observations:

- It's very good if all these (1)-(3) situations can be provisioned by PSPNG in a single implementation

 

- It's nice when groups go from new --> empty --> populated --> empty --> populated --> empty --> deleted in a nice, step-wise way. This means seeing the group in LDAP every step along the way.

 

- When removing the last member from a (1) group, the group needs to be deleted. It will likely slow down PSPNG noticeably if it has to read additional group information to avoid deletion-not-allowed errors or will create logging noise and modest slowness if the extra information is read in response to ldap errors to see if the group actually needs to be deleted.

 

- Sometimes, groups that are deleted and recreated aren't exactly the same. For example, a recreated Active Directory group would have a different SID. Therefore, we cannot standardize our handling of groups by implementing things as if they all require members.

 

- Type (1) groups today are created in (at least) some universities with an initial or persistent Faux member -- an account or dn that doesn't represent a real user. Pspng can be set up to do that today (by adding the Faux member to the group-creation template), but that member would be deleted during full-sync, resulting in errors when that is the last member or when another last member is eventually removed from a group.

 

My conclusions:

a) A single group-provisioning system can handle all the ldap group types, if we take the a Faux-member approach.

b) If Faux-members are too kludgy, then we'll need a separate, noisier and slower implementation that handles provisioning of groups that require members.

 

What do you all think about this?

 

Sincerely,

  Bert Bee-Lindgren

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature