Scribing Template --Wed., Nov 13, 2013 at 9am -- Marina del Ray
TOPIC: Permissions Management
CONVENER: Steven Carmody
SCRIBE: Keith Hazelton
# of ATTENDEES: 24
MAIN ISSUES DISCUSSED:
This session will just begin the problem definition work and identification of some models. This will definitely continue, we'll need to pick a forum The results will be useful in part as input to the CIFER project
There are a fair number of cloud vendors who dump the permissions enforcement problem on the institution (a mode that conflates authN/Z); AuthN, Front-door coarse-grained AuthZ, fine-grained authZ. All these categories need to be addressed. The service SHOULD receive a coarse-grained entitlement. IdP-side AuthZ.
Do we feel that the IdP should be doing authorization itself? Traditionally IdP does AuthN and attributes. it doesn't get finer than entitlements. There's no dogma, it depends.
Many of us are solving this with Grouper.
The problem: what are the requirements for managing permissions when sometimes 1) they're handled at IdP, 2) sometimes passed to the SP as an attribute and 3) sometimes done by provisioning to the end system. What kind of capabilities are needed by various parties (service owners, auditors, users,etc.). There's a lot you can do with these three models, but you need to have the talent on hand to implement them.
MACE-Paccman discussed these various models and how they work, but didn't drive it to prescriptive statements. See https://spaces.at.internet2.edu/display/macepaccman/Federated+Authorization+Problems+and+Models/Federated+Authorization+Problems+and+Models
As we create Grouper groups that are service oriented we do include/exclude groups. Always at least three groups. But when the auditors come years later, how do you encode that that group was in charge of authZ for that service: naming conventions such as apps:box tell us this kind of things; UW-Madison sponsors of groups request services, service owners then allow/deny that group
With a little help we could resurrect the models and then collect institutional case studies that have implemented these models.
The central IT folks can't say no to a problem, but they can enable service owners to effectively say yes/no to requests for services
Fine grained permissions bring a fourth category: If you have a place to act as a policy decision point, then you evaluate the authorization question and pass the answer to the app/policy enforcement point. Our problem at Duke: who has access to what identity data about other persons. Started thinking about how to represent those rules or access control statements. Then provide management intefaces. The first two pieces are solved by Grouper permissions and inheritance trees. We have a tentative model. Then we will build a web service that allow apps to talk to essentially a PDP. LDAP acis, even sophisticated ones, don't work for all consumers.
Next steps: What are the models, how can we transition to experiments with implementations of the models.
The need for abstraction and a new access layer (PDP-like) in order to effectively deal with this set of finer-grained access problems
ERPs have very sophisticated roles and rules about data access. When we externalize that data we need to replicate the rules in some way so the policy is still in effect.
We have a foothold in PS now. Links to self-service. Their internal def of a student was different than our external def, now we're driving our definition back into their system. We use our data warehouse. Pulls data out of PS, calculates what a student is, pushes into person registry, pushed back into PS.
Grouper permissions functionality being used to control access. Penn uses permissions in new person atttribute database schema, Oracle fine-grained access to control sub-views. permissions of what columns/rows you can see are managed in Grouper, changes driven to Oracle fine-grained view via XMPP messages. Access to cluster of access servers: which groups can start/stop apps, read logs, etc.
MIT had RolesDB dealing with permissions centrally, used to manage col/row access permissions.
ACTIVITIES GOING FORWARD / NEXT STEPS:
Duke will schedule webinar on their approach to data access management. Keep the discussion going.
Continue the discussion on the cifer-prov list: subscribe here. A federated wiki space that could be used for ongoing conversation is available at https://spaces.at.internet2.edu/display/cifer/Provisioning+and+Integration+Team
If slides are used in the session, please ask presenters to convert their slides to PDF and email them to acamp-info@incommon.orgNe