MACE-paccman call 17-June-2010
*Attending*
Tom Dopirak, CMU (chair)
Rob Carter, Duke
Chris Hyzer, U. Penn
Keith Hazelton, U. Wisconsin
Benn Oshrin, Internet2
Mark Scheible NC State
Renee Frost, Internet2
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)
*New Action Items*
[AI] (Keith) will check with Brendan on MACE-Dir and potential MACE-paccman involvement with Oracle issues.
*Carry Over Action Items*
[AI] (Rob) will attach numbers/identifiers to MACE-paccman use cases in preparation for promoting them (or pointers to them) from the wiki to the website.
https://spaces.internet2.edu/display/macepaccman/Use+Cases
[AI] (Stephen L) will share caBIG use cases on federated access management on the MACE-paccman wiki. (Rob) will help in this process.
[AI] (MichaelP) will work to polish the glossary, as a next step, until events warrant revisiting it.
[AI] (R.L. Bob) will separate “assurance” from “authentication” in the glossary.
[AI] (Rob) and (Paul) will look at Rob’s use cases and mapping to XACML. (this is on hold until CAMP in June)
**Discussion**
*MACE-paccman Meeting Schedule*
The MACE-paccman meeting schedule has been revised to avoid conflicts with IAM Online. The meeting dates are available at :
https://spaces.internet2.edu/display/macepaccman/Home
*XACML and Access Management*
Keith has been investigating how XACML expressions can be used for access management policy point expressions.
Useful links include:
- Official OASIS link to xacml AZcontribution from Hal Lockhart of Oracle
http://www.oasis-open.org/committees/document.php?document_id=33416
- HerasAF (uses XACML)
http://www.herasaf.org/
- Argus (uses XACML)
https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework
Keith intends to continue looking into issues of XACML and access management.
*Oracle/Sun Issues*
Keith had an action item to work on reactivating the Oracle Buddy List. However, the Campus EAI consortium now has an active group -- called the Oracle/Sun IDM Roundtable -- that makes this action item less relevant. Interested individuals should email Jasmine Kaur at jasmine_kaur@CAMPUSEAI.ORG
It was noted that the MACE-Dir working group had discussed some involvement with the CAMPUS EAI Oracle/Sun IDM Roundtable effort, possibly relating to Sun Directory issues.
[AI] (Keith) will check with Brendan on MACE-Dir and potential MACE-paccman involvement with Oracle issues.
*PeopleSoft Permissions*
There were challenges at NC State on restricting the PeopleSoft permissions granted to a particular role to a certain instance (i.e. department) of that role. Keith discussed that issue with PeopleSoft experts at U-Wisconsin. They suggested that the best way to restrict PeopleSoft permissions is using row level (fields and rows) security. This can involve mapping a role to a set of permissions lists.
TomD noted that this seems to reflect a database point of view instead of a schematic point of view. CMU is trying to get away from the notion of the screen. This is easier when developing software than when purchasing systems from PeopleSoft and Oracle.
*Permissions API Model*
Chris has proposed a model for an permissions API. This model is based on the Grouper API, but it is made more generic in a few places.
https://spaces.internet2.edu/display/macepaccman/Permissions+API+suggestion+based+on+Grouper+permissions
In this model the primary objects are:
subjects (and subject lookup)
roles (and role lookup)
permissions resources (and permission resource lookup)
application (and application lookup)
permission assignment returned from the permissions server. This is the assignment of a permission resource to a subject in the context of an action, and can have attributes associated with it.
Chris discussed each of these objects. Important points:
- Each subject must have an ID and a source (namespace), and can have description. Can have multi-valued attributes, including permissions. An example of an attribute on a subject could be netID, sometimes needed by authorization/ authentication systems.
- Roles have a namespace. Roles can also have a name and a displayName, description and other attributes. Roles can have a folder, which an end user has control of.
- Permission resource is what gets assigned in the permission assignment. Can have a namespace, folder, displayName.
- Application is similar to Permission Resource. This idea was copied from the perMIT system. (Grouper uses a more random access approach)
- Permission assignment ties everything together
- Attributes should be used when there are multiple constraints (conditions) on permission.
Concerning the API, there should be:
web service for request/response and
a real time message format (XMPP)
Keith noted that the model Chris has proposed is useful and will help in exploring the possible use of XACML for
implementation.
A question was raised of where are the attributes values are typically specified: at the policy point or at the evaluation/enforcement point?
It was noted that there can be issues of attribute staleness if attributes must be fetched. Can attributes get cached, and if so is there a mechanism to see if the values are current enough? There is a notion of a market (federation) where people make attributes available and trust issues are involved. There can be a lot of metadata around that. The amount of data made available in response to a request can potentially be dependent on how the requestor is authenticating.
*Grouper News*
Grouper v 1.6 will be released within the next week or so.
Next Call: Thursday, 1-July-2010, 1:00pm ET