Red Hat Single Sign-On Administration
Abstract
| Goal |
Identify the main components of Red Hat Single Sign-On. |
| Objectives |
|
| Sections |
|
Single Sign-On (SSO) is a mechanism that enables users to authenticate once and then access multiple secured applications without having to re-authenticate each time.
For example, when an organization implements SSO, the employees typically log into their account at the beginning of the working day and then can access all the company's secured applications, such as web mail or the Intranet, without having to provide their authentication credentials again.
The following figure shows that without SSO, users have to authenticate with each application individually. With SSO, users authenticate once, and then can access all the secured applications.
On the internet, some modern web services implement SSO so that users can use their social network account for authentication. This way, users can log in with their social network account and then access multiple web services without having to individually register with each service. The following screen capture shows the login page of an online newspaper. The online newspaper delegates the users authentication to social login providers such as Google, Apple, Facebook, and Amazon. Thus, the users can log in with one of the listed social networks.
 |
- Identity and Access Management (IaM)
SSO relies on an Identity and Access Management (IaM) system for authenticating and authorizing users. IaM systems centrally manage and maintain user accounts, offer authentication services, and define authorization rules to control the access to protected services and applications. In the preceding screen capture, Google, Apple, Facebook, and Amazon act as IaM systems. Organizations can deploy Red Hat Single Sign-On (RH-SSO), which provides several authentication mechanisms for internal users.
- SSO Standards
SSO relies on a standard protocol for the interaction between the user agent, usually a web browser, the secured applications, and the IaM system. Open Authorization 2.0 (OAuth2), OpenID Connect (OIDC), and Security Assertion Markup Language (SAML) are industry standards for SSO in web environments. Kerberos is a standard for non-web applications, such as client/server applications.
- Authentication
Authentication is the process that a user uses to identify themselves to the system. The goal of the process is to prove that the user really is who they claim to be. With a system that relies on passwords for authentication, a person logging in by using a correct username and password is authenticated.
- Authorization
Authorization determines whether or not a user is granted access to a service. Even a correctly authenticated user might be denied access due to other restrictions.
In the context of SSO, some IaM systems store additional user attributes, such as email addresses, user full names, profile photos, or phone numbers. Applications that delegate authentication to an IaM system do not automatically have access to all these attributes. Instead, the IaM system must get the consent, or authorization, from the user to allow the application to access the data.
The following example shows Google asking the user for consent to allow the on-line newspaper application to access the user's data.
The user accesses the web application login page and then selects Google for authentication.
The web application redirects the user's web browser to the Google sign-in page. The user provides the credentials to authenticate with Google.
To operate correctly, the on-line newspaper application needs the user's name, email address, and profile picture. Therefore, Google asks the user for consent to share this personal data with the web application.
- Delegated Authentication and Authorization
With SSO, a secured application that needs to authenticate its users does not perform that authentication itself, but rather delegates it to the IaM system. In return, the application receives a token that confirms that the authentication was successful.
The same goes for authorization: the secured application delegates the operation to the IaM system. With SSO, the IaM system asks the user for consent and the application receives an access token that allows it to retrieve the user's data from the IaM system.
Implementing SSO offers some benefits for end users. Users only have to remember one set of credentials to access all their applications. In addition, they only have to log in once to securely access multiple applications.
Because IaM is the central management tool for all user accounts, compliance and regulation rules are easier to implement. For example, to enforce password strength for all users, you only need to define a password policy at the IaM level. Also, when an employee leaves the company, you revoke access to all the company's applications by removing the account from the IaM system. IaM systems usually provide additional features, such as user activity monitoring.
SSO also improves security because the applications do not have access to all the user details. Because the applications delegate the authentication to the IaM system, they do not directly ask for the username and the password, and therefore do not have access to this information by default. Incidentally, some SSO standards do not specify how the IaM system performs user authentication: the authentication mechanism is left to the IaM system implementation. Some IaM systems perform authentication by username and password. Others support two-factor authentication, X.509 client certificate, or Kerberos ticket validation.
Application developers also benefit from SSO. Instead of implementing authentication mechanisms and user management in their application, usually by storing usernames and passwords inside a local database, developers delegate user management and authentication to the SSO system. Industry standards for SSO provide libraries for the most popular programming languages. Furthermore, RH-SSO comes with adapters, which are specialized libraries, to simplify the development of applications and services.
References
For more information about RH-SSO, refer to the Red Hat Single Sign-On Features and Concepts chapter in the Red Hat Single Sign-On 7.6 Server Administration Guide at https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#red_hat_single_sign_on_features_and_concepts
Authentication and authorization: The key to single sign-on (SSO) workflow