Red Hat Single Sign-On Administration

Bookmark this page
P123456
PreviousNext

Chapter 4.  Identity Brokering and User Federation

Section Federating Users with Red Hat Single Sign-On
SectionObjectives
SectionUser Federation
SectionLDAP Mappers
Guided Exercise: Federating Users with Red Hat Single Sign-On
Integrating Social Login with Red Hat Single Sign-On
Objectives
Identity Brokering
Create and Configure an Identity Provider
First Broker Login Authentication Flow
Guided Exercise: Integrating Social Login with Red Hat Single Sign-On
Lab: Identity Brokering and User Federation
Summary

Abstract

Goal

Configure RH-SSO to secure applications from multiple identity providers, by using user federation and social logins.

Objectives

  • Configure RH-SSO to secure applications from multiple identity providers, by using user federation and social logins.

Sections

  • Federating Users with Red Hat Single Sign-On  (and Guided Exercise)

  • Integrating Social Login with Red Hat Single Sign-On  (and Guided Exercise)

Lab

  • Identity Brokering and User Federation

Federating Users with Red Hat Single Sign-On

Objectives

  • Federating user identities from LDAP servers.

User Federation

RH-SSO stores users in its local database and manages them. However, you can also point RH-SSO to validate credentials from external stores. This is called user federation.

RH-SSO can federate multiple external databases containing users. The most common external databases containing users use the Lightweight Directory Access Protocol (LDAP). For example, Microsoft Active Directory (AD), or Red Hat Directory Server. By default, RH-SSO includes an LDAP and AD provider. You can also point RH-SSO to validate credentials from custom external databases. RH-SSO provides an API for creating custom plug-ins for user federation called the User Storage service provider interface (SPI).

Note

Configuring custom external databases by using the User Storage SPI is out of the scope of this course.

For more information about how to use the User Storage SPI to configure custom external databases, refer to the User Storage SPI section in the Server Developer Guide documentation at https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_developer_guide/index#user-storage-spi

RH-SSO Users Lookup

When a user tries to log in, RH-SSO does the following:

  • RH-SSO searches for the user in the users' cache.

  • If the user is not present in the users' cache, then RH-SSO searches for the user in the local database.

  • If the user is not present in the local database, then RH-SSO loops through the User Storage SPI provider implementations to perform the user query until one of them returns the user. You can modify the order that RH-SSO uses when looping through the user storage providers by setting the priority parameter.

When federating external databases containing users, RH-SSO maintains its own identity relational database. RH-SSO always imports users from external providers to its own local storage.

The amount of metadata that RH-SSO imports from the external user databases depends on the underlying federation plug-in. You can configure RH-SSO to only import the username or to import more data such as the email, the address, or the phone number. You can also configure RH-SSO to import the credentials to the local storage.

If you federate an LDAP server, then RH-SSO maps the username, email, first name, and last name for the user by default. You can also map other LDAP user attributes into the RH-SSO common user model by using mappers.

Note that RH-SSO never imports passwords to its local database. The user password validation always occurs on the LDAP server. However, you can modify the user password in RH-SSO so it synchronizes to LDAP.

Create and Configure a User Federation Provider

You can create and configure a user federation provider by using the RH-SSO Admin Console. Navigate to the RH-SSO Admin Console and click Configure → User Federation.

Figure 4.1: User Federation creation screen

From the drop-down menu, you can select between ldap and kerberos. RH-SSO supports log in with a Kerberos ticket through the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) protocol. Most of the LDAP servers contain also a kerberos key distribution center (KDC). You can configure the LDAP federation provider to allow authentication from the Kerberos ticket emitted by the KDC in the Kerberos Integration menu. If your Kerberos solution is not backed up by an LDAP server, then use the kerberos type for the user federation provider.

The following list shows some of the configuration options for an LDAP user federation provider:

  • Console Display Name: Sets the name for the LDAP user federation provider.

  • Priority: The priority of the provider when RH-SSO is looking for users. Higher priority for lower numbers.

  • Sync Registrations: Enable it to add to LDAP the new users created by RH-SSO.

  • Allow Kerberos authentication: Enable Kerberos authentication in the realm with user data provisioned from LDAP.

  • Vendor: Select between the Active Directory and Red Hat Directory Server.

  • Connection URL: The URL for your LDAP server.

  • User Object Classes: LDAP objectClass attributes divided by the comma character. RH-SSO only finds user records in LDAP if they contain all the user object classes. You can find the user object classes by using the ldapsearch command.

