Security Managers Overview

   Journey Manager (JM) The transaction engine for the platform. |   System Manager / DevOps |   21.11 This feature was updated in 21.11.

Journey Manager is designed with a robust security architecture in mind that ensures a safe and secure foundation for users to access forms and applications hosted on the server, as well as call a set of REST API. The security architecture is implemented using Security Managers, which are software components within Manager that handle users request access to different form spaces and modules. Users can be external or internal, and they can require access to form spaces or a combination of form spaces and modules in different environments.

Another important use of security managers is authentication of REST API calls. As Manager provides a set of REST API allowing integration with external systems, it is important to make communication secure. By default, REST API calls use basic authentication, but you can configure any required authentication mechanism, for example, Single Sign-On - OAuth 2.0, for REST API endpoints. Manager 24.10+ comes the Manager API module to configure a dedicated security manager for REST API end points.

You do it by configuring a security manager for a form space or a module that exposes REST API endpoint. When a request is sent to the REST endpoint, a user account, which identifies this call, needs to pass through Spring Security Session Management. The user must be authenticated with the form space's or module's security manager by using Single Sign-On (SSO), such as ADFS, OAuth 2.0 or custom SSO.

Security Managers are responsible for:

• User authenticationUser authentication is the verification of an active human-to-machine transfer of credentials required for confirmation of a user's authenticity.
• User authorizationUser authorization is interested in who the user is, and is used to determine what functions, actions, data, or other parts of an application the user has access to.
• User self-registration
• Session managementSession management is the rule set that governs interactions between a web-based application and users. Browsers and websites use HTTP to communicate, and a web session is a series of HTTP requests and response transactions created by the same user. Since HTTP is a stateless protocol, where each request and response pair is independent of other web interactions, each command runs independently without knowing previous commands. In order to introduce the concept of a session, it is necessary to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications.

Security Manager use the latest technologies, such as TLS, SSL, SHA and AES, to allow them fulfill their responsibilities.

The security architecture enables developers and system administrators to implement best security practices, such as:

• Never log PIIPersonally Identifiable Information (PII) is information about an individual that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and any other information that is linked to an individual. In Europe, PII is known as personal data. information to the Groovy service log.
• Never turn on debug level of logging in production environments.
• Never store passwords in the clear formats.
• Never log passwords to the log files.
• Never pass internal security data to the client, for example, by adding them in the XML files.

A security manager contains one or more authentication providers that can be chained. That is, if one authentication provider can't authenticate a user due to some reason, the next authentication provider is called and so on until the user is authenticated or no authentication providers are left. Providers can be local or delegated, as shown below.

An authentication provider's main job is to authenticate a user that will result in allowing or denying user access to a resource, which is often a form. Security Managers can be exported and imported across different Manager instances to make it easier to implement security requirements.

Manager comes with the following ready-to-use security managers:

• Local Security Manager
• LDAP Security Manager
• Microsoft ADFS Security Manager
• Microsoft WS-Trust Security Manager
• SSO Security Manager
• OAuth2 SSO Security Manager
• Fluent Microsoft ADFS Security Manager  |  19.11 This feature was introduced in 19.11.
• Fluent SSO Security Manager  |  19.11 This feature was introduced in 19.11.
• Fluent OAuth2 SSO Security Manager  |  21.11 This feature was introduced in 21.11.

The SSO Security Manager provides a generalized delegated authentication to external identity management systems. It uses the SSO Authentication Filter to validate the SSO authentication tokens, such as SAML assertions, and then uses a Groovy Authentication Provider to create a linking SSO user account in the local database with a link to the external identity management system.

Journey Manager supports the configuration of PKI certificates for the verification and decryption SAML tokens. These features enable SSO integration without having to deploy Java application code or libraries. Journey Manager ships with the OpenSAML 3 Java libraries for integration with SAML identity providers.

SSO security managers, such as Microsoft ADFS, have specific Groovy scripts, which you can configure to acquire a SSO token or call a chain of authentication providers. It allows you to create various SSO and login flows. The simplified flow sequences are shown below:

SSO Flow

1. SSO Get Auth Token, which is passed into the authentication providers.
2. Authentication Providers. If there's no result or there is a local authentication provider, it can go to the login flow.
3. SSO authentication OK response.
4. SSO re-validation.

Login Page Flow

1. Login page.
2. Authentication Providers, for example, LDAP or Local DB.

