tomcrane

Auth Notes

I appreciate that these aren't technically use cases, the use cases I had were too cluttered by the process of acquiring a cookie rather than the metadata's appearance in response to that cookie. We haven't had to solve the problem of describing in metadata HOW a consumer might acquire the authentication token our service layer is looking for, our viewer just knows - which obviously doesn't lend itself to interoperability. Nevertheless I hope these are useful in describing what Wellcome does in the rest of the authentication and authorisation scenarios.

These are the assumptions and use cases that underpin the Wellcome Library's authentication and authorisation requirements.

For clarity, I'll use terms similar to IIIF concepts (e.g., manifest) even though the Wellcome Library doesn't yet use IIIF. Also it's worth pointing out that if IIIF Auth turns out not to be implemented this way, it doesn't mean we can't adapt to it!

Assumption: The manifest doesn't contain any secrets -

tomcrane

Ref: https://github.com/IIIF/iiif.io/blob/master/source/event/2014/london_auth_scenarios.md

Ref: https://github.com/IIIF/iiif.io/blob/master/source/event/2014/london-auth-workflow.png

Reiterate assumptions from london_auth_scenarios:

Assumption 1: In both the Image API and the Presentation API, a given URI for an Image Information request, an Image request, or a Manifest request will result in the same bytestream if access is granted, irrespective of credentials and user identity.

(Is this compatible with london-auth-workflow.png? Think so because of the 301)

tomcrane

This post follows on from https://groups.google.com/forum/#!topic/iiif-discuss/mcs4T1KMyN4 and https://groups.google.com/d/msg/iiif-discuss/IIuduLgkRA0/X7xTZcUTmUAJ.

In the last IIIF call (2014-11-26) it was suggested that the auth information was better provided by a service - which can also be on any node - rather than an annotationList. So here are some further questions around that.

Is it OK for a service to return annotations too? It feels as if an annotation is a good mechanism to apply overriding auth information to a particular part of the structure, but via a service on a node rather than an annoList on a node.

Whether it is service or annolist, is it acceptable for a single profile supplied in an annotation to override ALL profiles "underneath" the target (i.e., descendant nodes in the JSON-LD)? It seems economical and reasonably easy to understand, but something about it doesn't feel right:

The "profile" term is dcterms:conformsTo. Here's my earlier example of an annotation providing an overri

tomcrane

Thoughts on thumbnails

Rendering thumbnails might be the activity that puts most stress on servers if not given some care both on server and in viewer.

We have to remember that IIIF consumers are under no obligation to do what you want them to do. It’s not necessarily your viewer looking at the endpoints. While you can arrange a careful honourable agreement between client and server if it’s your viewer looking at your server, other viewers won’t know the rules – or may choose not to play by them.

An uncaring viewer app takes no notice of any hints, recommended sizes or explicit thumbnails declared in the manifest and goes straight to the first image service it finds for a canvas and requests an image in the size it thinks appropriate for a thumbnail. It doesn’t know whether this is an optimum size for the server to produce, or whether the server has this cached.

This is what the our Viewer is doing currently. If generated images are cached then over time the performance of thumbnails for an already

tomcrane

This is based on the implementation described in IIIF Search Straw Person: https://docs.google.com/document/d/1F9-zelMCJqVjh-UMk8VeaPULBY2yRbI17X5EsrtcmSY

...and on the comments on this thread: https://groups.google.com/d/msg/iiif-discuss/cecb6B_21kk/3GIwpBWPMAsJ

The Wellcome Library already has search within, based on OCR data persisted in ALTO files. The implementation can be seen on any searchable book or archive: http://wellcomelibrary.org/player/b18035978

There are two services involved:

tomcrane

These notes are specifically from the point of view of the Wellcome Library's current auth requirements, to see how the current proposed IIIF services fit.

The Wellcome Library does not support degraded access on the image service. You're either authorised or you're not. For certain otherwise protected content, it allows a thumbnail to be served to anonymous users - but will provide that as the "thumbnail" property of the canvas, not as a size degredation on the image service. This "thumbnail" property might be a URI, ot it might be an image service - see other gist. This means that viewers should use the "thumbnail" to get thumbnails.

The Image API spec adds a login service to the info.json:

{
  "service" : {
 "@id": "http://authentication.example.org/login",

tomcrane

@prefix wdrs: <http://www.w3.org/2007/05/powder-s#>.

<http://wellcomelibrary.org/resource/b18180279> wdrs:describedBy <http://wellcomelibrary.org/iiif/b19708440/manifest>
<http://wellcomelibrary.org/iiif/b19708440/manifest> a <http://iiif.io/api/presentation/2#manifest>.

tomcrane

We want to move the Wellcome Library away from the Wellcome Player and onto the IIIF 2.0 Universal Viewer (UV).

This allows us to move all the Wellcome Library's image API endpoints to the protoype DLCS (Digital Library Cloud Services) that we have started building.

We have a problem. We have video, audio and born-digital content, besides image sequence content. We don't want to maintain the Player and the UV together. This non-image content is a tiny fraction of the total, but an important one.

Other institutions share this problem, and everyone agrees that IIIF will need to extend to handle non-image-sequence resources - "IxIF". We want to inherit all that we can from IIIF - the JSON-LD, the Open Annotation model, the manifest wrapper and general approach to metadata ("presentation not semantics"). Shared Canvas may be appropriate for some media but not others.

• Images are canvas-based media - they occupy a region of a plane. Annotations are on regions of the plane.
• Audio is a time-based medium - i

tomcrane

var decoded = Convert.FromBase64String(samlRequest);
var zlibPadding = new [] { decoded[0], decoded[1] };
var deflated = CompressionUtils.Deflate(decoded.Skip(2).ToArray());
Log.Info("decoded SAMLRequest:");
Log.Info(deflated);
var sessionIndex = CasAuthentication.ExtractSingleSignOutTicketFromSamlResponse(deflated);
Log.Info("Extracted sessionIndex: " + sessionIndex);

LibraryAuthentication.SignOut();

tomcrane

Protecting binaries - extending the auth flow beyond JSON-LD resources

This applies to image resources (as opposed to pixels returned from an IIIF image service). It also applies to audio, video, PDFs and any other resource for direct consumption by the end user that isn't a service with an info.json descriptor.

Problem:

The expected client implementation of http://iiif.io/api/auth/0.9/#workflow-from-the-client-perspective uses XHR to request the info.json. The response body is always the same regardless of the user's access (we don't protect the information carried in the info.json) but the HTTP status code differs. A client can detect the presence of a IIIF auth service in the info.json, allow the user to log in at the URI provided, obtain an access token from the token service provided, and then crucially present that access token to the info.json service in a second request (using an Authorization HTTP header) to determine whether