We (J Paul Getty Trust) require authentication for some of our images, notably images that have only been cleared for internal use on the way towards being made public. Also for images that are cleared for use at certain sizes publicly, but known researchers can have greater access, and onsite staff even greater. We have a deadline of September for a production quality implementation, as it is necessary for a university course we are collaborating on.
In order to keep the solution flexible, our analysis so far has led to having a sidecar file that lives with the source image that describes the extra properties to include in the info.json, the roles authorized to access the image, and generation rules to create derivative masters for different tiers of access.
We have an implementation of an authorizer module that follows the pattern of resolver, plus some minor tweaks to the workflow in webapp. The actual authentication services (access token, access cookie, authentication process) are completely external to loris, but we'll provide a reference implementation for comparison with Tom Crane's https://github.com/digirati-co-uk/iiif-auth-server code.
Feedback on the json structure below would be appreciated to ensure that the implementation effort also covers others' use cases.
The json file would live at a configurable path relative to the image, generated by replacing the file extension with the configured name. To ensure that it could be re-associated, the source image identifier is also in the JSON. Each key,value in extraInfo would be copied into the info.json verbatim. The tiers property is an ordered list of degraded images from least accessible to most accessible. The generation property includes rules to regenerate the degraded master, if the cached degraded master is purged. The intent is that this would be done outside of Loris as waiting while the master is decoded completely, then transformed with pillow, then re-encoded, then decoded to generate the tiles or other derivatives would be unusably slow.
{
"source": "identifier.jp2",
"allowed": ["roles", "allowed", "for", "full"],
"extraInfo": {
"attribution": "Text to put in attribution field",
"logo": "URI/dict to put in logo field",
"licence": "URI to put in licence field",
"service": {"id": "uri(s) to additional service(s)"}
},
"tiers": [
{
"identifier": "identifier-degraded or http://.../identifier-degraded",
"allowed": ["roles", "allowed", "for", "degraded"],
"extraInfo": {
"attribution": "Text to put in attribution field",
"logo": "URI/dict to put in logo field",
"licence": "URI to put in licence field",
"service": {"id": "uri(s) to additional service(s)"},
},
"generation": {
"output": "/path/to/identifier-degraded.jp2",
"size": 1000,
"quality": "gray",
"recipe": "/path/to/kakadu/recipe.txt"
}
}
]
}
bcail
commented
7 years ago
We (J Paul Getty Trust) require authentication for some of our images, notably images that have only been cleared for internal use on the way towards being made public. Also for images that are cleared for use at certain sizes publicly, but known researchers can have greater access, and onsite staff even greater. We have a deadline of September for a production quality implementation, as it is necessary for a university course we are collaborating on.
In order to keep the solution flexible, our analysis so far has led to having a sidecar file that lives with the source image that describes the extra properties to include in the info.json, the roles authorized to access the image, and generation rules to create derivative masters for different tiers of access.
We have an implementation of an authorizer module that follows the pattern of resolver, plus some minor tweaks to the workflow in webapp. The actual authentication services (access token, access cookie, authentication process) are completely external to loris, but we'll provide a reference implementation for comparison with Tom Crane's https://github.com/digirati-co-uk/iiif-auth-server code.
Feedback on the json structure below would be appreciated to ensure that the implementation effort also covers others' use cases.
The json file would live at a configurable path relative to the image, generated by replacing the file extension with the configured name. To ensure that it could be re-associated, the source image identifier is also in the JSON. Each key,value in
extraInfowould be copied into the info.json verbatim. Thetiersproperty is an ordered list of degraded images from least accessible to most accessible. Thegenerationproperty includes rules to regenerate the degraded master, if the cached degraded master is purged. The intent is that this would be done outside of Loris as waiting while the master is decoded completely, then transformed with pillow, then re-encoded, then decoded to generate the tiles or other derivatives would be unusably slow.