Platform

Deployment

The Asterias platform is deployed to AWS using Terraform. The core AWS technologies used include:

  • ECS
  • SES
  • Route 53
  • ALB
  • RDS (PostgreSQL)
  • ElastiCache (redis)

Each environment is managed by its own AWS account and is completely isolated from other environments. The current environments include UAT and Development.

The load-balancer will route all requests to the front-end container(s) with the exception of routes that start with /api, /auth or /graphql. The front-end container is an nginx container that serves static assets.

APIs

Each environment exposes a GraphQL and REST-based API. The REST API is used primarily to integrate with third-party systems and to perform operations that are cumbersome or not naturally suited to GraphQL i.e. file uploads. Click on the links below to view the relevant API documentation or download the specification/schema.

Authentication

User

The authentication mechanism used is slightly more involved than a traditional web application which has to trade off XSS for CSRF attacks and vice-versa. An article explaining the concept may be found here: The most secure way to store JWTs.

Instead of storing the token in local/session storage or in a cookie, the platform makes use of two distinct types of tokens:

  • Session token: A long-lived token (by default, 8 hours)
  • Access token: A short-lived token (by default, 10 minutes)

Acquiring a session token is accomplished by logging in with a username/password pair or via SSO (SAML). On success, the session token is stored in a cookie. The cookie has path set to /auth, samesite set to strict and httponly and secure are both on. The session cookie are also signed and verified.

The only useful operations that may be performed with the session token include logging out of the platform, and obtaining an access token. The front-end does not directly store this token in any way. Instead, the service worker keeps this in a variable that cannot be access directly by any part of the application.

The service worker is responsible for intercepting all requests to API endpoints and injecting the access token into the request in the form of the Authorization header. The service worker further ensures that the access token is refreshed as required.

Automation

The SCIM endpoints use a single, long-lived access token for authentication. These tokens are generated during integration and communicated out-of-band to the relevant parties.


Table of contents