AWS Overview
AWS Structure
Organization
Top level = Root
- Management account name = Method Apps
- Management account email address = jody.vanv@methodgrid.com (verified)
Root is the parent organizational unit (OU) for all accounts and other OUs in your organization. When you apply a policy to the root, it applies to every OU and account in the organization.
Learn more: https://us-east-1.console.aws.amazon.com/organizations/v2/home/accounts
Organizational Units (OUs)
Organizational units (OUs) enable you to group several accounts together and administer them as a single unit instead of one at a time.
Accounts
Second Level = Accounts
Currently 1 account: - Account name = Method Apps - Email = jody.vanv@methodgrid.com
An AWS account contains your AWS resources. When you attach a policy to an account, it affects only that account.
Learn more: https://us-east-1.console.aws.amazon.com/organizations/v2/home/accounts
IAM Identities
IAM Identity Center enables you to manage workforce user access to multiple AWS accounts and applications.
We have one managing instance to manage Method Grid user access to our accounts: - Instance name = MethodGrid - Region = Europe (London) | eu-west-2
Learn more: https://eu-west-2.console.aws.amazon.com/singlesignon/home?region=eu-west-2&tab=management#/instances/7535f3ddc87ff1ec/dashboard
Billing and Cost Management
Learn more: https://us-east-1.console.aws.amazon.com/costmanagement/home#/home
App Subdomain
Need for Staging Domain
We need to have a staging domain fully different than production for testing integrations.
How do we deal with app subdomain?
All production functionality should be testable on staging. We don't have a way to test any changes to 3rd party integrations that rely on app.methodgrid.com because staging (and local) share domain with production, which means that, while on staging, any reliance on app.methodgrid.com points to production. This was done probably due to codebase not being domain agnostic (methodgrid.com is typed about 225 times in the codebase). Until we're able to refactor this, and making domain an environment variable, this cannot be tested so it cannot be changed at all.
I propose, even if we could maybe avoid it, we add this change to Data separation proposal.
Reference: Building a SaaS App? You should probably stick to a single subdomain.
Options
Option 2.1: As it is but enhanced
app.as an entrance to redirect (as current)- Single session per subdomain (as current)
- Without account switching
- Actually domain sessions. Able to handle subdomain/account changes instead of breaking session
- No security per account, once you're in you can change account freely without being bounded by accounts
Considerations:
To group users between accounts, user and password is compared, only grouping the ones that match Auth::authenticateEmailAndPassword(). This is very clunky as it breaks separation (and would not hold if password rotation is enforced). Would this functionality connect to all databases looking for users that match? How can we organize this?
Pros: - Improved experience
Cons: - Minimal changes
Consequences: - Improved experience
Option 2.2: Account can be in subdomain or on path
Same as 2.1. The whole app is located at app, accounts are part of the path as app.domain.com/account/path or subdomain account.domain.com/path. Have a middleware to internally rewrite paths (to extract account from subdomain or path) and keep a user domain session field for links.
app.domain.com/account/path = account.domain.com/path
app.domain.com/path won't work anymore
Pros: - Improved experience - No weird redirects - Simpler testing (app is subdomain bound)
Cons: - Work - All clients should have subdomain
Unknowns: - Account fluid subdomain session details
Option 2.3: Authorization Server
We create a new service that is responsible for authentication and user data keeping. App is no longer the owner of user data, it queries an identification server that provides authentication and user data to app. This is a separate service but it could be located in the back-office. Possible problems on latency for other servers, specially when considering new regions. New regions would require their own domain, back-office and identity server.
Reference: How OpenID Connect Works - OpenID Foundation
Identification separation. No reliance on a specific identification system.
OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework. Simplifies the way to verify the identity of users based on the authentication performed by an Authorization Server and to obtain user profile information in an interoperable and REST-like manner.
Pros: - Centralized user management - Single responsibility - Single user manager - Possible session per subdomain - Paving the way for modern auth across multiple services (web, api, mobile..)
Cons: - Extra service that needs to be developed, tested, maintained and provided on all envs - Work++
Unknowns: - How to handle accounts creating their own users? - Where/how would we store which users have access to which accounts? - Security per account? How would we handle an account change? (if at all)
Testing
Whatever option is chosen, we'll need to be able to test this architecture on staging. For option 1 and 3, MG is a domain level app, so staging environments cannot be a subdomain. Option 3 has the added need for an identity server service testing strategy. Option 2 is the easier to test as it can be confined to the subdomain level.