...
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