MACE-paccman call 8-May-2009

**Attending**

Tom Dopirak, CMU (chair)
Tom Barton, U. Chicago
Steve Carmody, Brown
Tom Barton, U. Chicago
Michael Gettes, MIT
Jim Repa, MIT
Paul Hill, MIT
Ben Oshrin, Rutgers
Andrew Petro, Unicon
Lynn Garrison, Penn State
Chris Hyzer, U. Penn
Steve Olshansky, Internet2
Renee Frost, Internet2
Ann West, EDUCAUSE/Internet2
Emily Eisbruch, Internet2 (scribe)

**New Action Items**

[AI] (U. Penn) and (CMU) will add use cases to the wiki.
https://spaces.internet2.edu/display/macepaccman/Use+Cases

[AI] (Jim) will add his write up on "permissions, authorizations versus groups" to the wiki.

[AI] (Andrew) will flesh out his outline on uPortal Groups and Permissions and put it on the wiki.

**Carry Over Action Items**

[AI] (Paul) will update the glossary to reflect feedback received.
[AI] (SteveO) will enable ITANA members to comment on the glossary in the wiki
[AI] (All) Post use cases to the wiki as time permits.

-- HELPFUL LINKS --

- MACE-paccman wiki:

https://spaces.internet2.edu/display/macepaccman/Home

- MACE-paccman Mailing List Archives

https://mail.internet2.edu/wws/arc/mace-paccman

**DISCUSSION**

*Glossary*

https://spaces.internet2.edu/display/macepaccman/MACE-paccman-glossary

Itana members now have write access to the glossary, but haven’t contributed to it yet. Paul plans to follow up with them.

TomB reported that the latest update to the glossary was to add “entity,” reflecting this term’s use in Kuali identity management.

*Use Cases*

Rob has classified use cases into generic categories, as summarized in the minutes of the 24-April-09 MACE-paccman call.

It would be helpful if group members would put on the wiki use cases they are familiar with and alert the group via email.

[AI] (U. Penn) and (CMU) will add use cases to the wiki.
https://spaces.internet2.edu/display/macepaccman/Use+Cases

*Discussion Topic: permissions and authorizations and groups*

Michael suggested that it could be helpful for the group to discuss the difference between permissions and authorizations and groups and when to use them. Discussion in that area could force us to think through use cases. Ben agreed that for Rutgers, this sort of discussion would be helpful.

[AI] (Jim) will add his write up on "permissions, authorizations versus groups" to the wiki.

*uPortal’s use of Groups and Permissions (Andrew) *

- About uPortal Groups:
uPortal has groups and permissions framework that’s a separate library.
Groups:
Can be users/people
Can portlets (widets one can use in portals)
Sources for Groups:
locally stored into database
pulled in from LDAP
from flat files on file system
just-in-time groups, based on rules about user attributes. (e.g. users in Class of 2009)
Other: an API allows developers to define other sources for groups (for example, there is an efficient way to get groups out of Active Directory in use at Johns Hopkins.)

The uPortal system optionally allows for groups to be read/write, by manipulation through a web UI. Sites can flag whether their web store chooses to support that feature. Most do not; most groups are read only.

- About uPortal Permissions

There is a permission system built on the group system. The permission system is a database of mappings that essentially state “these groups are permitted to perform a defined action on a defined object”
Mappings for the permission system are in a database table.
It would not be ideal to go directly to database table to look at what permissions someone has. But no one has written another realization of this API.
It is possible to delegate permissions over groups, i.e. to grant a group permission to give permission to some other group of users.
It is possible to allocate a permission to an individual instead of a group. But there are bugs and this doesn’t work in all cases.
Permissions can become complex -- it’s possible to grant permission of various kinds: permissions to add/delete/rename members/groups/subgroups, to change permissions, etc. There is the concept of permission to use a group and also to publish a portlet (make it available to groups).
The reality is that usually there are a few administrators who have full permissions to do anything and much of the complexity is not used.
Groups are sets to whom privileges are granted. Groups are exposed to JSR 168 portlets. There is a standard API for writing portlets for portals. It focuses on roles, not groups. uPortal supports this by mapping those roles requested by portlets to a group in the system.

*Issue with Enumeration of uPortal Groups*
One use of groups and permissions is as targets for just-in-time content: (e.g. “these are the groups of users who should see these tabs when they log in.”)
Example: notifications portlet, an add-on where you could compose method and choose groups to receive the notifications.
Issue: not all groups are amenable to this enumeration. There are groups that are just-in-time (result of applying a rule such as "class of 2009") . The system doesn’t know if someone is a member of the group until s/he logs in. So trying to send a message to this sort of group doesn’t work.
This gets more problematic with Shibboleth. With Shib, you can’t do arbitrary queries out of various directories. Need extension to map with appropriate queries.
uPortal needs better metadata about groups to reveal which ones can be enumerated and which can’t.

Q: Is it possible to query: “Is this user permitted to perform this action on this target?“

A: Yes, but there are no qualifiers on the arguments. You get only one target.

Q: Has uPortal’s groups/permissions been compared and contrasted with any other systems existing or emerging?

A: Dan Ellentuck was involved in comparing with early-stage Grouper and with Sakai.

*Access Management Camp in Philadelphia*

Everyone is encouraged to sign up for CAMP and Advanced CAMP in June:

CAMP: Practical Building Blocks for Access Management
http://net.educause.edu/camp092

Advanced CAMP: Identity Services Summit for Higher Ed Open/Community-Source Projects
http://net.educause.edu/camp093

*Next Meeting*

Next Meeting we will discuss permissions, authorizations and groups and their use at MIT and Penn.

**Important: New Day and Time**

- Thursday, 28-May-2009, at 1 p.m. ET