This Play Framework app provides an API for managing Identity accounts. The API forms a thin wrapper around our Identity Provider.
While it's in a state of transition, it's also used to manage user service and marketing permissions.
The main components of the app are:
classDiagram
class UserController
class UserService
class CompositeUserService
class OktaUserService
class legacyIdentityDbUserService
UserController <--> UserService: User
UserService <|-- CompositeUserService
CompositeUserService --* OktaUserService
CompositeUserService --* legacyIdentityDbUserService
UserService: healthCheck()
UserService: fetchUserByIdentityId()
UserService: ...()
- Set up a local PostgreSQL service listening on port 5555.
- Install local AWS credentials for the Identity account.
- Set the
AWS_PROFILE
environment variable toidentity
:export AWS_PROFILE=identity
- Run the app:
sbt run
The app configuration has three levels of precedence. Any values repeated at a higher level will override those at a
lower
level.
The levels are, in order of precedence:
Secret and private settings are stored as
AWS SSM parameters,
named in the format:
/<stage>/identity/gatehouse/<param key>
where param key
is a slash-separated
Hocon key.
Eg.
/CODE/identity/gatehouse/play/http/secret/key
would give us a play.http.secret.key
value.
Secrets are stored as SecureString
parameters.
Private settings are stored as String
parameters.
Settings that aren't private but vary between deployment stages are set in the stage-specific config files in
the conf
directory. These might be values that we expose in browsers, for example.
Finally, settings that aren't private and are the same for all deployment stages are set in the conf/application.conf
file.
TODO: Instructions on how to generate an Okta access token locally.
We use the Okta Code org locally because this makes it easier to develop and test with users that have already been
registered in Code gateway.
This repo contains the schema files for the Gatehouse database, these can be found in the ./db
folder.
The following steps require docker
, aws
, and jq
installed.
- Create a new file in
./db/migrations
with the naming schemeV(YYYYMMDD)__Migration_Description.sql
. The naming scheme is important and the migration will be skipped if it does not adhere to it, take note of the double underscore between the version number and migration description. - Run
./db/test.sh
to test and verify your new migration against the local test database. - Create a PR and merge your new migration into
main
- Run
./db/migrate.sh CODE
to apply the migrations to CODE.- You will be prompted to rotate the admin user credentials, we suggest you always do this but you may want to delay the rotation if you are worried about your migration causing any outages.
- Run
./db/migrate.sh PROD
to apply the migrations to PROD.