You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the task
FAM AWS "production" supports downstream apps for DEV/TEST/PROD.
For BCSC login, apps with DEV/TEST use BCSC's TEST environment; only apps with PROD use BCSC's PROD environment.
However, BCSC returns JWE (encrypted)token (not the JWT token) and this encryption/decryption requires AWS KMS public key for BCSC to do token encryption.
On BCSC side, for their DEV/TEST/PROD integration with FAM, they are all configured to work from FAM "proudction" AWS KMS (KMS expose jwks endpoint: /jwks.json) to get the public key.
This has disadvantage for FAM to test BCSC integration because we can't test changed code for BCSC integration
without deploying to FAM production. Moreover, due to the timeout limit issue from Cognito we found in the past
that caused BCSC user login to fail (incomplete), the solution was to hardcoded AWS JWKS endpoint (/jwks.json)
production value at BCSC side (DEV/TEST/PROD) in order to have BCSC login process within time limit.
In the recent past there was time due to the backend library not in support anymore and that forced us to replace
the library for FAM BCSC integration code. Also there can be times that we need to update some other library, for
example - "cryptography"/"authlib"/"pyjwt". Above upgrade might need FAM BCSC integration code to be tested before
moving to production. In the past, we (FAM team) had to contact BCSC team to switch their hardcoded /jwks.json value
for their DEV environment to use our FAM AWS DEV JWKS endpoint value so FAM team can test BCSC integration code. This change impacts downstream apps in DEV environment for BCSC login to be broken. Also each time when BCSC integration code changes happens if we need to switch back and forth on BCSC side, then it becomes unsustainable (this was commented by BCSC team Ryan).
We may want to discuss possible ways to be able to do BCSC integration code testing without affecting downstream apps and not requiring to ask BCSC team to switch configuration.
Acceptance Criteria
first
Additional context
Maybe better to involve Conrad Gustafson in discussion, who has deeper knowledge of this integration and more talk with BCSC team in the past.
Describe the task
FAM AWS "production" supports downstream apps for DEV/TEST/PROD.
For BCSC login, apps with DEV/TEST use BCSC's TEST environment; only apps with PROD use BCSC's PROD environment.
However, BCSC returns JWE (encrypted)token (not the JWT token) and this encryption/decryption requires AWS KMS public key for BCSC to do token encryption.
On BCSC side, for their DEV/TEST/PROD integration with FAM, they are all configured to work from FAM "proudction" AWS KMS (KMS expose jwks endpoint: /jwks.json) to get the public key.
This has disadvantage for FAM to test BCSC integration because we can't test changed code for BCSC integration
without deploying to FAM production. Moreover, due to the timeout limit issue from Cognito we found in the past
that caused BCSC user login to fail (incomplete), the solution was to hardcoded AWS JWKS endpoint (/jwks.json)
production value at BCSC side (DEV/TEST/PROD) in order to have BCSC login process within time limit.
In the recent past there was time due to the backend library not in support anymore and that forced us to replace
the library for FAM BCSC integration code. Also there can be times that we need to update some other library, for
example - "cryptography"/"authlib"/"pyjwt". Above upgrade might need FAM BCSC integration code to be tested before
moving to production. In the past, we (FAM team) had to contact BCSC team to switch their hardcoded /jwks.json value
for their DEV environment to use our FAM AWS DEV JWKS endpoint value so FAM team can test BCSC integration code.
This change impacts downstream apps in DEV environment for BCSC login to be broken. Also each time when BCSC integration code changes happens if we need to switch back and forth on BCSC side, then it becomes unsustainable (this was commented by BCSC team Ryan).
We may want to discuss possible ways to be able to do BCSC integration code testing without affecting downstream apps and not requiring to ask BCSC team to switch configuration.
Acceptance Criteria
Additional context
The text was updated successfully, but these errors were encountered: