Grouper Users - Open Discussion List

["Michael R. Gettes" <>]

Allow me to correct myself on one point from my earlier reply.

PSPNG, I believe, would still need to change in two respects.  Only perform "group add" in the error handling of "member add" when you see the group does not exist in LDAP.  I believe with the “ghost” member, you will have issues with removing the final member of the group before you see the add of the “ghost” member.  You could decide that add of “ghost” member implies delete of all member attributes and an add of the “ghost” in one LDAP operation to resolve the lingering last member.  This implies PSPNG would need to know the DN of the ghost member if ghost operation of grouper was in effect.  When you get an error on remove of a member, you should log and ignore it (or ignore for just objectclass violations and attribute doesn’t exist).  Otherwise, what I describe should work for any LDAP server.

/mrg

On Jan 15, 2017, at 11:47, Michael R. Gettes <> wrote:

+1 to Dave.  (actually, +1000000000)

now, even tho i disagree with Mr. Fox (and Curry) about the need to even solve this problem I would like to see if there is a way to address the requirements stated.  What I “hear” is a desire to have the state of a grouper group properly reflected into LDAP (and other applications) even when the group is empty.  If that is an effective description of the problem, then this problem must not be solved by PSPNG as it provisions a subset of what interacts with Grouper.  I believe the proper solution would be to have an option (not the default) for grouper to detect the case where a group has no members and add to the group the “ghost” member.  The “ghost” member should behave like any other member of a group (however, maybe you don’t want to allow it to be deleted?).  When other members are added to the group, the “ghost” can be removed.  We are implementing identity management services here - so the very notion of a “ghost” member should throw us all into a tizzy.  I can’t support the notion of a “ghost” member - it’s just wrong.  So, a “ghost" member is a subject - all subjects must be defined in a subject source for grouper - and most logically the person subject source which would be taken from your identity management system.  This way, all applications in your identity eco-system will be able to properly reference the “ghost”.  Now you won’t have LDAP based applications having groups different than non-LDAP apps.  You won’t have LDAP based applications needing additional data from other identity services (your registry) having to deal with the special “ghost” situation.  And, PSPNG wouldn’t have to change.  

I believe this would address the concerns/desires stated thus far and would be a more holistic approach and not one based on exception(s).

Thoughts?

/mrg

On Jan 15, 2017, at 10:54, David Langenberg <> wrote:

... but at what expense?  Sure, we'd now have the ldap reflect grouper, and then apps written to the standard now will encounter unknown issues as the number of groups visible and useless to it increases. The access management provisioners should conform to the limitations and standard of the targets, not the other way around. 

Dave

David Langenberg

Asst. Director, Identity Management 

The University of Chicago 

Sent from my iPhone 

On Jan 15, 2017, at 9:15 AM, Curry, Warren <> wrote:

+1.  Jims observation is on target.  

Sent from my Verizon Wireless 4G LTE DROID

On Jan 15, 2017 1:44 AM, Jim Fox <> wrote:

I disagree completely.  There is a world of difference between a group without members and a non-existent group.  The LDAP ought to reflect the state of Grouper as best it can,  In this case it cannot do that exactly.  Either the group is deleted or there is a ghost member.  I claim the latter is the path that preserves the most correct representation of the group.

As a practical matter LDAP has specific error codes when the memberless situation occurs.  It can be quite easily handled without a lot of overhead.

Jim

________________________________________
From:  <> on behalf of David Langenberg <>
Sent: Saturday, January 14, 2017 8:35 AM
To: Michael R. Gettes; John Gasper
Cc: Bert Lindgren; 
Subject: Re: [grouper-users] PSPNG: Handling groups that require a member

+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<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.internet2.edu_jira_browse_GRP-2D1376&d=DQMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=01PV2kvhCtqOq8iLMPoAa2RTSGhVGsbUlNhPgagpxV8&m=rPbogwtkusJu9_2a-zlMMifkqWE3OFHCqvrgODpDOjs&s=6b5zWCJsLLQLrNqL8-OcoIctLehASoioIKkt2lvF2p4&e=>.

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