Let’s take a closer look at the SSO flow, as it is the most commonly used flow.

SSO Flow

Manager uses JSESSIONID secure cookies to track users and it:

• Keeps tracks whether a user is anonymous or authenticated.
• Manages its life cycle until it is expired or invalidated.

Authentication Flow

Any user trying to access secured resources, which are accessible via {form-space-context-path}/secured/ URLs, must be successfully authenticated. If a form space or the Home Dashboard module is configured to use the SSO Security Manager and unauthenticated user attempts to access the Home Dashboard or a secured resource hosted on that form space, Manager performs the following authentication sequence:

1. An unauthenticated user attempts to access a secure URL.
2. Redirects the user to a configured login URL, which can be your identity provider (IDP)An identity provider (IDP) is a system entity that creates, maintains, and manages identity information for principals and also provides authentication services to relying applications within a federation or distributed network. or a login screen.
   1. Captures and stores the entry URL to a resource the user tries to access before the redirect happens.
3. Upon successful user login, the remote IDP redirects the user back to Manager using a configured and allowed URL.
   1. A redirect POST request contains a user's SAML token.
4. Executes the SSO Get Auth Groovy script, configured in the SSO Security Manager, that carries out the following steps:
   1. Validates and parses the SAML token.
   2. Extracts user's info.
   3. Maps Azure AD Groups to Manager's roles and groups.
   4. Constructs a Manager's user account object with details populated from the SAML token. Also, it:
      1. Updates basic user profile info, such as names, contact details, external ID, and so on.
      2. Grants Manager's specific roles and groups as per defined mapping.
   5. Stores the user account record in the Manager's DB as SSO type, which is needed so Manager's form transactions can be linked to the same user permanently across multiple user login sessions.
5. Redirects the user back to the original entry URL that is the resource the user has attempted to access in the first place.

Access Permissions Refresh

Every time a user session is expired or none is present and the user has to go through the authentication process described above, all user details including the claims are synced from the SAML token to Manager's DB. This means that the latest user authentication details stored in the IDP are synced and reflected in Journey Manager.

After the successful SSO login and creation of a valid authenticated user session, Journey Manager handles the rest of user interaction so no other redirections or API calls are needed from Manager to the IDP.

It's important to remember, that the SSO user can't log into the Journey Manager form spaces using any local credentials as none are captured in Manager during the SSO flows.

Authorization

As the user has been authenticated, this (authenticated) user, as per the current JSESSIONID session, has been granted specific Journey Manager claims. They are listed below:

1. Roles
2. Groups
3. Access to form spaces. For the current session, it is the form space the user has attempted to access at first, before SSO login has been established.
4. Access to some organizations. This is checked upon every HTTP request for any secured resources stored on the Journey Manager server.

Optionally, upon user log out request, the SSO Security Manager can be configured with a logout chain redirect URL, where you can redirect the user to an IDP logout page and log the user out from the remote server as well.

SSO User Deactivation

This is a responsibility of the remote IDP. However, for any immediate user account invalidation, while the user's JSESSIONID session is still valid or active, the user can be deactivated using the Home Dashboard manually.

SSO User Deletion

This is a responsibility of the remote IDP to prevent blacklisted or unwanted users from logging into Journey Manager. Manager might have a number of form transactions linked to a user account, therefore, we don't recommend deletion of the SSO user account, if there is one in Manager. However, if needed, Manager user accounts can be deleted using the Home Dashboard manually.

SSO User Profile Management

User profile provisioning and update is automated by the core platform and via the selected configured Security Manager components. Journey Manager, as a platform, uses its own built-in methods to manage the users profiles stored in the DB. This is further controlled by our choice of the Security Manager type, such as the SSO Security Manager.

Further customization and configuration on top of the default SSO Security Manager is usually required, with the following to be done:

1. Configure a REST IDP login external URL where a user is redirected to for authentication.
2. Configure certificates to verify and decrypt SAML tokens. This is an optional task.
3. Map REST Azure AD groups (present in user's SAML token) to Journey Manager pre-configured roles and groups
4. Configure a security manager on the required form spaces and Manager module.

For the authorization sequence, it works as described above with no modifications expected. You can reuse the pre-exising and configured Journey Manager roles and groups that the current (local) REST users are configured with.

Manager controls access to the Manager Dashboard using permissions and organization based filters, whereas access to forms and content on the form space is controlled using groups, permissions, and user account based filtering.