...
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
...
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:
...
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.
...
===================================
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 - discussionHow 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