From attendee #1:
PSU
LDAP is the data store as objects
100 or so role admins giving assignments
1000 or so people with assignments
10000s of assignments
no auto expiration or other limitations
not linked to IdM lifecycle
financially focused - need to do academic, research, hr
MIT
Delegation
Washington
Delegation
authorization poaching
directory specs?
federated users?
3-tier?
stanford
delegation
proxy
"acting approver"
IDE for creating priv systems
signet
-------------------
From attendee #2
There were presentations from Washington State, Penn State, Stanford, and MIT, outlining their current permission system work, and the major components of their architecture.
Take Aways:
- Permissions to the rest of the Application world
- Data out? XACML
- IDE?
- UI?
- Layering as UI?
- As a group, with greater interest / relevance for Developers:
o Data Classification
o BI
o Risk Mgmnt system integration
- Central Mgmnt / Application Mgmnt
- OSID
Issue: Often, Developers aren't interested in Security aspects of the functions they develop, or of the environment they develop for, until they HAVE to consider them in order to move out of development into testing / QA.
- How can we get them interested and invested in Security so that it's a primary development aspect rather than being viewed as a minor aspect that needs to be added on.
o Management emphasis on Security and Security architecture as a major development concept
§ Security Policy
§ Integration with Enterprise risk assessment & management (HIPAA, ID theft, etc., Customer/Client satisfaction & retention)
o Development standards / policy
o Testing policy / process
o Promotion policy / requirements
Question: Are people here willing to share what they're doing in this area?
PSU: Renee Shuey is working PSU's Risk Management Team to review and update their policy. As it is defined, she will share the results with the group. i.e. She will identify the touch points of the policy and the SDLC / IdLM as applied to PMS. (IdLM = Idnetity Life cycle Management)
University of Washington - Ian Taylor will share the Questions and Answers of what they currently do for PMS and Developer discussions.
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
=======================
Attendee #6
Scotty seeking agreement - How permissions are represented in a directory.
Astra - 1999 (They picked up some early code from MIT circa 1996/97
Astra moving to supporting not only Person, but also other more generic subjects (keytab, cert, application,...)
Astra's approach is more like our implied authorizations.
Does a small number of "roles" which imply a broad level of privileges raise authorization management into a much more political domain. Perhaps needing a long term standing committee?
Applications consume data from Astra in real time.
Developers doing authorization poaching. E.g. a project has created roles for one system and they now create a new system and use the existing roles. But the authorizer may not have anticipated this and they might not approve this if asked.
There are authorizations that are reflected into Astra, but are not managed with Atra.
MIT Problems:
Desire a data dictionary showing security level of every data element
How do I make an authorization request?
How do I find out who can grant me an authorization?
Reflect auths into enterprise directory
Authorizations for more than just users (email, kerberos principal, certificate, ...)
Who granted my authorization?
Stanford Authority System - 6 years ago
Bulk loading of privileges - operational requirement, but no programmatic way of inputting data?
What are some of the axis of convergence or divergence between these systems?
In other words, what are some of the common characteristics, or important characteristics?
○ Using enterprise data sources to populate authorizations
○ Exposing the authorizations via LDAP groups
○ Is authorization management pushed to the edge or is it very centralized?
○ How complex is the data model?
○ Does this system reflect (publish) authorizations that are managed elsewhere, or must the authorizations be managed within the central system?
Common problem: the difficulty in visualization of the collision of privileges, list, and access.
What about the inverse problem? I am a user and I've been told do go perform a job, what authorizations do I need, and who do I need to contact in order to be granted these authorizations?
Michael would like a "what if?" tool. I'm going to add Bob to group A what authorizations will this affect and what systems will consume this?
IDE discussion - how do people model authorizations to lessen the need for personal consulting for each project that needs to use authorization management?
Action Items for Paul and Jim:
Take:
- Libraries EZ proxy
- SDLS
- Touchstone
Write up the problem statement faced by each project in a couple of paragraphs.
Write up the functions and qualifiers created to solve the problem.
Describe the qualifier hierarchy
What do we covet / admire / or wish for:
- Expose authorizations via LDAP and well defined APIs
- Be able to reflect existing applications "roles" centrally
- Stanford's decoupling of roles & systems (layering)
- Automated de-provisioning
- Application driven versus Organization driven
- Signet's Subject API
- Reducing # of PMS
- Build bridges between
- Good Governance and Policy
What don't we believe, what we would shed?
Renee doesn't believe that the triple is easy to understand.
Is it possible to map out the roles for the entire institution? Question for Penn State. They have their Mudder-of-all-Roles and Elvis-the-king-of-roles. - Top down approach which was a result of financial workflow. That has been deployed. Still trying to determine Academic roles - they are still trying to determine what the roles are, who owns them, and who can approve them.
Scotty - likes REST
Get a URL:
200 - yes you can
400 - no you can't
Should we create a REST interface for authorizations? (A translation of the OSID work?)
LDAP representation put an attribute on a user's object:
Permit:<category>:<function>:<qualifier>
If we could agree on:
- Common OSID
- Common REST
- Common WSDL
- Common LDAP
- Common format for what a rule looks like