Use Case 1:  External Authentication and Authorization

Title (goal)
 External Authentication and Authorization
Primary Actor developer, consuming applications
Scope Organizational, black box
Level 
Story

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.

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

At this point, the front-end application decides what to do with the 403:  show an error page, mask with a 404, etc.

9 Comments

  1. David Wilcox

    As of 4.0-Alpha-4, this is ready to test.

  2. David Wilcox

    Scott Prater can you verify that this use case is satisfied?

  3. David Wilcox

    Scott Prater will you have time to verify that this use case has been satisfied over the next couple weeks? We need to get the use cases for the 4.0 beta through acceptance testing as soon as possible. Thanks!

  4. Scott Prater

    David Wilcox:  This use case is fairly complex, as it requires a certain amount of infrastructure already in place to test it end-to-end.  A short term test would be to test an anonympous request vs. a request with some principal attributes attached.  Would that be enough?

    1. Andrew Woods

      Scott Prater, in the absence of setting up the whole system as you described in the use case, it seems that yes, it would be valuable to perform the requests specified against F4 directly to see if you get the expected responses:

      • anonymous request for public object/datastream -> 200
      • anonymous request for protected object/datastream -> 401
      • authenticated and authorized request -> 200
      • authenticated and unauthorized request -> 403

      Additionally, if you have specific needs around "policy may be evaluated based on a properties of the object", it would be good to detail your thoughts.

      And, yes, the source I.P. of the request is available to the authorization machinery (although there is no current PDP that references that information).

       

  5. Scott Prater

    OK, I can do this.  I won't be able to work on it until sometime towards the end of next week, though.

    1. Andrew Woods

      Thanks, Scott Prater.

    2. David Wilcox

      Hi Scott Prater - have you made any progress with validating this use case?

    3. David Wilcox

      Hi Scott Prater - will you have a chance to review this use case soon?

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.