Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting
March 7, 2007

*Attendees*
Tom Barton, U. Chicago (chair)
Blair Christensen, U. Chicago
Gary Brown, U. Bristol
R.L. "Bob" Morgan, U. Washington
Kathryn Huxtable, U. Kansas
Chris Hyzer, Penn State U.
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Blair} will send a link to a document describing the Shibboleth extension framework.
[AI] {Kathryn} will look at source adapter implementations from classes, for the Subject API.
[AI] {Kathryn} will email the list with a proposal about giving class structure differences, and why a more inclusive product would be more useful than a provisioning connector that only works for LDAP.
[AI] {Kathryn} will add a test case for prepared statements, offering a descriptive example to show how it is done.

Carry-Over *Action Items*
[AI] {Kathryn and Dave} will investigate Subject API matters, relating to the prepared statement and use of Velocity. (21-Feb-07)
[AI] {Joy} will share a write-up of a Cornell use case for the provisioning connector regarding the preservation of security for a query for group attributes. (9-Nov-06)

 

*Agenda*
1. Extension framework for grouper build process
2. Subject API v.next
3. Ldappc enhancement for provisioning signet permissions

*Discussion*

-Prepared Statements in the Subject API-
The Group opened with a brief discussion of prepared statements within the Subject API. {Kathryn} said the syntax is different, and that she does want people to make changes to the config files. Others agreed that this would be fine, given the ease of making a syntax change. {Blair} suggested upping the Subject API version to 0.3.0, and the Group accepted. Additional discussion will continue offline. [AI] {Kathryn} will add a test case for prepared statements, offering a descriptive example to show how it is done.

{Gary} also added that one of the difficulties of using syntax for prepared statements is that it does not give named parameters. There is no way in the API to have multiple search queries; perhaps an extension would allow you to use another query.

- Extension framework for grouper build process
{Blair} discussed the extension framework around Shibboleth, such that dropping in a properly formed directory structure will be compiled. He is interested in having Grouper offer the same, i.e., for gsh, etc. He anticipates it will be in place with the coming of the next release. {Tom} said it would benefit others wanting to add framework or suggest changes. {Gary} discussed how it relates to the UI, saying he was interested in people being able to call their own class, such that a there is a hook for a build script to run and make properties available. Another possibility is to have the API plug into the UI. {Tom} said it would be good to have a common extension, not one per component in the UI. He also mentioned GridShib, which uses a framework that integrates some extension but requires that you articulate others. [AI] {Blair} will send a link to a document describing the Shibboleth extension framework.

-Subject API v.next-
{Tom} reviewed the <grouper-develop> mailing list archives to retrieve discussion of the Subject API from the last 10 months (cf. Tom's email, 5-Mar-07; Subject: Subject API 1.0 restart) [0].

[AI] {Kathryn} will look at source adapter implementations from classes, for the Subject API.

-LDAPPC enhancement for provisioning signet permissions
LDAPPC can provision as a string or as an LDAP object. The schema is designed to reflect the structure of that string. For any given permission, it is essential to have some mapping capability, i.e., that there is some way of computing an associated value or mapping value.

{Kathryn} mentioned some work that her campus had done prior to the release of LDAPPC. They have been provisioning with Grouper since November, along with their Identity Management group. She discussed particular mappings that they have done for creating a group with an entitlement, etc.

[AI] {Kathryn} will email the list with a proposal about giving class structure differences, and why a more inclusive product would be more useful than a provisioning connector that only works for LDAP.

The next Grouper Working Group call will be on March 21, 2007 at 12pm EST.

 

"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

[0] (cf. Tom's email, 5-Mar-07; Subject: Subject API 1.0 restart)

1. Strip Subject type of its identifying status.

v1.0 Subjects will be identified by their sourceId and subjectId. Type will remain an attribute of a source. We didn't cleanly determine if its value should be exposed as a Subject attribute or not, but that seems the logical thing to do. It needs to be conveniently exposed, and that would satisfy a conceptual desire (and potential operational need) to see Subject objects with their types stamped right on them.

We also discussed whether the "sourceId" should in fact be renamed "typeId", making it likelier that deployers would choose identifiers that would transcend temporal vagaries of how a site persists different
types over time. We left the term unchanged, but admonished ourselves to ensure that future documentation should clarify what the terms themselves cannot. Think of (sourceId, subjectId) as (namespaceUsedForThisType, uniqueIdWithinNamespace).

2. Reduce type to a string, lose the enumeration.

3. Specify a capability that supports iterating over sources and types.

Whether that would be an enhancement of SourceManager or a new interface (something like grouper's SubjectFinder, perhaps) was not determined, though there was a leaning towards the latter.

4. Determine a configuration and initialization strategy that decouples source adapter implementations from classes in the reference source adapters.

We didn't detail or discuss this item on the signet-dev list, though it was much talked about among a few of us offline. This is probably the most substantial piece of unfinished business that would be great to fold into Subject API v1.0.

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

The Large Hadron Collider. Internet2.
1,000,000,000,000,000 bytes per year. A network built to move them.
http://www.internet2.edu/science