Grouper Developers Forum

[Chris Hyzer <>]

Sometime soon I will try to make a generic loader for simple SQL loads.  There is also vision in grouper for a larger scale loader that might be external to grouper (a la ldappc).  Also, with some examples (like the one I want to make), it will be easier to make one’s own custom loader (e.g. to update memberships based on data in person registry).

 

You mentioned being in a role only if in another role.   Assuming role means group, one solution with grouper was our discussion last month:

 

https://mail.internet2.edu/wws/arc/grouper-users/2008-03/msg00006.html

 

I would be interested in a DB audit table which keeps important grouper history.  We have a similar thing at Penn for our custom apps and it works well.  Just need to not put enough but not too much info in there, and keep it clean (delete the deletable parts that are older than X).  This can be a solution to the membership history problem, and the “Former” or maybe “Disabled” status of a membership.  Of course it would keep track of who or what made the change, from where, etc

 

I’d also be interested in group and membership enabledDate and disabledDate columns.  What is the current thought about this from other Grouper team members?  Is it not what grouper should do, or has it been too complicated to implement, or not enough demand?

 

Some of your other thoughts might require a membership attribute list (similar to your Membership Factor) which doesn’t currently exist (and your custom loader could be based on an attribute you add to a membership)… e.g. an attribute that says “onlyWhileJobTitle__Financial Analyst”, then your daemon could process that when you see the person’s data change in the person registry.

 

Im not sure how a “Pending requirement” state of a membership would work.  Maybe something in the audit log would help.  Also, Im not sure that the “pending”, “disabled” etc would go to LDAP, or if LDAP should a point-in-time registry of memberships…  so the ways to access this info are the UI or WS.

 

“Separate groups for each Role”, not sure what this means, you mean attributes about a person should not be groups?  The subject API can handle attributes of a person, which could help...

 

Chris

 

 

 

 

 

 

 

 

 

 

From: Bert Bee-Lindgren [mailto:]
Sent: Tuesday, April 22, 2008 7:59 AM
To: Grouper Dev
Subject: [grouper-dev] Groups, roles, loading, lifecycle

 

Since yesterday's I2 meeting didn't include much conversation about automating group maintenance, I thought I'd send this email to describe our (Gatech's) near-term Role/Group/Authorization lifecycle management goals.  My purpose in writing this is to see what collaborative interest there is within grouper-dev for this -- today or once it's up and running.

 

Thanks,

  Bert

 

 

At the highest level, we need to publish up to date information about people's roles:

          Each person would have lots of RoleId/Status tuples, where status is {Enabled, Disabled, PendingRequirements, Former}

 

and maintain people's history

          What roles people have today and why and how this has changed in the past

 

At a functional level, we need to add/remove/disable/etc people's roles based on the following:

 -Rules matching (or not matching) people's data and groups in our Person Registry

 -People's membership in other roles

 -Manually grants/denies which can automatically expire based on Time, Role-membership or Person Registry data patterns

 

Therefore, we are building a role system that uses the following combinations of data and purpose:

 

Purpose              Data/Groups      Roles         Manual

Enabling                 Y              Y             Y

Disabling                Y              Y             Y

RequirementSetting       N              Y            (Y)

 

 

 

Here are some random thoughts:

 

What is the development state?

          Starting from a PoC system that is in Beta at Gatech which does Positive LDAP Filters, and Persistent/Non-Persistent+Positive/Negative overrides

 

          New system: 

                      SQL Schema, Java Data and ORM: Done

                      Java Logic: underway, about to copy logic from PoC into larger and more-flexible data model

                      User interface: Does not exist

 

How does this Role System tie into Grouper & Signet?

          Our current pilot/PoC system (which implements 3 of the 7 Ys in the table) saves the membership status in SQL and then publishes changes to our PReg. I see it instead adding & removing members from grouper. Grouper & ldappc would then be responsible for publishing group membership.

 

 

Why tie into grouper?

          Elimination of (a little) custom code that does the LDAP provisioning, but instead does soap, of course [not a big win]

          Publishing to multiple group destinations (PReg, Active Directory, etc)

          Increased utility of Role System to other institutions, and, therefore, increased partnership on its development

 

 

Why not use grouper's UI for manual overrides?

          Automatic override removal options do not exist in Grouper's UI

          Diagnostic/Audit logging incompleteness (Admin username, comment) and separation across multiple systems

          Would not go through requirement or disabling checking

          Would require double-maintenance of Admin access rights

 

 

How will manual overrides automatically go away?

          When overrides are established, the administrative user will be able to define any (one) of the following

                      Expiration date ("Until May 1, 2008 10am")

                      Sustaining role membership ("As long as Joe is in the Employee Role")

                      Sustaining PReg data ("As long as Joe's job title is XYZ")

 

          Additionally, overrides can be non-persistent which means the override goes away when an automated factor agrees with the override. (The manual grant to that early-arriving faculty member goes away when the PReg has the data that automatically authorizes them)

 

 

Differences in Person Registries [SQL vs LDAP vs etc]

          A huge majority of the work is atop an abstract MembershipFactor class. This majority includes Timers, overrides, access-control, tracking and evaluating multiple matching membership factors, etc

          Yes, there will be work to genericise the data the engine gets from and hands to its (local) concrete MembershipFactor classes

          I don't know enough about the Subject API to know if provides anything beyond a more-generic identifier

 

 

When will automated factors be reevaluated?

          Given a feed of changed people, we will be processing that queue every X seconds

          During this time, we will also process expired overrides and other timers

          Our current PoC system does this today with the help of a change-feed from our LDAP directory servers

 

 

How I might differentiate between Roles vs Authorization vs (signet) Privileges:

          Authorizations often have one or more

                      Grace Periods so people can clean up their resources

                      Disabled time so resources are kept after users are locked out, in case it was a mistake or so fewer files need to be restored from backup

                      Former time so loosely coupled systems (daily cron job) know who to deprovision

 

          Roles often don't have the timers that authorizations often do

 

          What about roles vs timerless authorizations? Doesn't matter, just call them all roles

 

          Privileges: 

                      Signet introduces scope and limits to authorizations. 

                      There is overlap between expiration-date limits (to be supported in the Role System) and signet Limits, but Signet uniquely has repeating limits (Time of Day, etc)

 

Why publish non-enabled membership states (Disabled, Pending Requirements, Former)?

          It might help end users or service administrators quickly see why a user cannot access a service

          It indicates to a provisioned service that it should stay provisioned (disabled) or be deprovisioned (former)

          A service might choose to display a clue to an unauthorized user why they are not able to access the system

 

 

Open questions:

          How do we handle non-enabled states (Disabled/PendingRequirements/Former) with Grouper? 

                      -Separate groups for each Role? [Ugh]

                      -LDAPPC take state into account at provisioning time?

 

          How do we make the storage of people-matching patterns generic across the different types of people registries?