Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • ACTIONS: Read, Create, Edit, Delete, and "Change Permissions"
    • One vocabulary covers all equivalent methods in SOAP and REST APIs (ie. policies decide at a higher level who can edit a datastream, rather than saying who can call the modifyDatastream SOAP method).
  • TARGETS: Collections, Objects, and Datastreams
  • SUBJECTS: User & Group
    • Assign permissions by User or by Group, regardless of where user attributes are coming from (ie. LDAP, Shibboleth, OpenId, CAS, etc.).

A general design principle of the FSL approach is that an object ideally belongs to one collection for authorization purposes, providing a simpler approach to policy interpretation. However, sample policy templates will be provided which show more complex examples with multiple parents for one object. FSL will look at an approach that allows an object to be assigned to a policy object in the policy repository using a special authorization predicate.

Authentication (AuthN)

  • Wiki MarkupSupport _surrogate authentication_ and document how to do it \[This needs clarification.\]Provide documentation on how a GUI can allow a user to authenticate and pass the credentials to the Fedora server.
  • Support LDAP, AD and Tomcat-Users by refactoring the existing servlet filters to make them more user friendlyunmigrated-wiki-markup.
  • Implement authentication in a modular way so that participating organizations can write their own adapters way (ie. via Jaas) so that participating organizations can write their own adapters (ie. Drupal, OpenID, etc.) \[This needs some additional information from Paul.\]

Policy Manager / Authorization (AuthZ)

...