Grouper Users - Open Discussion List

[Jim Fox <>]

1) I do not believe Grouper should be constrained by LDAP.  so I reject the 
idea the Grouper fix this---except as it is embodied in pspng .
2) I do not believe an empty group is both "visible and useless".  'Member 
not found' means, say, that a user does not have an authorization.  Whereas 
'Group not found' indicates a configuration error.

Do we know of examples where an LDAP client would be disabled by a ghost 
member of a group?

Jim

________________________________________
From: 

 
<>
 on behalf of Michael R. Gettes 
<>
Sent: Sunday, January 15, 2017 9:30:42 AM
To: David Langenberg
Cc: Warren Curry; Jim Fox; 
;
 Bert Lindgren; John Gasper
Subject: Re: [grouper-users] PSPNG: Handling groups that require a member

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 
<<mailto:>>
 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 
<<mailto:>>
 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 
<<mailto:>>
 wrote:

+1.  Jims observation is on target.

Sent from my Verizon Wireless 4G LTE DROID
On Jan 15, 2017 1:44 AM, Jim Fox 
<<mailto:>>
 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: 
<mailto:>
 
<<mailto:>>
 on behalf of David Langenberg 
<<mailto:>>
Sent: Saturday, January 14, 2017 8:35 AM
To: Michael R. Gettes; John Gasper
Cc: Bert Lindgren; 
<mailto:>
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: 
<<mailto:>>
 on behalf of "Michael R. Gettes" 
<<mailto:>>
Date: Friday, January 13, 2017 at 9:18 PM
To: John Gasper 
<<mailto:>>
Cc: Bert Lindgren 
<<mailto:>>,
 
"<mailto:>"
 
<<mailto:>>
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:><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:><mailto:>>
 on behalf of Michael R Gettes 
<<mailto:><mailto:>>
Date: Wednesday, January 11, 2017 at 10:40 AM
To: Bert Lindgren 
<<mailto:><mailto:>>
Cc: 
"<mailto:><mailto:>"
 
<<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:><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