Grouper Users - Open Discussion List

[Jim Fox <>]

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 
<<mailto:>>
 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: 
<<mailto:>>
 on behalf of Michael R Gettes 
<<mailto:>>
Date: Wednesday, January 11, 2017 at 10:40 AM
To: Bert Lindgren 
<<mailto:>>
Cc: 
"<mailto:>"
 
<<mailto:>>
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 
<<mailto:>>
 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