Grouper Developers Forum

[Bert Bee-Lindgren <>]

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?