Notes from CAMP
Breakout session
Providing input to perMIT and Grouper projects
Our raw notes. Questions welcome but I got caught up in the conversations.
Begin forwarded message:
From: Chris Hyzer <mchyzer@isc.upenn.edu>
Date: June 17, 2009 1:00:31 AM EDT
To: tom dopirak <tgd@andrew.cmu.edu>, "Paul B. Hill" <pbh@MIT.EDU>
Subject: RE: notes from grouper/permit session -- I am afraid I got carried away listening an not note taking, let me do some editing.
Tom, thanks a lot for taking notes (and volunteering to present back to the group 
)
Here are some edits:
Scenario - We have an IDM application but not a centralized AD, we are
looking at bringing up a central AD to support sso and file sharing.
Do we want folks to use the Identity Manager or some other way?
a- We have been running enterprise group management at MIT for
sometime and feeds AD. The groups are mostly adhoc and managed by end
users . There are over 200,000 groups with about 24,000 active users.
If you wanted to use institutional data use ldappc to push the data
into AD.
a - Grouper has three ways of pushing data : sql-loader, web service
FROM: pushing TO: pulling
interface and ldappc
For pushing, it is the upcoming Grouper notification / change log for incremental provisioning out (or read from ldap or web service)
There are other ways like permit to solve a set of problems
other
than simply group membership e.g. MIT perMIT
a - in perMIT "canwrite to file share" " filesharename" these can be
flattened to a group name for groups based access
a/hy - attributes will be connect to groups , to minimize having to
Attributes will connect to groups, folders, memberships, or subjects. We will be able to support hierarchies of roles, permissions, and of course group memberships so you can have as elegant (or complicated ) a structure as you want
create long names
a/h- for small groups , less than 500 , doing adhoc groups is not much
of a burden.
a/h - begins to talk to a use case with two classes sharing a
fngileshare, one reading and one reading and writing
function = ( can create video, can read video, can write
critique,
can read critique)
1. get data from lms and populate subjects into permits
a/h-Grouper would populate groups with the memberships of the two
classes and add an attribute to designate the "verb"/function
a/Hill- with a well developed application they are likely going to
use for example AD security descriptors for all authorization, you
can set a registry key so that group membership are not passed in
kerberos tickets
q; what will most linux kinds of applications do
a: java acegi or ldap calls
q: we have a master admin accounts system , users are mapped to role
and sources( secondary identified source) how can perMIT support roles?
a: are you talking about traditional rbac roles
q: yes
a: perMIT has some role concepts : primary authorizer
, principle
investigator,
q: do you support workflow
a: not really, the roles maybe be part of the authorization system
Discussion about precalculating memberships in nested groups
q: does the permit have to know about a subject before it can be
assigned or can users type a random but unique string
a: in general folks felt this was unwise and the subject name had to
be verified
q: should group information be kept in saml assertion?
a: no particular needs expressed except a desire from CMU's KS
implementation to have the option given their web services
implementation
q: have you looked at implementing Kuali authorization services on top
of perMIT
a: yes and for the KS service definitions we think we can implement
it as a layer
q: how do you support confluence
a: confluence has an ldap plugin but you had to do authenication via
ldap at one point, an option can allow you to use shib for
authentication. There ldap connector doesn't support ldap mods .
Tom Dopirak
tgd@andrew.cmu.edu
Senior Consulting Architect, OWC