Identity Microservice

Build

Build status:

Environments listed bellow are divided into 2 groups, first are the environments specified at build time which are injected into the code. Second group are remote environments that are set into our AWS account, using the Systems Manager parameters to allow the code to fetch without the values living on the repo or injected through build. Benefits of the second group is that values can be changed without deployment but also are securely/encrypted stored into the deployed AWS account making it harder to be erroneously exposed.

*Local environments: *

• PORT - Which port should this API run into (optional, defaults to 8080)
• COMMIT_HASH - From which commit short hash this server is running
• TZ - NodeJS timezone
• NODE_ENV - Node environment which this service will be running for. Possible values are: local, development or production. Optional
• STAGE - The stage on the AWS that this API is running
• SSL_CERT_ARN - The SSL certificate to bind the service to
• ALB_HOSTNAME - The service hostname at load balance
• TASK_MEM_SOFT - The ECS task memory
• TASK_NUM - The ECS number of tasks
• CONTAINER_ENABLED - Indicates if deployment should be serverless only or have a container as well

Remote environments: (all values are prefixed with /module-identity-${process.env.STAGE}/env/ and available on the deployed account after being manually configured)

• TOKEN_SECRET - Authentication JWT secret

Build steps

1. Run npm run build to transpile/build the Typescript code into regular Javascript. This will generate a new build folder.
2. Generate a new folder with the contents of build folder and copying the the following node_modules, package.json, package-lock.json into the root on the folder.
3. Within the new folder, you can run npm run start to get the backend up and running in a non containerized way.

Resources

Endpoints

• 🚧 Development: https://auth.dev.creator.co/
• 🟢 Production: https://auth.backend.creator.co/

Documentation

• API Docs

Development

1. Run npm i if dependencies are outdated or not installed already.
2. Run npm run dev to start a development server with live reload (updates after code change).

Container based

Building and getting identity-microservice running can be accomplished by running npm run docker for getting just the API running on port 4000.

Docker will transpile the application into Javascript code and will generate a container with only the required resources for running the API. This process should get the local API running much closer to what our production system is.

Database if pointed to localhost should be changed from localhost to host.docker.internal in order to be able to loopback from the container to the host machine. `

FYI, https support to come soon on container based services.

CI/CD

CI/CD implemented through GitHub actions and workflows are defined on Creator-co/tool-github-workflows repo.

Environments

For each environment defined on the deploy job, we must set the following secrets at the repository environment level:

• AWS_ACCESS_KEY_ID - AWS Access key on the account to be deployed
• AWS_SECRET_ACCESS_KEY - AWS Secret key on the account to be deployed

For each environment defined on the deploy job, we must set the following variables at the repository environment level:

• I_AWS_REGION - The AWS region to have the service deployed

Setup

Setup first admin

Because we have an exclusive route for admins to add admins; after the first deployment getting the first admin in the system needs to follow those simple steps.

1. • Configure your AWS CLI account, with the crendetials of the the environment you are configuring.
2. • Change the generate-local-envs script on package.json to the region and environment you want. 2.1 - Example: "generate-local-envs": "mv .env .env-old; true && region=ca-central-1 stage=dev sls export-env --filename .env --skipFailure", for the dev account.
3. • On ./src/routes/user/admin/post.ts, change the route ACL to public; Identity.Globals.AccessLevel.ADMIN -> Identity.Globals.AccessLevel.PUBLIC
4. npm run dev to run the local server with the environment you are setting up.
5. • Using module-identity-client and configuring the server to be localhost, run

    // Register Admin
    const b = await client.api.user.createAdminNew({
        email: '[email protected]',
        firstName: 'Joe',
        lastName: 'Doe',
        tmpPassword: 'Test@123',
    })
    // Login
    const loginResponse = await client.authenticator.login('[email protected]', 'Test@123')
    // Respond to auth challenge to change the password
    const challengeResp = await client.api.public
      .createChallenge({
        challengeState: ChallengeInputChallengeStateEnum.NEW_PASS_REQ,
        challengeContext: loginResponse?.['challengeContext'],
        newPassword: 'Creator@123',
        email: '[email protected]',
      })
      .catch(e => e?.response?.data as ErrorResponse)
    console.debug('Challenge resp: ', challengeResp)

Federation - Google Setup

• Go through AWS official docs and follow only the Setting up Google section.

1. • Go to Google Developers console
2. • Choose APIs & Services, then OAuth consent screen. On the OAuth consent screen, be sure to select creator.co as the Authorized domain and fill the other information.
3. • Choose Credentials, then Create credentials. Choose OAuth client ID. Select Web application as the Application type.
   • For the Authorized redirect URLs, we want to add https://<your-user-pool-domain>/oauth2/idpresponse, where the user pool domain can be seen in the App Integration tab of the cognito pool you are configuring. Example
   • For production, it's recommended that you manually configure a custom domain in the cognito pool and set the env COGNITO_USER_POOL_CUSTOM_DOMAIN, so the code can forward users to one of our subdomains instead of quickly seeing an AWS domain.
4. • Create the credentials and download it, saving in a secure place! (1pass - Look for 'IDM - Google - Dev')
5. • From the file, copy web.client_id field and paste on the env.yml:{env}:GOOGLE_CLIENT_ID
6. • Same with web.client_secret field on env.yml:{env}:GOOGLE_CLIENT_SECRET
7. • If the first time you are deploying it, additional steps are required:
   • 7.1 - OAuth URLs - Because OAuth is a client based flow, we need to set a whitelist of URLs we are going to use in our FEs that will ultimately initiate the flow with cognito.
     • 7.1.1 - FED_ALLOWED_LOGIN_URL - Is the main url we will use for login. Example: https://auth.creator.co/login
     • 7.1.2 - FED_ALLOWED_LOGOUT_URL - Is the main url we will use for logout. Example: https://auth.creator.co/logout
     • 7.1.3 - FED_OTHER_ALLOWED_LOGIN_URL - Is the secondary optional URL that will be allowed to instantiate the flow. Usually useful for local environments and/or deep link protocols. Example: https://localhost:3000/login; (More URLs can be added in the Cognito UI but get removed after deployments)
   • 7.2 - Cognito Client Secret
     • 7.2.1 - After the deployment with GOOGLE_* envs, cognito will for the first time generate an app client secret.
     • 7.2.2 - Because it's so secret, and we don't have access through IaC, you will need to go into the dashboard, copy it's value and paste on env.yml:{stage}:COGNITO_CLIENT_SECRET - Dev client secret
     • 7.2.3 - Redeploy with COGNITO_CLIENT_SECRET set and everything should be working as expected.

• Dev Project