Architecture
AWS Cognito is a SaaS product that has similar capabilities to Keycloak. The main advantage is that we add custom behaviour to add authorization logic as part of the login process. This can be done with Keycloak, but it requires the creation of custom extensions to Keycloak that are not acceptable on the SSO Pathfinder Common Component.
The FAM user pool acts as a user directory in Cognito. In the case of FAM, there will not be any Cognito users as this is counter to OCIO policy which dictates that government digital services make use of approved identities (IDIR, BCeID, and BC Services Card). The user pool enables log in with external identity providers only. There is no user registration, and only the minimal amount of personal information is stored.
The Pathfinder SSO service brokers BC government approved login services (BCeID, IDIR) and provides projects a self-serve lifecycle to create authentication integrations to these services. Pathfinder SSO supports OIDC connections, even when the upstream IDP only supports SAML (this is the case for the Siteminder common login service).
It is worth noting that the FAM user pool can be configured to integrate directly with the IDIR and BCeID login services instead of proxying through Pathfinder SSO. Pathfinder SSO is a matter of convenience for this pattern and could be removed as a component in the final target architecture. The process to set up the direct integrations with the identity providers is somewhat time consuming but not technically challenging.
The IDIR IDP is an integration through Pathfinder SSO to the IDIR authentication service. This integration makes it possible to create application clients in the user pool that will provide digital products the ability to have users log in through IDIR using the BC government common logon page.
Note that for IDIR authentication there is an option to integrate through Siteminder or through Azure AD. Azure AD is the preferred method at this time as it allows the enforcement of multi-factor authentication (MFA) if necessary.
The BCeID IDP is an integration through Pathfinder SSO to the BCeID authentication service. This integration makes it possible to create application clients in the user pool that will provide digital products the ability to have users log in through BCeID using Azure AD.
Note that this integration is scoped to Business BCeID only. If we discover that there is a requirement to support Basic BCeID, a separate integration will be created specifically for that identity.
The IDIR authentication service is provided through the BC Government common logon page (CLP) and implemented with Siteminder.
A future enhancement will offer IDIR authentication through Azure AD (a SaaS service provided by Microsoft). The IDIR Active Directory domain is synchronized between on-premise servers and the Azure cloud service in order to provide cloud-based authentication.
The BCeID authentication service is provided through the BC Government common logon page (CLP) and implemented with Siteminder. It is assumed that Business BCeID is required and Basic BCeID is not required. If a requirement for Basic BCeID is discovered, another integration to the CLP will be created in the FAM user pool.
Note that Personal BCeID is no longer supported. Individual authentication for government digital services is supposed to use BC Services Card. If this becomes a requirement, BCSC IDP integrations will be created in the FAM user pool.
The BCSC authentication service is provided by IDIM by means of a custom OIDC service. Note that there is significant technical work in FAM to integrate Cognito and BCSC. See BCSC Encryption for details.
This is custom logic implemented as a pre-token generation Lambda trigger from the FAM user pool. During every authentication event, the function gets triggered. The function receives the identifier of the user and the identifier of the application that is being logged into. Using this information, the function runs a database query to find out the applicable roles for the user within the context. These roles are then injected into the OAuth token (JWT) that is returned to the user. Digital services can use the role information embedded in the token to trigger authorization-based business logic such as allowing access to a certain UX function or enabling specific web service endpoints.
The FAM database holds the operational data associated with each user that defines what privileges they should have within the FSA suite of applications. It is a serverless, managed database hosted within AWS Canadian availability zones and subject to the managed guardrails of the BC Government AWS tenant.
The RDS Proxy service does connection pooling so that the serverless lambda functions don't connect directly to the database. It provides performance because when a connection is requested, an existing connection is returned instead of creating a new connection on each request.
The FAM REST API is a suite of web service endpoints that enable management of the data in the FAM DB. This is the back-end to the FAM web application that lets users act as application administrators and authorization grantors. It is implemented using AWS Lambda.
The AWS API Gateway exposes public endpoints for the FAM REST API. The FAM REST API is a Lambda function that cannot be called directly from the internet, so the API Gateway accepts incoming HTTP requests and forwards them in the form of direct calls to the Lambda. The API Gateway can also be configured to enforce security rules around the requirements for token validation, scopes and custom roles.
Cloudfront is a content delivery network (CDN) service that can host static files. It is a preferred way to deliver content such as images, HTML files, and Javascript single page applications (SPA) as it does not require the provisioning of a server or container within AWS. It provides a number of other benefits such as DDoS protection and local caching.
The public web assets served by Cloudfront are stored in an S3 bucket as part of the FAM infrastructure.
The FAM Angular SPA Code is a user-interface that can be used to manage the FAM operational data. This is the front-end to the FAM web application that lets users act as application administrators and authorization grantors. Like any SPA, it is a bundle of static files that the user downloads and runs in their browser. The application interacts with the FAM REST API in order to perform back-end functions.
See details on the Database Migration Management page.
The Flyway lambda gets its list of SQL scripts from an S3 bucket managed in the FAM workspace.
FAM is a client of the Forest Client API which is an external service. FAM uses this API to validate forest client numbers and to provide up-to-date display names for Forest Client records. FAM does not cache Forest Client data.
FAM is a client of the IDIM IDIR/BCeID Web Service. FAM uses this API to validate IDIR and BCeID usernames input by FAM users in the admin tool. In the future, this web service will be used to search for users in the admin tool.
This component is managed by the FAM team as a simple proxy service to the IDIM IDIR/BCeID Web Service. It is available to the FAM API over the internet through OpenShift routing. It was created in order to provide connectivity between FAM API and the IDIM IDIR/BCeID Web Service (which is only available on the SPAN/BC network).