Grouper Users - Open Discussion List

[Chris Hyzer <>]

Michael, Rahul,

 

Please let me know what requirements are not met by this suggestion:

 

1.       The Grouper team can modify the LDAP and JDBC2 (not JDBC) subject sources in the following way.

 

If subject sources had this param:

 

        <param>

           <param-name>statusAttribute</param-name>

            <param-value>

                status

            </param-value>

        </param>

        <param>

            <param-name>inactiveStatusValue</param-name>

            <param-value>

                inactive

            </param-value>

        </param>

        <param>

            <param-name>defaultStatusExpression</param-name>

            <param-value>

                status!=inactive

            </param-value>

        </param>

 

Then an LDAP or JDBC2 source could take advantage of it where by default it would filter by not inactive (in LDAP, just wrap the filter in an & and add that _expression_).  If something special is in the search input, E.g. status=all, status=active, status!=active, status=inactive, then it would take that into account.  Note, if status is all, then no _expression_ needs to be added to the query.  So… maybe the UI could have a checkbox that says “include inactives” or something to make it easier for users…  worst case it could just be _javascript_ to add “status=inactive” or “status=all” to the input field.

 

As far as the composites or loader or whatever, let me copy a modified version of what I had below:

 

1.       Identify the populations who have access to GA: e.g. students, faculty, staff, ad hoc  (note, students/faculty/staff are loaded by the grouper loader, so inactives wont be in there)

2.       Make a GA groups:

a.       school:it:apps:googleApps:groups:allUsers

b.      school:it:apps:googleApps:groups:adHoc

c.       Add groups to allUsers:      school:community:students, school:community:faculty, school:community:staff, school:it:apps:googleApps:groups:adHoc

3.       Then, if the ad hoc users need to be active, either add a rule that says if a user is not in school:community:activePeople then remove them, or do a composite group that requires activePeople to be in the overall adHoc group

 

If you arent using the loader or you want a group of provisioned users or something, then make that group:

 

a.       school:it:apps:googleApps:groups:provisionedUsers

b.      school:it:apps:googleApps:groups:allUsers   (which is a composite intersection of provisionedUsers and school:community:activePeople).  Anyone is not in activePeople will not be in allUsers

c.       If you want to know who is provisioned and not active, you could do a group: school:it:apps:googleApps:groups:provisionedUsersInactive which is a composite of provisionedUsers minus activePeople.  You can always query for this if you need it infrequently, we have never needed this type of group at Penn

 

Anyways, then you don’t need the shadow groups when people move back and forth.

 

Thoughts?

 

Thanks,

Chris

 

 

 

From: [mailto:] On Behalf Of Chris Hyzer
Sent: Thursday, April 04, 2013 9:55 AM
To: Michael R. Gettes
Cc: Rahul Doshi;
Subject: RE: [grouper-users] multiple subject sources

 

 

>

> why would i want my users to see inactive people let alone add an inactive

> identity to a group?

>

 

Inactive users definitely need to show on the screen… If someone is looking at members of a group, and that group has a member who has recently become inactive, they need to see their name/description instead of just their institution ID (e.g. 12345678).  Or if someone is looking through audit history, so see who did something, or what was done to someone, you would want to see the name of the person and description.  I think there is a disconnect about what a subject source is.  It is just a repository of entities and a way to look them up, search for them, etc.  If there is a subject which is not used in grouper, and is no longer active, then it can be removed from a subject source.  If there are any references to that user in the grouper_members table and references to the grouper_members row, then it really should not be removed from the subject source.  Its like Atlassian, if you have an external user which is not findable anymore, Jira screens wont even display anymore.  If you want to remove a user from Jira, you remove them from groups which have authorizations, not remove the subject from the external subject source.  Basically the subject source should not be used for authorization, it is just a linking of subject id and name/description/netId.  I think it would be really useful to find a way to satisfy your requirements without taking inactives out of the subject source.

 

There are problems with “inactive”.  Different people have different definitions of when someone is “inactive”.  Also, even though there is not an active affiliation with your institution, people might need access to resources.  If someone is on long-term disability, are they active?  Someone who has been retired for 5 days?  Someone who is collecting a severance package?  Someone who was visiting your institution and went back to their home institution?  Will those people need access to any resources?  Might someone want to add them to a group or remove them from a group or see if they are in a group?

 

> 4.       If the user was mistakenly marked as inactive, and they are reactivated,

> should all their old memberships/privileges reappear?  What amount of time should

> elapse when things are permanent if any?

>

> is there some way to say "show me all memberships/privs for a user at a point in

> time?  Could I then click restore-all or selectively restore?

>

 

Well, if you don’t do the USDU remove of the subject, then if the removed subject is added back to the active subject source, then all their previous assignments will be there.  But after that, you would have to go to point in time, which I don’t know of a friendly way to do this, but it would be a useful UI feature, or at least useful to document how to do this manually…

 

>

> 5.       You mentioned this is at the Group level.  So some groups have this method

> and some don’t?

>

> i have a use case for the group level, or we think it is at the group level, yes. 

> We want to have 2 groups:  1 - active Google Apps users.  2 - Former GA users. 

> If a user becomes suspended, they are no longer active and we would move them

> from the group 1 to group 2.  Group 2 would be defined to go against the same

> "physical" subject store but with different parameters to allow the subject

> store to see inactive users.  We want careful control over who (or what in the

> case of a group), gets to see inactive users.  I hope this helps.

>

 

So what you are saying is that the active subject would be removed from the active google apps users, and the newly created inactive subject will be added to the former GA users?

 

How we would do this at penn is:

 

4.       Identify the populations who have access to GA: e.g. students, faculty, staff, ad hoc  (note, students/faculty/staff are loaded by the grouper loader, so inactives wont be in there)

5.       Make a GA groups:

a.       school:it:apps:googleApps:groups:allUsers

b.      school:it:apps:googleApps:groups:adHoc

c.       Add groups to allUsers:      school:community:students, school:community:faculty, school:community:staff, school:it:apps:googleApps:groups:adHoc

6.       Then, if the ad hoc users need to be active, either add a rule that says if a user is not in school:community:activePeople then remove them, or do a composite group that requires activePeople to be in the overall adHoc group

 

So you wont have inactive people using google apps, but there is nothing that will remove users from other groups once they become inactive since there are other groups that do not want that.

 

The UI would need to be very clear when searching for subjects so average grouper end users know to click an extra button if looking for someone not directly affiliated with the institution.

 

Thanks,

Chris