Bookmark this page

Customize authentication with Red Hat Single Sign-On

Objectives

  • Customize Red Hat Single Sign-On to enhance authentication security in the realm.

Customize Authentication with Red Hat Single Sign-On (RH-SSO)

As stated elsewhere in this course, RH-SSO centralizes the authentication of the users of one or more realms. Thus, you can define common protections and features for the process of authentication, with independence from the SSO standards you use in the realm.

There are two main pages in the RH-SSO Admin Console that are related to the configuration of the authentication: the ConfigureRealm Settings page, and the ConfigureAuthentication page.

You can find information about the different options in the Admin Console by hovering over the question marks.

Overview of RH-SSO Authentication Flows

In RH-SSO, an authentication flow is a set of actions and verifications that RH-SSO performs during a log in, a registration, or any other workflow managed in the realm.

Note

Note that RH-SSO flows are different than the SSO standard flows from OAuth2, OIDC, and SAML.

RH-SSO includes by default different authentication flows. You cannot remove or add steps to the default authentication flows, but you can modify them to suit your requirements. You can also create new authentication flows.

You can access the definition of the RH-SSO authentication flows from ConfigureAuthentication, in the Flows tab. You can navigate through the different authentication flows by using the drop-down menu.

Each RH-SSO authentication flow has one or more authentication types. The following are examples of authentication types:

  • Signed Jwt

  • X509 Certificate

  • Username Password Form

  • Identity Provider Redirector

  • Cookie

  • Kerberos

  • Docker Authenticator

As a general explanation for authentication flows, the Auth Type parameter is the action to execute. If an Auth Type is indented, then it is in a sub-flow and the previous non-indented Auth Type parameter is its parent. RH-SSO executes sub-flows depending on the results from the parent execution.

You can control the authentication action by using a set of radio buttons:

  • Required: RH-SSO must successfully execute all the required authentication actions to evaluate the flow as successful. If one required authentication option fails, then the flow terminates as failed.

  • Alternative: RH-SSO must successfully execute one of the alternative authentication actions to evaluate the flow as successful.

  • Disabled: RH-SSO does not take into account the disabled authentication action.

  • Conditional: A conditional sub-flow contains executions. RH-SSO evaluates these executions as logical statements. If the logical statements evaluate as true, then RH-SSO executes the authentication actions in the sub-flow. If the logical statements evaluate as false, then RH-SSO does not execute the authentication actions in the sub-flow.

RH-SSO defines the following eight built-in flows

  • Http Challenge

  • Docker Auth

  • First Broker Login

  • Clients

  • Reset Credentials

  • Registration

  • Direct Grant

  • Browser

You can hover over the question marks to get more information about each built-in flow.

The following image is the definition of the Browser built-in authentication flow.

Figure 3.25:

The RH-SSO Browser authentication flow.

The Browser flow has four authentication types, which RH-SSO evaluates sequentially.

The first one tests if the browser has an existing identity cookie, because the user could be previously identified.

The Kerberos authentication type is disabled. Thus, the identity provider (IdP) is not going to test if the HTTP header for Kerberos exists.

The third test, the Identity Provider Redirector, determines if the realm has any federated identity provider.

If there are other providers, and the user chooses to authenticate against one of them, then the user browser redirects to the login page of that IdP.

If the previous alternative checks have not succeeded in authenticating the user, then the last authentication type in this flow is the Forms authentication type. The Forms authentication type has two nested authentication types. The nested Username Password Form authentication type is required. Thus, the showing of the form is mandatory, because there were no authentications with the previous tests. The Browser - Conditional OTP authentication type shows another form to enter the OTP password, only if the user has configured OTP as required.

Most of the common use cases are covered by the existing built-in flows, but as an RH-SSO administrator you can create new authentication flows, and configure them to act as the actions by default. You can configure which authentication flows are in use from the ConfigureAuthentication page, in the Bindings tab.

Figure 3.26: The RH-SSO authentication flow bindings.

You can also define the authentication flow at a client level, to apply only to a specific application.

Required Actions

As an RH-SSO administrator, you can configure the realm to perform common actions for all client applications and users. These actions include, among others, configuring the OTP, showing a terms and conditions page, updating the user locale, or updating the password.

Figure 3.27: The list of available required actions for the realm.

