Update Controller for ICAM Changes

[yonatan-dp]

User Story As an EASEY user, I want to be able to successfully login by using the new ICAM authentication servers So that I can perform my authorized actions in the EASEY system as usual.

Development Notes

• Modify Auth Controller to consume newly updated Auth services.
• Modify DTO’s as needed. 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.

[lgiannini1]

Verified during testing of #6199

[ibarra-michelle]

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