Introduce OIDC login in Admin Manager

Currently, administrators access the Veridium Admin Manager through certificate-based authentication, header authentication, and SAML. We aim to augment this by integrating OIDC support, enabling authentication within the Admin Manager using this method as well.

1. Third-party IdP

This is the most generic integration that can contain an external IdP that responds to OIDC requests from Veridium Admin. Based on the OIDC response, the admin users are created in Veridium and assigned the corresponding permissions based on AD group membership mapping that is already present in previous versions.
No separate enrollment and authentication flows are available in this scenario.

2. OIDC provider is Shibboleth with Veridium users

This method uses the existing Veridium enrollment and authentication flows' configuration for Veridium Manager admin login.

This requires an existing user in a Directory Service connected to Veridium via LDAP. Administrators would enroll via the Self-Service Portal and be assigned the corresponding permissions based on AD group membership mapping that is already present in previous versions. User attribute sync will be done during authentication, so when entering the Veridium Manager at the end of a successful authentication, the user will be presented with the appropriate permissions inside it.

Authentication is done through Shibboleth which is configured to consider Veridium as both the Service Provider and the IdP for this scenario.

Because veridium manager has already a way of authenticating using SAML, it was created an exclusivity in the settings in order to use one of the IdP way to authenticate, either SAML or OIDC (or none)

3. Technical perspective

From the technical perspective we implemented the OIDC for Admin manager as following:

1. Websecadmin act as OAuth 2.0 resource server in a Spring Security application to validate JWT tokens. It performs the following steps:

   • it sets up the resource server to handle JWT tokens using the provided JWK Set URI.

   • It configures the JWT decoder using NimbusJwtDecoder with the provided JWK Set URI. This decoder is responsible for validating and decoding the JWT tokens.

   • Sets a custom JWT type verifier (DefaultJOSEObjectTypeVerifier) to ensure the token is of type JOSE or at+jwt.

   • It sets a custom JWT authentication converter (jwtAuthenticationConverter) that is used to convert a decoded JWT token into an Authentication object.

   • It configures a custom authentication entry point to handle authentication exceptions.

   • If an authentication exception occurs, it logs the error message and sets the HTTP response status to 401 Unauthorized.

   • the session storage in the database is not existent for the OIDC, because every API call that is coming from frontend, had attached a Baer token, and that token is held in the browser session storage.
     
     Websecadmin is used to secure a Spring-based application by validating incoming JWT tokens using a specified JWK Set URI. It ensures that only valid and correctly typed JWT tokens are accepted, and it handles authentication failures gracefully by logging errors and returning an appropriate HTTP status code. This configuration is essential for securing REST APIs that rely on OAuth 2.0 and OpenID Connect for authentication and authorization.
     

2. Angular client to use OpenID Connect (OIDC) for authentication:
   This configuration in the initialization phase of your Angular application, typically in a service or a component that handles authentication. This ensures that the application is properly authenticated with the OIDC provider and can handle user login, token validation, and automatic token refresh.

Flow

1. User Initiates Login:

   • The user attempts to access a protected resource in the Angular application.

   • The Angular application checks if there is an existing valid ID token in session storage. If not, it initiates the OIDC login flow.

2. Authorization Request:

   • The Angular OAuth service redirects the user to the OIDC provider's authorization endpoint.

   • The request includes parameters such as client ID, redirect URI, response type, scope, and code verifier (authentication with PKCE ).

3. User Authentication:

   • The user authenticates with Shibboleth.

   • Upon successful authentication, the Shibboleth generates an authorization code and redirects the user back to the specified redirect URI in the Angular application.

4. Authorization Code Handling:

   • The Angular application receives the authorization code from the Shibboleth.

   • The OAuth service in Angular exchanges this authorization code for tokens (access token, ID token, and optionally a refresh token) by making a backend call to the OIDC provider's token endpoint.

5. Token Management in Angular:

   • The received tokens are stored in session storage.

   • The OAuth service sets up automatic silent refresh to renew tokens before they expire.

   • The access token is used to authenticate subsequent API requests to the Spring resource server.

6. Interceptor in Angular:

   • An HTTP interceptor in Angular attaches the access token to every outgoing request if the token exists and is valid.

   • This ensures that the Spring resource server receives a valid token with each request.

7. Spring Resource Server Validates Token:

   • The Spring resource server receives the request with the attached access token.

   • It validates the token by checking its signature, expiration, and other claims against the public keys fetched from the OIDC provider's JWKS endpoint.

   • If the token is valid, the request is processed; otherwise, a 401 Unauthorized response is returned.

8. Access Protected Resources:

   • Valid requests are authorized, and the resource server responds with the requested data.

   • Unauthorized or invalid token requests are rejected, prompting the Angular application to handle the error (redirect to home page)

9. User Logout:

   • When the user logs out, the Angular application clears the tokens from storage.

   • The user is then redirected to a post-logout URL (home page).
     

4. UI configuration and migration of data

From the zookeeper migration perspective:

1. it moves the SAML configuration from saml/admin-auth.json to admin.json

2. it’s completing the ContentSecurityPolicy property from admin.json with issuer URL because it’s needed for xhr request made for .well-known call.

3. it’s removing the "/websecadmin" extension string if exists from the SAML base url (because of the upgrade of SAML version and refactoring)

4. because Shibboleth will be up and running after zookeeper migration is done, the OIDC configuration will not be populated during ZK migration (it won’t have any data) thus the population in ZK will happen on the first save from UI of the OIDC configuration. The only field that will need a input from the user will be the redirect uri.

From the UI configuration perspective, the Admin OIDC settings for authentication will be present in the Admin Auth settings area with a new tab named OIDC Auth.
In this settings section we will find all important configurations that allow OIDC Admin manager application to properly communicate with Shibboleth provider.

The action panel from the right is having an upgrade regarding the settings:

1. Configure OIDC Veridium IDP → will create a new service provider application for Admin manager with the settings that are provided in the OIDC Auth tab. This application will have the type OIDC

2. Download OIDC Metadata → will download the well-known json from the provider.

3. Copy OIDC Metadata URL → it’s a handy action that will allow to get the URL for the well-known json content.

Because SAML and OIDC can not be enabled both at once, we enhance an UI mechanism to prevent enabling both on the same time. For example if we have OIDC feature enabled, then on SAML tab we will face this warning with no enable SAML toggle present.

The same scenario is active when we have SAML active and go to OIDC tab.

In Shibboleth we added a new CorsFilter that is allowing Access-Control-Allow-Origin from the angular app.

5. Other improvements

1. In this feature, we had the opportunity to improve the SAML library and simplify the implementation, with this we increase the SAML library to version x and we get rid of Bean declarations. From the user perspective, on the SAML part should be no difference when we are referring to the admin manager authentication.

2. SAML configuration are moved from the saml/admin-auth.json into admin.json under samlAuthConfiguration. With this change we aim to create a single place for admin settings.

3. Usage of Provider and Observable for all configuration from admin.json, instead of reading and writing directly with Zookeeper nodes. From the user perspective should be no difference.