Documentation: Add Amherst's image extension service to Vagrant

[jonathangreen]

This is part of this ticket:
https://github.com/Islandora-CLAW/CLAW/issues/572

And probably relates to this ticket:
https://github.com/Islandora-CLAW/CLAW/issues/573

In adding the Amherst image extension service to our vagrant install, I tripped over a bit of a problem. Because we are using Syn to do authentication against Fedora, the image extension service isn't able to retrieve resources from Fedora anymore.

This could be solved in a number of ways:

1. Have APIX services pass on authorization headers that they receive
2. Have some sort of default username and password for services

I think that I'm leaning towards 1, that way the operations on objects take place as the user that requested them. For instance if someone were to ingest an image into fedora, then derivatives were created through this service, the requests would take place as the user that requested it since the authentication headers would just be passed along with each request.

Interested in everyones input what we should do here.
@acoburn @Islandora-CLAW/committers

Where the request is getting made here:
https://gitlab.amherst.edu/acdc/repository-extension-services/blob/master/acrepo-exts-image/src/main/java/edu/amherst/acdc/exts/image/ImageRouter.java#L110

[DiegoPino]

@jonathangreen could syn have some sort of IP based allowance or white-listing? Managing authorization headers can become tricky if we depend on APIX for that.
Fedora already has a way of defering/refering "on behalf of" actions. It's the base of their Authz/ AuthN model, separating authentication of authorization, roles and users and making use of WebACL. Not sure if we should go our way on this and mix both concepts

[dannylamb]

@jonathangreen I'm leaning towards 1. I would like consistency across all microservices, fedora, and Drupal. And since this seems more like an AuthN thing than an AuthZ thing, I'd prefer we remain agnostic about WebACL on the underlying Fedora resource.

[acoburn]

Why not just set the configuration values for fcrepo.authUsername and fcrepo.authPassword in the $KARAF_HOME/edu.amherst.acdc.exts.image.cfg or am I missing something?

[jonathangreen]

@acoburn we are using this repo to do authentication against Fedora and as @dannylamb mentioned, hopefully in the future everything. It isn't using basic HTTP authentication, rather it is looking for a JWT set in the Authorization header of any requests it receives. Some more info on what we are doing in this ticket https://github.com/Islandora-CLAW/CLAW/issues/520.

Because we aren't using HTTP basic authentication authentication in fedora those configuration values don't help us with the authentication issues. What I'm thinking would be a good solution is that the Authorization headers received, are just forwarded on if they are set. That would let someone pass along different basic HTTP auth headers as well if desired. Is this something you would be interested in supporting?

That would let people call the image service with something like:

curl -u fedoraUsername:fedoraPassword "http://localhost:9081/image?context=http://localhost:8080/fcrepo/rest/image/resource&options=-resize%20400x400" -H"Accept: image/jpeg"

and we could do a call that would look like this:

curl -H "Authorization: Bearer <TOKEN>" "http://localhost:9081/image?context=http://localhost:8080/fcrepo/rest/image/resource&options=-resize%20400x400" -H"Accept: image/jpeg"

[acoburn]

@jonathangreen possibly? I don't have that use case, and it would add complexity to the image service (and all other such services), which I don't like. The work-around is also, arguably, quite simple -- do a HEAD request on Fedora for the resource, if it succeeds, run the service; otherwise don't.

[jonathangreen]

@acoburn not sure if I follow you there. Everything in the fedora is behind this authentication scheme, so the head request would always fail...

[acoburn]

@jonathangreen oh I see. Supporting arbitrary Authorization headers is most probably not going to happen.

[acoburn]

To be clear about _why_ that is, consider this: fcrepo-camel would need to be substantially re-worked to support this, and someone would need to write a shim for use with camel-http4 so that the headers would be passed on properly. Only then could the Amherst services make use of such flexible AuthN mechanisms. As it is, those options are not available.

[jonathangreen]

Cool. Thanks @acoburn. Based on this I think I'm going to close this ticket, and look at other alternatives for our image service in #572.