Page History

...

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^{Image Removed}http://itarch.stanford.edu/blog/archives/2008/general/permissions-management-meeting-mit-discussion^{Image Removed}

=======================
Attendee #6

...

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.

...

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