In any large company, and X5 Retail Group is no exception, as it develops, the number of projects that require user authorization increases. Over time, seamless transition of users from one application to another is required, and then there is a need to use a single Single-Sing-On (SSO) server. But what about when identity providers such as AD or others that do not have additional attributes are already used in various projects. A class of systems called "identification brokers" will come to the rescue. The most functional are its representatives, such as Keycloak, Gravitee Access management, etc. Most often, use cases can be different: machine interaction, user participation, etc. The solution must support flexible and scalable functionality that can combine all requirements in one, and such solutions our company now has an indication broker - Keycloak.
Keycloak is an open source identity and access control product maintained by RedHat. It is the basis for the company's products using SSO - RH-SSO.
Basic concepts
Before you begin to deal with solutions and approaches, you should decide in terms and sequence of processes:
Identification is a procedure for recognizing a subject by his identifier (in other words, this is the definition of a name, login or number).
Authentication - this is an authentication procedure (the user is checked with a password, the letter is checked with an electronic signature, etc.)
Authorization - this is the provision of access to a resource (for example, to e-mail).
Identity Broker Keycloak
keycloak is an open source identity and access management solution designed for use in IS where microservice architecture patterns can be used.
Keycloak offers features such as single sign-on (SSO), brokered identity and social login, user federation, client adapters, admin console and account management console.
Basic functionality supported by Keycloak:
- Single-Sign On and Single-Sign Out for browser applications.
- Support for OpenID/OAuth 2.0/SAML.
- Identity Brokering - authentication using external OpenID Connect or SAML identity providers.
- Social Login - Google, GitHub, Facebook, Twitter support for user identification.
- User Federation - synchronization of users from LDAP and Active Directory servers and other identity providers.
- Kerberos bridge - using a Kerberos server for automatic user authentication.
- Admin Console - for unified management of settings and solution options via the Web.
- Account Management Console - for self-management of the user profile.
- Customization of the solution based on the corporate identity of the company.
- 2FA Authentication - TOTP/HOTP support using Google Authenticator or FreeOTP.
- Login Flows - user self-registration, password recovery and reset, and others are possible.
- Session Management - administrators can manage user sessions from a single point.
- Token Mappers - binding user attributes, roles and other required attributes to tokens.
- Flexible policy management across realm, application and users.
- CORS Support - Client adapters have built-in CORS support.
- Service Provider Interfaces (SPI) - A large number of SPIs that allow you to customize various aspects of the server: authentication flows, identity providers, protocol mapping, and more.
- Client adapters for JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Support for working with various applications that support the OpenID Connect Relying Party library or SAML 2.0 Service Provider Library.
- Expandable using plugins.
For CI / CD processes, as well as automation of management processes in Keycloak, the REST API / JAVA API can be used. Documentation is available electronically:
REST API
Java API
Enterprise Identity Providers (On-Premise)
Ability to authenticate users through User Federation services.
Pass-through authentication can also be used - if users authenticate on workstations with Kerberos (LDAP or AD), then they can be automatically authenticated to Keycloak without having to enter their username and password again.
For authentication and further authorization of users, it is possible to use a relational DBMS, which is most applicable for development environments, since it does not involve lengthy settings and integrations at the early stages of projects. By default, Keycloak uses a built-in DBMS to store settings and user data.
The list of supported DBMS is extensive and includes: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle and others. The most tested so far are Oracle 12C Release1 RAC and Galera 3.12 cluster for MariaDB 10.1.19.
Identity providers - social login
It is possible to use a login from social networks. To activate the ability to authenticate users, use the Keycloack admin console. Changes in the application code are not required and this functionality is available out of the box and can be activated at any stage of the project.
It is possible to use OpenID/SAML Identity providers for user authentication.
Typical authorization scenarios using OAuth2 in Keycloak
Authorization Code Flow - used with server-side applications. One of the most common types of authorization permission because it is well suited for server applications where the application's source code and client data are not available to outsiders. The process in this case is based on redirection. The application must be able to interact with a user agent (user-agent), such as a web browser - to receive API authorization codes redirected through the user agent.
implicit flow - used by mobile or web applications (applications running on the user's device).
The implicit authorization permission type is used by mobile and web applications where client confidentiality cannot be guaranteed. The implicit permission type also uses user agent redirection, whereby the access token is passed to the user agent for further use in the application. This makes the token available to the user and other applications on the user's device. This type of authorization permission does not authenticate the identity of the application, and the process itself relies on a redirect URL (previously registered with the service).
Implicit Flow does not support access token refresh tokens.
Client Credentials Grant Flow β are used when the application accesses the API. This type of authorization permission is typically used for server-to-server interactions that must be performed in the background without immediate user interaction. The client credentials grant flow allows a web service (confidential client) to use its own credentials instead of impersonating a user to authenticate when calling another web service. For a higher level of security, it is possible for the calling service to use a certificate (instead of a shared secret) as a credential.
The OAuth2 specification is described in
JWT token and its benefits
JWT (JSON Web Token) is an open standard () that defines a compact and self-contained way to securely transfer information between parties as a JSON object.
According to the standard, the token consists of three parts in base-64 format, separated by dots. The first part is called the header, which contains the type of token and the name of the hash algorithm for obtaining a digital signature. The second part stores the basic information (user, attributes, etc.). The third part is the digital signature.
. .
Never store a token in your DB. Because a valid token is equivalent to a password, storing the token is like storing the password in clear text.
Access token is a token that grants its owner access to secure server resources. It usually has a short lifetime and may carry additional information such as the IP address of the party requesting the token.
Refresh token is a token that allows clients to request new access tokens after their lifetime has expired. These tokens are usually issued for a long period of time.
The main advantages of using in microservice architecture:
- Ability to access various applications and services through one-time authentication.
- In the absence of a number of required attributes in the user profile, it is possible to enrich with data that can be added to the payload, including automated and on-the-fly.
- There is no need to store information about active sessions, the server application only needs to verify the signature.
- More flexible access control through additional attributes in the payload.
- The use of a token signature for the header and payload increases the security of the solution as a whole.
JWT token - composition
Title - by default, the header contains only the type of token and the algorithm used for encryption.
The type of the token is stored in the "typ" key. The 'type' key is ignored in the JWT. If the "typ" key is present, its value must be JWT to indicate that this object is a JSON Web Token.
The second key "alg" defines the algorithm used to encrypt the token. It should be set to HS256 by default. The header is encoded in base64.
{ "alg": "HS256", "type": "JWT"}
payload (content) - the payload stores any information that needs to be checked. Each key in the payload is known as a "claim". For example, you can enter the application only by invitation (closed promo). When we want to invite someone to participate, we send them an invitation letter. It is important to check that the email address belongs to the person who accepts the invitation, so we will include this address in the payload, for this we store it in the "email" key
{ "email": "[email protected]"}
Keys in payload can be arbitrary. However, there are a few reserved:
- iss (Issuer) - Identifies the application from which the token is being sent.
- sub (Subject) - defines the subject of the token.
- aud (Audience) is an array of case-sensitive strings or URIs that is a list of the recipients of this token. When the receiving side receives a JWT with the given key, it must check for the presence of itself in the recipients - otherwise ignore the token.
- exp (Expiration Time) - Indicates when the token expires. The JWT standard requires all its implementations to reject expired tokens. The exp key must be a timestamp in unix format.
- nbf (Not Before) is a time in unix format that determines the moment when the token becomes valid.
- iat (Issued At) - This key represents the time the token was issued and can be used to determine the age of the JWT. The iat key must be a timestamp in unix format.
- Jti (JWT ID) β a string that defines the unique identifier of this token, case-sensitive.
It is important to understand that the payload is not transmitted in encrypted form (although tokens can be nested and it is then possible to transmit encrypted data). Therefore, it cannot store any secret information. Like the header, the payload is base64 encoded.
Signature - when we have a title and payload, we can calculate the signature.
Base64-encoded: header and payload are taken, they are combined into a string through a dot. Then this string and the secret key are input to the encryption algorithm specified in the header ("alg" key). The key can be any string. Longer strings will be most preferred as it will take longer to pick up.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Building a Keycloak Failover Cluster Architecture
When using a single cluster for all projects, there are increased requirements for an SSO solution. When the number of projects is small, these requirements are not so noticeable for all projects, however, with an increase in the number of users and integrations, the requirements for availability and performance increase.
Increasing the risk of single SSO failure increases the requirements for the solution architecture and the methods used for redundant components and leads to a very tight SLA. In this regard, more often during the development or early stages of implementing solutions, projects have their own non-fault-tolerant infrastructure. As development progresses, it is required to lay down opportunities for development and scaling. It is most flexible to build a failover cluster using container virtualization or a hybrid approach.
To work in the Active/Active and Active/Passive cluster modes, it is required to ensure data consistency in a relational database - both database nodes must be synchronously replicated between different geo-distributed data centers.
The simplest example of a fault-tolerant installation.
What are the benefits of using a single cluster:
- High availability and performance.
- Support for operating modes: Active / Active, Active / Passive.
- Ability to dynamically scale - when using container virtualization.
- Possibility of centralized management and monitoring.
- Unified approach for identification/authentication/authorization of users in projects.
- More transparent interaction between different projects without user involvement.
- The ability to reuse the JWT token in various projects.
- Single point of trust.
- Faster launch of projects using microservices/container virtualization (no need to lift and configure additional components).
- It is possible to purchase commercial support from the vendor.
What to Look for When Planning a Cluster
DBMS
Keycloak uses a database management system to store: realms, clients, users, etc.
A wide range of DBMS is supported: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak comes with its own built-in relational database. It is recommended to use for non-loaded environments - such as development environments.
To work in Active/Active and Active/Passive cluster modes, data consistency in a relational database is required, and both database cluster nodes are synchronously replicated between data centers.
Distributed cache (Infinspan)
For the cluster to work correctly, additional synchronization of the following types of caches using the JBoss Data Grid is required:
Authentication sessions - used to save data when authenticating a specific user. Requests from this cache typically only include the browser and the Keycloak server, not the application.
Action tokens are used for scenarios where the user needs to confirm an action asynchronously (via email). For example, during a forget password flow, the actionTokens Infinispan cache is used to keep track of metadata about associated action tokens that have already been used, so it cannot be reused.
Caching and invalidation of persistent data - used to cache persistent data to avoid unnecessary queries to the database. When any Keycloak server updates the data, all other Keycloak servers in all data centers need to know about it.
Work - Only used to send invalid messages between cluster nodes and data centers.
User sessions - used to store data about user sessions that are valid for the duration of the user's browser session. The cache must process HTTP requests from the end user and the application.
Brute force protection - used to track data about failed logins.
Load balancing
The load balancer is the single entry point to keycloak and must support sticky sessions.
Application Servers
They are used to control the interaction of components with each other and can be virtualized or containerized using existing automation tools and dynamic scaling of infrastructure automation tools. The most common deployment scenarios in OpenShift, Kubernates, Rancher.
This concludes the first part - the theoretical one. In the next series of articles, examples of integrations with various identity providers and examples of settings will be analyzed.
Source: habr.com