IIIF Authentication and SIPI (and Knora)

#1

In order to use SIPI with the IIIF Authentication API, there are several points to be aware of:

  1. The IIIF Authentification API relies on a complex interaction between the client and the server. There are possibly multiple DNS domains involved:

    • user domain: the domain the user is attached to the internet, e.g. me.berkely.edu
    • viewer domain: the domain the viewer is loaded from, e.g. universalviewer.io
    • the domain providing the manifest file, e.g. collection.org
    • the domain of the content provider, e.g.ub.unibas.ch

  2. In order to access a pixel resource, the IIIF-viewer first requires the corresponding info.json from the IIIF-Server (content provider domain):

    • if the content is free available, the info.json is returned with HTTP status 200 OK. In this case the viewer requests the pixel content. THE END
    • if the content is protected, the info.jsonis returned with HTTP status 401 Not Authorized

  3. If the viewer gets a status of 401 Not Authorized back, the info.json contains (should contain) the information where to get the necessary resources to access the pixel conent. It needs both information about

    • a cookie service
    • an access token service

  4. SIPI in the current version has a fixed info.json that has to be made configurable for cookie and token services. This is not a major work, but needs some programming in C++… The configuration will be project specific (prefix dependent) within the generic SIPI configuration file.

  5. First the viewer opens a iframe to access the cookie service. This may present just a button I accept or may present a login window. After the user action (pressing the button in the simple “clickthrough” case; making a login using the credentials from the user – eventually going over shibboleth), this service returns a cookie. This cookie will be used to access the pixel content.
    Attention: This server must be in the same domain as the content server (that is SIPI)! Otherwise the cookie will not work!!

  6. In the next step the viewer uses the cookie to access the token service. This service returns a baerer-token that will be used to access the text content, especially info.json. This is necessary because XHR-Requests (that are used to access info.json) do not allow cookies. For accessing info.json, the baerer token must be supplied.

  7. Now the viewer again requests the info.json using the access baerer token – which this time should be returned with a HTTP status 200 OK.

  8. Now the pixel content can be requested. The browser automatically adds the access cookie. The pixel content server sends the image data. THE END

For the use of SIPI within the UB this has the following consequences:

  1. SIPI must support the service info within info.json. This has to be programmed, but is not a big issue -> Lukas

  2. In the same domain where the SIPI server runs (e.g. *.ub.unibas.ch) we have to setup a webserver which acts as a cookie and token service (auth-server). The cookie-service will at the end use shibboleth to authentificate the user. These services may be rather small PHP, python or similar programs running within apache (or nginx).
    -> Manuel, Lukas, Ivan, UB-staff

  3. The SIPI pre-flight-script (in Lua) has to check the access cookie (in case of pixel data requests) or baerer-token (in case of info.json-requests). In order to do so, the auth-server and the SIPI-server must have a shared secret.
    -> Manuel, Lukas

With this procedure, a fully IIIF compliant, secure authentification can be implemented which will run seamlessly with all IIIF-compliant viewers as Universalviewer, Mirador, leaflet etc. There is no need to install a proxy as long as the auth-server and the SIPI-server are in the same domain (e.g. “ub.unibas.ch”). A proxy may be used however if there are other reasons for it (e.g. SSL with only one certificate – a hint from Ivan :wink: