Update Token Authentication Service for ICAM

[yonatan-dp]

User Story As an EASEY user, I want to be able to successfully authenticate existing tokens So that I can perform my authorized actions in the EASEY system as usual.

Development Notes • Update Token Authentication Service to call new ICAM services instead of SOAP Services • Refactor as needed • Deprecate/remove SOAP service API end points • Update Guards

Acceptance Criteria:

1) Login Functionality

AC1.1: The login page must only require a userID for login, and no password field should be present. AC1.2: Upon entering a valid userID, the system should redirect the user to the OIDC provider for authentication. AC1.3: Invalid userIDs should result in an appropriate error message being displayed without redirection to the OIDC provider. AC1.4: The system should handle the OIDC callback and log the user into the application upon successful authentication. AC1.5: Ensure session creation and user-specific data are correctly initialized upon successful login. AC1.6: Ensure facilities and roles are correctly retrieved from CAMD and are used for securing application resources correctly.

2) Token Refreshing Functionality

AC2.1: The application must automatically refresh the OIDC token before it expires without user intervention. AC2.2: The refreshed token should be valid, and user sessions must continue without requiring a re-login. AC2.3: If a token refresh fails, the user should be redirected to the login page with an appropriate error message.

3) Retrieving Organization Information for Users

AC3.1: The application must correctly fetch and display use information (first and last names) from the OIDC token claims post-login. AC3.2: Changes in organization information on the OIDC provider side should reflect in the application after a new login.

4) Token Validation

AC4.1: The application must validate OIDC tokens using the provider’s public keys to ensure they are genuine. AC4.2: Expired or tampered tokens should be rejected.

6) Login Scenarios for Different User Types Across Multiple Paths

AC6.1: Verify that both EPA and non-EPA users can successfully log in through all available paths (sign in, sign up, and migrate). AC6.2: User-specific redirections or flows (e.g., first-time login instructions for new users) should work as expected for both user types. AC6.3: Ensure that error handling and messages are appropriate for each scenario and user type. AC6.4: Post-login redirection to intended pages (or dashboards) must be correct depending on the user type and the authentication path used.

[esaber76]

Receiving the attached error trying to log in from VDI or ERG laptop with an epa.gov account (saber-ad).

[maheese]

I received the following error when I switch between my accounts.

Steps to reporoduce:

1. Log in with first account (mheese-non-org)
2. Select the Monitoring Plans link
3. Select "Logout"
4. Log in with the second account (mheese-no-pr)
5. Select Monitoring Plans and the error message appears

When I look at the log out put for the facilities-api I see this:

17:55:42.112: [APP/PROC/WEB.0] data: { 17:55:42.112: [APP/PROC/WEB.0] message: 'Existing session for the provided token does not exist.', 17:55:42.112: [APP/PROC/WEB.0] errorId: '6b54add0-2228-430a-85ce-3fc505d1e22d', 17:55:42.113: [APP/PROC/WEB.0] statusCode: 400 17:55:42.113: [APP/PROC/WEB.0] } 17:55:42.113: [APP/PROC/WEB.0] },

This probably won't be a common use case.

[yonatan-dp]

We made a change to how tokens are validated late yesterday. Can you retest once it is deployed? Will confirm deployment with Mark.

[maheese]

When I log in with an organizational user (an account with an epa.gov email address), the login message states that I will be redirected to Login.gov. Organizational users do not use Login.gov. They are redirected to the EPA Gateway. Here's what's currently displayed in ECMPS:

Here's what is displayed in CDX:

[lgiannini1]

Receiving the attached error when logging in with my non-EPA lgiannin_ds or lgiannini_dp accounts

[maheese]

Receiving the attached error when logging in with my non-EPA lgiannin_ds or lgiannini_dp accounts

I am also receiving this error when I log in with my non-organizational account. This was working yesterday.

[ibarra-michelle]

Today, I am also receiving the same 400 error for the non-organizational account:

[yonatan-dp]

When I log in with an organizational user (an account with an epa.gov email address), the login message states that I will be redirected to Login.gov. Organizational users do not use Login.gov. They are redirected to the EPA Gateway. Here's what's currently displayed in ECMPS:

Here's what is displayed in CDX:

Correcting this.

[yonatan-dp]

We made a change to how tokens are validated and are not able to deploy since morning because Github actions (the way we deploy) is down for all GitHub users (not just EPA). Some of these error may be related to that, so let's retest and confirm once we deploy. I will continue to look at them and see if I see anything in my local.

[yonatan-dp]

We had a number of environment issues yesterday, almost all day.

1. Github was down and
2. mock permissions were disabled when the app redeployed automatically after a build.

Fixes

1. We have fixed the "login message issue" reported by Mike
2. The "Unable to validate access token" issues for EPA users has also been fixed.
3. The error "request failed with a status code 400" was caused by the mock permissions being disabled during app deployment. Mark has resolved that so that this issue does not happen again accidentally.

A deployment was done late yesterday after GitHub resolved the GitHub actions issue. Please retest all issues reported above.

[ibarra-michelle]

After discussing internally, logins to the dev/test/beta environments will be the way test these changes to the application.