Grouper Users - Open Discussion List

[Tom Barton <>]

--- Begin Message ---

• From: Tom Barton <>
• To: jpb <>
• Subject: Re: [grouper-dev] Grouper dev Action Item
• Date: Sat, 19 Feb 2005 21:33:33 +0100

I sent a longish and multifaceted email to grouper-users on 20050115 the last third or so of which sketches several ways that ismemberof style memberhsip information might be associated with a member object in ldap and still enable enforcement of privs using ldap ACLs. At least one of those ways - using subentries - seems applicable to the Brown situation. In any case, perhaps that email can serve as a starting point for discusion of how a connector can map grouper groups and their privs into ldap.

Tom

jpb wrote:

This 'action' item is a result of a comment I made at the end of the last grouper call.
I was wondering if anyone felt concerned over the lack of visibility control incurred when we populate 'ismemberof' in ldap. I'll keep quiet next time.

As most folks know we are using a group metadirectory here at Brown coincidentally called 'grouper'.
It was written locally by James Mathiesen circa 1993.
I believe Tom may have used

We use brown's grouper here for two major services, authorization (ismember) and group lists (members).

The authz component is used mostly by (another) locally written web authentication system WebAuth.
WebAuth uses the ismember to check membership in a grouper group contained in an .htaccess file typically.
Currently grouper gets about 3-5000 ismember hit's a day.
This is very bursty, and can change significantly when an event such as web grades happens.
So low latency and 24/7 authz would be a good thing.

The group list function is used by several ( yet other ) locally written bulkmailing systems.
These are used for directed messaging to targeted communities as well as the entire university.
Very high profile, so 24/7 is expected, latency not so important.

We currently provision groups via three paths, SIS feeds, HRS feeds and web interfaces.
The provisioning system only populates 'immediate' memberships.
These groups acls are set in such a way that grouper administrators cannot typically alter membership.
All groups used for authz and lists usually contain 'effective' memberships only.
For example the HR feed populates a group called EAB.AFFIL.VISITING_SCIENTIST.
The provisioning system will create a group called COMMUNITY.AFFIL.VISITING_SCIENTIST.
This group is acl'd so the COMMUNITY.ADMIN group may include this group in other groups.
In this way a group tree structure is built, culminating in a group like COMMUNITY.ALL.
COMMUNITY.ALL is our most often authz'd group (software downloads?) and is made up effective memberships of hundreds of other groups.
We currently provision about 2400 course groups and 500 or so HR type groups.

I first started taking a look at replacing our WebAuthz with ldap.
So, instead on calling a 'brown' grouper method such as ismember('John_Ballem',"department.cis").
I could, use an ldap filter instead.
(&(brownnetid=John_Ballem)(ismemberof=department.cis))

This works very well albeit 3X slower than the grouper method. (Brown's grouper runs in memory)
So I have a simple perl script that checks a persons grouper 'effective' membership and diffs it with 'ismemberof' in ldap.
Very simple.

A couple of weeks ago I thought I'd convert the ismember provisioning system to use java and mace grouper.

This would give me some java introduction (beyond hello world) and experience with the grouper api's.
I decided to use my perl provisioning script to generate xml.

So my entry xml looks like.

<subject>
<dn>brownUUID=236ee3ad-82fd-ef35-02f6-b80f069378f4,ou=People,dc=brown,dc=edu</dn>
<uuid>236ee3ad-82fd-ef35-02f6-b80f069378f4</uuid>
<name>jpb</name>
<type>person</type>
<group>brown:community:affil:all</group>
<group>brown:community:all</group>
<group>brown:community:cfs</group>
<group>brown:community:eab</group>
<group>brown:community:email</group>
<group>brown:community:employee:admin:all</group>
<group>brown:community:employee:administrative</group>
<group>brown:community:employee:all</group>
<group>brown:community:employee:oncampus</group>
<group>brown:community:employee:staff_only</group>
<group>brown:community:general</group>
<group>brown:community:netreg</group>
<group>brown:department:cis</group>
</subject>
<subject>

This file is read by my loader (subjectloader.java) which converts the 'group' list to a HashSet.
It then calls "listVals()" to get all memberships and turns that into a HashSet.
The two hashes are them sent to a method "hashDiff()".

// find the difference between A and B
// What happened to pass by reference?
public boolean hashDiff() {
HashSet left = this.hashA();
HashSet right = this.hashB();
left.removeAll(right);
right.removeAll(right);
if( left.size() > 0 || right.size() > 0)
return(true);
return(false);
}

After this hashA will contain the group adds and hashB has the deletes.

My connector (ldapconnector.java) can then be run.
Currently it uses a filter "(&(objectclass=browneduperson)(ismemberof=*))" to get the comparison set.
You'll notice a flaw in that it's not going to get any new members there.
It can also be used to sync a single member in this way. (uid=jpb) for example.
Again converting the ismemberof values to a HashSet and using the method above to test the membership HashSet.
Here is my ldap ismemberof attribute.

isMemberOf: community:affil:all
community:all
community:cfs
community:eab
community:email
community:employee:admin:all
community:employee:administrative
community:employee:all
community:employee:oncampus
community:employee:staff_only
community:general
community:netreg
department:cis


Originally the loader was setup to create nonexistent groups on the fly as it encountered them.
I'm currently working on a groups xml feed that will provision groups only.
This should allow me better configuration for acls and types.
I'll be looking forward to using group math to model mace grouper on our current grouper.

Oh, how did the subjects get in to grouper, it's not in the api yet?
I cheat and run Blair's excellent csv2subject program before the loader.

I'm using snippets directly from the Blair's examples in the contrib section, invaluable.
The grouper tests directory are another great source on grouper method usage.

Oh yeah, my original question that started this message goes something like this.

I create a group called, edu.brown.community.a
Another called, edu.brown.community.b

I give members of group edu.brown.services.bulkmail LIST acls to edu.brown.community.a
I give members of group edu.brown.services.webauth TEST acls to edu.brown.community.b
So webauth group members can test 'b' but not 'a'.
So using grouper acls you have fine granularity control over group access.

When I put them in ldap I get,

ismemberof:
edu.brown.community.a
edu.brown.community.b

Now anyone that has ldap visibility of the 'ismember' attribute can by default view all the users memberships.
That should be ok here, as we have rather central control of authz here, but for how long.

Another discussion along these lines could be group memberships for bulkmailers like sympa.
Static or dynamic and loss of viability acls in ldap.


Any questions/comments let me know.



-jpb

--- End Message ---