Grouper Users - Open Discussion List

["Bee-Lindgren, Bert" <>]

Michael,

>  I am afraid I am not appreciating the reasoning for the “faux” member approach.

I understand that the LDAP standard has been around forever. I'd say that the faux-member approach is driven by our desires for Performance and Consistency/simplicity (where possible).

Could we standardize on the same group-/membership-lifecycle where we treat all groups as if they require members:

No. We cannot take the delete-when-empty approach for all LDAP groups, as it would totally break active directory. So, we need to do something different. We also benefit from seeing an empty group created when it's created in Grouper.

Choice 1: Dedicated code for provisioning groups with required members. This is obviously possible since people have been doing it forever. This will create groups and delete members differently than we do for other ldap-group targets. It will probably be slower and/or noisier when a last member is being removed.  

Choice 2: Graft on support support of required memberships onto the existing ldap-group provisioner with a "faux" member approach. We need to decide if those memberships should be permanent or not, where temporary faux memberships mean extra handling of membership removals.

This all said, we'll create the group provisioner(s) we need. This conversation is just asking if we really need two different group- and membership- lifecycles.

Thanks,

  Bert

---

From: Michael R Gettes <>
Sent: Wednesday, January 11, 2017 1:40 PM
To: Bee-Lindgren, Bert
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