Tech Blog

Cloud Apps: Retrieving Data from Other Institutions

One of the powerful features of Cloud Apps is the ability to make API requests in the context of the current user. This means that no API key is required and the user’s privileges are considered when determining which APIs are accessible. In a consortial setting, there is often a need to retrieve or update data in other institutions within the consortium. This is a common use case for service providers and central offices who have in the past built stand-alone apps to fulfill their requirements. The Cloud Apps framework doesn’t provide a built-in capability to make API requests in other institutions. However, we can leverage the public cloud to design a solution which allows us to easily make API calls to other institutions from our Cloud App.

At a high level, the solution consists of the following pieces:

  • An AWS API Gateway to handle the incoming requests
  • The AWS Secrets Manager to store the API keys for the various institutions
  • An AWS Lambda function which performs the authentication from the Cloud App and proxies the request with the relevant API key
  • An Angular class which provides a similar interface to the Cloud App Rest Service
  • An Angular component which calls our rest client

The components are seen in this diagram:

AWS Components

The following AWS components are part of this solution. They can be built using the AWS console or by using the scripts and  CloudFormation template which are in the Github repository referenced below.

API Gateway

The API Gateway is a thin layer which simply provides a proxy to our Lambda function. The ANY method on the special route {proxy+} indicates that all requests will be forwarded to the Lambda integration.

Secrets Manager

The AWS Secrets Manager provides secure storage for sensitive strings such as keys and credentials. We created a secret which includes name/value pairs, each pair an institution code and its corresponding API key.

Lambda function

The function performs the following tasks:

  • Validates the Cloud App authentication token sent with the request. Note that in order to allow only desired Cloud Apps and institutions to call our proxy, we can validate the information provided in the token.
  • Retrieves the API key for the desired institution from the secret manager.
  • Adds the API key to the request and forwards it to the Alma API
  • Proxies the response back to the caller

The code for the Lambda proxy function is available in this Github repository. It also includes a CloudFormation template and scripts to easily deploy the resources to AWS. The repository’s readme contains instructions for how to deploy the stack.

Cloud App

The following are added to our Cloud App:

Rest Client

The Rest Client class exposes the same interface as the Cloud App Rest Service in order to provide a consistent coding experience. The call method accepts the request along with an additional parameter for the institution code, which is passed along to our proxy in a special X-For-InstCode header. The proxy uses the value in that header to retrieve the relevant API key, as explained in the previous section.

Component

Finally, we’ve build a component which includes a few fields- one to select the institution and another for the primary ID of the user whose details we wish to retrieve. The component exposes two methods- one uses the rest client to retrieve the user details (GET user), and the other uses the rest client to update the user details (PUT user).

The code for the rest client and the component are available in this Github gist.

Summary

The solution outlined here can be adapted to your particular needs and shows how the public cloud can be leveraged to easily provide a way to access data from other institutions within my Cloud App.

Leave a Reply