...
Mike Gettes drew a diagram which the group discussed and the finished image was:
Mike Olive and Scotty Logan said that they could contribute the documentation sets they use for workgroup and authority. They use workflow to route work items to appropriate people for their part of a task, making it an integral part of the authorization system.
MIT: Scott Thorne will provide a document describing how MIT designs systems, and why they are designed that way. (Mike re-phrased as: Nearing analysis paralysis on systems architecture and development.)
Paul Hill and Jim Repa will provide a summary of what happened with a recent integration of an application, specifically to show how the triple (person & function & qualifier) modeling breakdown of a recent implementation developed.
Discussion:
Data Out: how to represent permissions
i.e. foo:bar:permission1:p2:p3:...
ex. listmgmnt:listname:function
Do all three of these permission categories / systems / uses require seeing the same structure?
The data changes with the use.
Perms Mapping Authz
Authz System
App checking Authz
(eval vs reference)
APP This That
Permit:foo:function:qualifier
>> Application foo can only see foo:x
C S F Q : Limits
C = Category
S = subject (person, system, application)
F = Function
Q = Qualifier
Limits can be anything, as: Time, date, money, etc.
What we covet / admire / wish for:
- LDAP & APIs
- Reflecting Apps roles back into Central Management
- Stanford's decoupling of roles & systems (layering)
- Automated de-provisioning of permissions
- Signet's subject API
- Reducing the # of PMS
o Build bridges between
- Good governance policy
What do we question?
- the MIT triple in terms of comprehensiveness, and of comprehension by Customers
- can we map out an institutional system of roles?
PSU presented a short discussion on work done by a consultant for them on a Content Management System that has identified five 'branches' or 'categories' of entities:
Curriculum
Roles
Individuals
Buildings
Org Units
Mike G. noted that this appears to be more of a Library Science view than a Computer Science analysis / representation, in that the categories are specific, not abstracted, the organization appears to be list oriented, and there are no indicators for the relationships between the entities.
Mike G. raised the question for all to consider: Does any of this conflict with Internet 2, Educause, MACE (Middleware Architecture Committee for Education), etc.?
- People could not see any at the time.
We need to agree on the data interfaces:
- OSID
- REST
- WSDL
with the goal of providing a common language that we can all understand, and take the same meaning from.
============================
from atttendee #3
Items of discussion:
1. permissions to the rest of the app world
2. data out - xacml
PSU (Renee) provide touchpoints of policy and SDLC & IdLM applied to PMS (2-3 mths)
UW (Ian) Q&A of what they currently do for PMS & developer engagements
SU (MO) published docs for PMS and groups
MIT (Scott) Analysis Paralysis on systems architecture and development
MIT (Scott) capture systems breakdown into triple model of late
Seems to be consensus around entitlement LDAP attribute structure of Categorty:Subject:Function:Qualifier
RESTful interface
OSID
3. IDE/UI
4. Layering as UI
5. Data classification
6. Business Intelligence
7. Risk Mgmt/App Mgmt
8. OSID / Interfaces
=========================
From attendee #4
Scotty Logan goal for meeting: a common way to represent permissions in a directory
MIT
-seems like the authorization is in the database...
MIT's Roles Database: Parts of an Authorization
web.mit.edu/repa/www/roles_auth_parts.html
Action Items
PSU - touch points of policy and SDLL & IdLM applied to Privilege Management System
UW - share Q&A of what they currently do for PMS & develop discussion
Stanford - does for developers on how to use Auth
MIT - Nearing anlaysis/paralysis on system architecture and development
-Capture systems breakdown into triple model (subject/function/thing)
DATA OUT
Ways in which data can be represented
foo:bar:permission1:p2:p3
list management:list name: function
person managing auth
managing authz system
application checking authz
evaluation vs. reference
category:subject:function:qualifier
date range contained in the directory -
unnecessary, if it is in the directory it is valid
Covet
-the LDAP APIS
-Stanfords developing of roles and systems layering
-automated de-provisioning
-app driven vs. org driven
-subject api
Additional Goals/Action Items:
common interface to the systems: OSID, WSDL, REST
common format for what a role looks like
common format for static representation in LDAP
===================================
Attendee #5
http://itarch.stanford.edu/blog/archives/2008/general/permissions-management-meeting-mit
http://itarch.stanford.edu/blog/archives/2008/general/permissions-management-meeting-mit-discussion