Enterprise-CMCS / macpro-quickstart-serverless

Other
18 stars 14 forks source link

add code to integrate QuickStart app with Okta OIDC #559

Closed leslie-corbalt closed 2 years ago

leslie-corbalt commented 2 years ago

Purpose

  1. Figure out how to integrate Okta OIDC with Cognito user pool
  2. Verify that the QuickStart template login works with Okta OIDC, Okta SAML, and Cognito
  3. Get user info from identity token, rather than from Auth.currentUserInfo(), since all the information is available in the identity token received from the identity provider

Linked Issues to Close

https://jiraent.cms.gov/browse/CMCSMACD-531 https://jiraent.cms.gov/browse/CMCSMACD-544 https://jiraent.cms.gov/browse/CMCSMACD-545

Approach

Add code to integrate with Okta OIDC Add parameters to enable Okta SAML and Okta OIDC Verify integration with both Okta types Handle case where both Okta types are provisioned -- use Okta OIDC and not Okta SAML, since only 1 Okta IdP can be enabled

Tested: When Okta SAML is configured and OIDC is not, user can log into Cognito or SAML When Okta OIDC is configured and SAML is not, user can log into Cognito or OIDC When Okta OIDC and SAML are configured, OIDC and Cognito are enabled (SAML is not) and user can log into OIDC or Cognito When neither Okta SAML or OIDC is configured, user can log into Cognito Verified that user Profile displays phone number stored in Cognito user pool. Verified that user can update phone number in Profile and it is stored in Cognito user pool.

Learning

Even though serverless docs say it is possible for serverless.yml to reference a secret in secretsmanager using ssm: syntax, this is not possible due to permissions restrictions on the cloudtamer role. The cloudtamer role cannot access a secret with prefix /aws/reference/secretsmanager/ which is required to get a secret via ssm.

Pull Request Creator Checklist

Pull Request Reviewer/Assignee Checklist

mdial89f commented 2 years ago

Hey @leslie-corbalt These changes appear to break the Profile functionality that exists.

I'd like to retain this functionality if possible, as it nods to how a user might manage some of their attributes on that they should be allowed to update. Is there a way for your changes to be made, but continue to allow this?

leslie-corbalt commented 2 years ago

Hey @leslie-corbalt These changes appear to break the Profile functionality that exists.

  • Signup/login using cognito to the deployed env for this PR https://d6qq3huwa1tam.cloudfront.net/
  • Once logged in, click My Account in the top right, then Profile
  • Punch in a phone number and click Save
  • The permissions to make the update aren't available.

I'd like to retain this functionality if possible, as it nods to how a user might manage some of their attributes on that they should be allowed to update. Is there a way for your changes to be made, but continue to allow this?

I added the "aws.cognito.signin.user.admin" scope back to the user pool client. Now the user can update their phone number in Cognito user pool.

I will create a new PR that just focuses on this scope. When Cognito is backed by Okta, the ability for a user to update their phone number in the app causes the Cognito user pool to be updated. The user attributes in the user pool no longer match the user attributes in the Okta directory.

codeclimate[bot] commented 2 years ago

Code Climate has analyzed commit e96cf430 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 0.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 24.5% (-0.8% change).

View more on Code Climate.