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.
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
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.