| Table of Contents |
|---|
...
| Include Page | ||
|---|---|---|
| ||
| Anchor | ExternalAuthNZ | ExternalAuthNZ |
...
|
...
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.
- Resource is available: PDP responds with "yes". Fedora sends back the requested resource, with a HTTP 200 response code. Work is done.
- 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.
- 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.
- 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.
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||
|---|---|---|
|
Use Case 2: Resource Index/Triplestore queries
...
Title (goal) | Obtain filtered list of objects |
|---|---|
| Primary Actor | administrator, consuming applications |
| Scope | component |
| Level | |
| Story | An administrator or piece of software needs to get a list of all the top-level objects in a particular collection, or created under the auspices of a given project. They run the following ITQL query against the Resource Index: select $fco from <#ri> where the project ID is "AfricaFocus". Alternatively: select $fco from <#ri> where the collection ID is "CollectionHLATextile". As a variation, the actor may just retrieve count of objects that match the criteria. |
...
...
|
...
|
...
|
...