Closed codeclout closed 10 months ago
I'm not sure I understand the use case. Are you just trying to protect the IIIF Lambda from being called by another entity besides CloudFront? We haven't built in any auth support for the lambda itself – the goal of the project is to keep the code focused on interpreting IIIF requests and returning the correct JSON/image responses. It's assumed that any additional functionality would have to be implemented via CloudFront triggers or implementer modifications.
@mbklein - thank you.
During testing we discovered that operationalizing across teams and environments, the private key used for signing the URL passed to the info.json
writer was outside the scope of the LOE for this project.
We are using the CloudFront template and have opted to check the incoming headers to ensure the request is coming from CloudFront, comparing the forceHost
environment variable, set to the distribution for that environment.
Please let us know if there are any glaring issues with that approach.
Thank You, Brian
That seems like a reasonable approach, though incoming headers can easily be faked by a malicious request (or even a benign hacker) to impersonate CloudFront. You could look into adding a known query string or request header (via the CloudFront Origin Request Policy) with a secret in it to make sure the request is not only coming from CloudFront, but from the correct CloudFront distribution.
Hello,
We are reviewing the requirements for using auth type
AWS_IAM
as the auth type for the IIIF API Lambda, behind CloudFront. Outside of the necessary IAM permissions there is a requirement for signed requests when invoking the function using this auth type. Ultimately this application will transition to another team and we are doing our best to keep custom code to a minimum.Has the Samvera community implemented the IIIF API function using the
AWS_IAM
auth type?Thanks, Brian