You can also mark the required actions as a default action. If you mark an action as a default action, then it is executed for each new user.

You can mark actions as default actions from the ConfigureAuthentication page, in the Required Actions tab.

In the ManageUsers page, you can also define required actions for any specific user.

Improve the Authentication in the Realm

You can apply common security features to the applications that use RH-SSO as their identity and access management (IaM) system. There are authentication features related to password policies and One Time Password (OTP) configuration, related to using Kerberos, or related to using credential types different from the username and password.

The following is a list and descriptions of important features that you can use from the ConfigureRealm Settings. To see the full list of the authentication features refer to the References section.

Login Page Settings

Define common features for applications in the login flows. You can access the login page settings by clicking the Login tab within the ConfigureRealm Settings.

The following is a list of features that you can enable for the login page for all clients, or applications:

  • User registration: Enables user registration of new users. You can configure the policies for user registration, and generate an access token for the registration service, from the Client Registration tab.

  • Forgot password: Enables the link to recover lost passwords in the realm login page.

  • Remember Me: You can allow users to remain logged in between browser restarts while the SSO sessions are valid, by enabling the check box in the realm login page.

  • Verify email: If this option is enabled, then the user must click the link that RH-SSO sent via email to verify the account.

  • Require SSL: You can force the clients to connect with RH-SSO by using a secured HTTPS connection. If you use external request, then only the localhost and the private addresses can access without HTTPS.

Password Policies in the Realm

The RH-SSO password policies can force the users to use stronger passwords, and control the frequency between password updates. You can force users to use a secure password by defining password policies from the ConfigureAuthentication page, within the Password Policy tab.

There are no password policies applied by default. Red Hat recommends establishing a set of password policies when you create a new realm. Note that if you federate an LDAP identity provider, then there could be other password policies coming from the federated provider.

The name of each password policy describes its functionality.

Figure 3.28: The list of available password policies for the realm.

You can divide password policies into three types:

  • Policies that specify the format of the passwords.

  • Policies that specify parameters for hashing the passwords.

  • The Expire Password policy, which specifies the frequency of updating the passwords.

Some password policies require parameters that you can fill from the table in the Password Policy tab.

Note

To see the full description for each password policy, refer to the Password policies types section from the RH-SSO Server Administration Guide, at https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#password_policy_types

The SSO Sessions and the Token Lifespan

RH-SSO manages the concept of Single Sign-On sessions to determine if the users are authenticated and authorized, how long the authentication and authorization are valid, which scopes and clients are authorized for the user, or if the user needs to authenticate again.

From a security point of view, the SSO session helps to control the user activity, and the validity of the tokens.

Red Hat recommends you maintain the SSO session lifetime as short as possible. If an SSO session expires, then all its related tokens lose their validity. By using a short value for the SSO session lifetime, you reduce the impact of session or token hijack attacks.

Furthermore, the SSO sessions are stored in the shared caches, in the RH-SSO instances, and they have a direct impact on memory consumption.

The main parameters for SSO sessions management are the SSO Session Idle, and the SSO Session Max parameters. Their default value is ten minutes for SSO Session Idle, and ten hours for SSO Session Max. You can access these parameters from the ConfigureRealm Settings menu, in the Tokens tab.

The tokens that RH-SSO emits for the clients have their own claims about the expiration time. The JWT format allows the applications to validate the token without requesting data to the identity provider. Thus, if an SSO session expires, then the applications could continue accepting an access or identity token. Red Hat recommends to maintain the access token lifespan as short as possible. You can access the Access Token Lifespan parameter from the ConfigureRealm Settings menu, in the Tokens tab. Its default value is 1 minute, and it is also applied to calculate the expiration of the ID token.

References

For more information about configuring the authentication, refer to the Configuring authentication chapter from the Server Administration Guide from the Red Hat Single Sign-On documentation https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#configuring-authentication_server_administration_guide

For more information about the management of sessions, refer to the Managing user sessions chapter from the Server Administration Guide from the Red Hat Single Sign-On documentation https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#managing_user_sessions

For more information about mitigating security risks by using RH-SSO, refer to the Mitigating security threats chapter from the Server Administration Guide from the Red Hat Single Sign-On documentation https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#mitigating_security_threats

Revision: do313-7.6-bc10333