Versions Compared

Old Version 2

changes.mady.by.user Scott Prater

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Woods

Saved on

Key

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

Table of Contents

Include Page
University of Wisconsin - Madison - External

...

Title (goal)

...

Authentication and Authorization

...

1.  User on a browser clicks on a link to see information about a digital object in Fedora.  The request will pass through a few layers of front-end applications before it reaches Fedora.

    • No user information is submitted with the request;  it's an anonymous request from an unauthenticated user.

2.  Fedora receives the anonymous request for the resource (object, datastream, datastream metadata, etc.).  It asks the external PDP if this resource is accessible;  no role attributes are delivered to the PDP (an anonymous, public request).

    • Is the source IP for the request is passed along, for access control?
    • PDP needs access to the object;  policy may be evaluated based on a properties of the object.
    1. Resource is available:  PDP responds with "yes".  Fedora sends back the requested resource, with a HTTP 200 response code.  Work is done.
    2. Resource has restricted access.  PDP responds with "no".  Fedora sends back a HTTP 401:  Unauthorized.

University of Wisconsin - Madison - External Authentication and Authorization

Include Page
University of Wisconsin - Madison - Obtain filtered list of objects
University of Wisconsin - Madison - Obtain filtered list of objects

Include Page
University of Wisconsin - Madison - Obtain list of objects that contain a given datastream
University of Wisconsin - Madison - Obtain list of objects that contain a given datastream

Other Use Cases of Interest

  1. University of North Carolina at Chapel Hill
  2. Yale University
  3. Use Case: Distributed authentication and authorization

At this point, the front-end application decides what to do with that 401:  in our case, it will redirect the user to an authenticating web service, protected by Shibboleth;  the authentication web service will do the Shibboleth dance, then redirect the user back to the front end web application, with user attributes included.

3.  The front-end web web application will re-request the resource from Fedora, this time with user attribute information.

4.  Fedora receives the authenticated request for the resource.  It asks the PDP again if the resource is accessible, this time passing along user attributes.

    1. Resource is available to the user:  PDP responds with "yes". Fedora sends back the requested resource, with a HTTP 200 response code.  Work is done.
    2. Resource is not available to the user:  PDP responds with "no".  Fedora sends back a HTTP 403:  Forbidden (final, request should not be re-submitted).

...