Figure 4.2: User Federation Provider configuration screen

You can configure the LDAP user federation provider to work on three different edition modes:

  • READ_ONLY: You cannot change the user attributes in RH-SSO. If you try to edit the attributes for a user, then RH-SSO shows an error.

  • WRITABLE: You can modify the user attributes and RH-SSO automatically synchronizes the changes to the LDAP store. You can also update the password for the user.

  • UNSYNCED: You can modify the user attributes and RH-SSO stores them locally in its own local storage. However, RH-SSO does not synchronize the changes to the LDAP store.

You must also configure how RH-SSO maps the LDAP attributes to RH-SSO attributes. You must fill the following LDAP attributes to be mapped to RH-SSO:

  • Username LDAP attribute: The name of the LDAP attribute that RH-SSO maps as the username.

  • RDN LDAP attribute: The name of the LDAP attribute that RH-SSO maps as the relative distinguished name (RDN).

  • UUID LDAP attribute: The name of the LDAP attribute that RH-SSO maps as the unique object identifier (UUID).

You need to specify the full distinguished name (DN) for the users, and for the admin user. In the RH-SSO user federation provider configuration screen, you must fill the following LDAP user federation provider configuration options:

  • Users DN: The full DN for the LDAP tree where the users are.

  • Bind DN: The full DN for the LDAP admin user. RH-SSO uses this DN to access the LDAP server.

  • Bind Credential: The password for the LDAP admin user.

If you want RH-SSO to automatically synchronize users with LDAP, then you can configure it in the Sync Settings menu. There are two types of synchronization. By default, both synchronization types are disabled.

  • Periodic Full Sync: If you change the user attributes in LDAP for those LDAP users that exist in RH-SSO, then RH-SSO automatically updates their attributes in its local storage.

  • Periodic Changed Users Sync: RH-SSO only updates or imports the LDAP users that are updated or created after the last synchronization.

After you configure and save your LDAP user storage provider, you can synchronize all the LDAP users or only those users updated or created after the last synchronization. However, as the LDAP directory might have many users, you do not always want to synchronize the entire LDAP directory to RH-SSO. RH-SSO always imports the LDAP users during their first connection, or when you explicitly look for them in the console. Thus, you do not need to import the entire LDAP directory to RH-SSO. RH-SSO gradually imports the LDAP users as they connect.

LDAP Mappers

RH-SSO maps by default the username, email, first name, and last name LDAP user attributes into the RH-SSO user attributes. However, you might need to import other LDAP user attributes into the RH-SSO user attributes. For this purpose, you can use mappers.

LDAP mappers are listeners triggered by the LDAP provider, which synchronize user attributes between LDAP and RH-SSO. LDAP mappers trigger when users log in by using LDAP, users initially register in LDAP, or RH-SSO queries a user.

RH-SSO automatically provides a set of mappers for the username, email, first name, and last name when you create an LDAP Federation provider. You can modify or remove this set of default mappers and create new ones for the LDAP user federation provider in the Mappers tab. When you create a mapper, you must provide a name and type for the mapper.

The most important mapper types are summarized as follows:

  • user-attribute-ldap-mapper: The user attribute mapper maps a LDAP user attribute to an RH-SSO user attribute. You must provide both the names for the LDAP and RH-SSO user attributes. For example, you can configure the user attribute mapper to map the givenname LDAP user attribute to the firstName RH-SSO user attribute.

  • role-ldap-mapper: Use the role mapper to map LDAP roles to RH-SSO realm or client roles. LDAP roles usually refer to groups from a particular branch of the LDAP tree. You can configure different role mappers for the same LDAP provider. For example, you can create a role mapper to specify that LDAP groups under the DN ou=main,dc=example,dc=com map to RH-SSO realm roles and that LDAP groups under the DN ou=marketing,dc=example,dc=com map to the client roles of the marketing client.

  • group-ldap-mapper: Use the group mapper to map LDAP groups to RH-SSO user groups.

References

For more information about LDAP, refer to https://learn.spidernet.pl/en/topics/security/what-is-ldap-authentication

For more information about setting up RH-SSO user federation providers, refer to the Using external storage section in the Server Administration Guide documentation at https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#user-storage-federation

For more information about Kerberos authentication in RH-SSO, refer to the Kerberos section in the Server Administration Guide documentation at https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#kerberos

For more information about RH-SSO user federation provider mappers, refer to the LDAP mappers section in the Server Administration Guide documentation at https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#ldap_mappers

PreviousNext
Revision: do313-7.6-bc10333