Grouper Users - Open Discussion List

[Kathryn Huxtable <>]

Sure.

We've been using the eduPersonEntitlement attribute for awhile now to
support access to Great Plains Network applications using Shibboleth, and
also to support internal access control to web applications via both
Shibboleth and our homegrown ISO, Argus, which is also attribute based.

But we've been populating it from a database table with no UI or API to
populate *that*. So when someone needed access to a resource, someone in
Identity Management would manually insert a record using SQL. It was a pain.
We had a UI for a previous access control mechanism and had thought of
porting it, but Grouper was coming along and we decide to use that.

To start with, we created a stem hierarchy that mimics the university
administrative structure. So for example, Identity Management is under
Information Technology, which is under Information Services (IS includes
libraries).

We created a custom group type called "entitlement" with the attribute
"eduPersonEntitlement", which is required, and contains the URI for the
eduPersonEntitlement value to be provisioned from that group.

Since we in Identity Management need control over the eduPersonEntitlement
namespace, we only provision the entitlement values from groups under a
particular stem, which we administer.

To give external people on campus, the Political Science department, say,
the ability to manage their own entitlements, they can create a group in
their own stem and manage it how they like. We include that group as the
sole member of the group in our Identity Management provisioning stem which
provisions the eduPersonEntitlement values.

I expect a similar scheme will be used for other flat namespaces such as
email distribution lists. We desperately need a better scheme for
provisioning them.

For groups, we are planning something much like the "bushy" scheme in the
RFQ for your provisioning connector.

The way we're actually provisioning the groups is thus: we created an action
table in the grouper schema called provision_action and created a trigger
for insert or delete rows on the grouper_memberships table that adds a row
to provision_action indicating the group_id, the subject_id, and whether
it's an insert or delete action. (Are there ever update actions performed on
grouper_membership, and if so, why?)

A background process checks the provision_action table for new actions and
throws away the ones that don't have special external group types.

A separate background process for each external entity being provisioned
will check the provision_action table for new actions for its groups and in
the case of entitlements throw away any records from groups outside the
provisioning stem and update our directory with the rest.

A side effect of handling it this way is that a single group can only
process a single type of external provisioning, but I don't see that as a
problem. You can always have a base group with your membership and then have
that group as a member of multiple groups that each provision a different
thing.

If this becomes onerous, we can revisit the way we do the external
provisioning, e.g. Using a series of flags instead of a single flag to
indicate that an action has been processed.

A nightly cron job deletes moldy actions.

This way, I had no need to modify the API at all.

BTW, I'm not using the Grouper API for my background processes. Since they
are basically scheduled jobs and have very simple needs, they're just
30-line Perl scripts. I see no need to bring out the big guns of Java for
this, with its memory overhead and generally large footprint.

-K

--
Kathryn Huxtable
Middleware Architect
Identity Management
Information Technology, a division of Information Services
The University of Kansas
785-864-0420


On 10/24/06 8:49 AM, "Tom Barton" 
<>
 wrote:

> 
> 
> Kathryn Huxtable wrote:
>> We are now using Grouper to populate eduPersonEntitlement and will soon be
>> populating LDAP groups.
> 
> Great! Are there any details you can share about implementation and
> deployment choices like how you're using custom grouper attributes,
> naming stem usage, subject sources, etc? And about some of the specific
> application use cases you are or will soon be supporting?
> 
> Tom