Integrated Keycloak for authentication and authorization

Introduction

Keycloak is an open source identity and access management solution primarily targeted at applications and services. You can authenticate with Keycloak on behalf of individual applications. Therefore, the application does not need to process the login form, authenticate the user, or save the user.

Keycloak offers features such as Multiple Protocols Support, Single-Sign-On (SSO), Identity Brokering and Social Login, User Federation, Client Adapters, an Admin Console, and an Account Management Console.


There are 2 main components of Keycloak:

  • Keycloak server, including the API and graphical interface.

  • Keycloak application adapter: a set of libraries to call the server

 

 

Overview

Keycloak is an open-source tool that will make securing your application easier. It is a tool for Identity and Access Management. The core benefits of this tool is the easy-to-use interface. Besides, the keycloak features is also associated with a single sign in options, that provides an seamless process for all the applications. Once you log in to Keycloak, users don't have to log in again to access another application. The same applies to deregistration. Keycloak provides everything you need for advanced user management tools, not only system security, social login, mobile app support, integration with other solutions, but also all logins and all systems without logging in. Keycloak also has LDAP and Active Directory implementations. Sapper offers different components , therefore we wanted to provide a single login feature's. This attribute is required for logged in for the various Sapper components including Virtual assistant, slack, teams etc. To ensure a single login process for these component Keycloak is found to be the most effective one. Keycloack is also capable for configuring external SSO, and IDP.

Purpose

In Sapper, we are looking for Single Sign-On. We want to use single login & authorization for Sapper, Sapper Virtual Assistant & while embedding sapper into other platforms. It helps to ensure a secure and error free way to conduct the sign-on process for the multiple application.

Key points

  • Single Sign-On (SSO) - This is a technical term used to handle application login through a single server. 

  • Tenant – Single isolated environment for each Sapper customer. 

  • Realm -  A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control. 

Scope

We will have the following points in the scope while doing this SSO integration -  

  1.  Keycloak integration 

  2.  Each tenant will have a separate realm 

  3. Each application, has a separate Client configuration (eg. Sapper, Virtual Assistant, Embedding, etc).

  4. Users log out of one application and then log out from all applications. By default, you will be logged out of Keycloak. 

  5. Configuration SQL for Keycloak. 

  6. Save the required user information in Sapper & synchronize it with various events. 

  7. Sapper tenant Admin can configure SSO/IDP/LDAP and update the tenant password policy.  

Feature's of Keycloak

Multiple Protocols Support

Keycloak supports a variety of protocols such as openID Connect, OAuth 2.0 and SAML 2.0. Keycloak supports both OpenID Connect (an extension of OAuth 2.0) and SAML 2.0. When backing up clients and services, you first need to decide which of the two to use. Depending on your needs, some are protected by OpenID Connect and some are protected by SAML. You also need an adapter or library for the protocol of your choice to protect your clients and services. Keycloak comes with its own adapter for the platform of your choice, but you can also use the generic OpenID Connect Relying Party and SAML service provider libraries.

OpenID Connect and OAuth 2.0

OpenID Connect (OIDC) is an authentication protocol that is an extension of OAuth 2.0. OAuth 2.0 is just a framework for creating authorization protocols, mostly incomplete, but OIDC is a full-fledged authentication and authorization protocol. OIDC also makes extensive use of the Json Web Token (JWT) standard. These standards define JSON-formatted identity tokens and how this data can be digitally signed and encrypted in a compact, web-friendly way. There are actually two types of use cases when using the OIDC. The first is an application that requires the Keycloak server to authenticate the user. Upon successful login, the application will receive an ID token and an access token. The ID token contains information about the user, such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (such as user role mapping) that the application can use to determine which resources the application is allowed to access. Keycloak authenticates the user and then asks for consent to grant access to the requesting client. The client then receives an access token. This access token is digitally signed by the realm. Clients can use this access token to make REST calls to remote services. The REST service extracts the access token, verifies the token's signature, and then decides whether to process the request based on the access information in the token.

SAML 2.0

SAML 2.0 is a specification similar to OIDC, but much older and more mature. Its roots are in SOAP and numerous WS specifications, so it tends to be a bit more verbose than OIDC. SAML 2.0 is an authentication protocol that works primarily by exchanging XML documents between the authentication server and the application. XML signatures and encryption are used to validate requests and responses. In Keycloak, SAML provides two types of use cases: browser applications and REST calls. There are actually two types of use cases when using SAML. The first is an application that requires the Keycloak server to authenticate the user. Upon successful login, the application receives an XML document containing so-called SAML assertions that specify various attributes about the user. This XML document is digitally signed by the realm and contains access information (such as user role mapping) that the application can use to determine which resources the application is allowed access to.

SSO

Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials. Keycloak has full support for Single Sign-On and Single Sign-Out. SSO works on the basis of an established trust relationship between an application called a service provider and an identity provider such as OneLogin. This trust relationship is often based on the certificate exchanged between the identity provider and the service provider. You can use this certificate to sign the identity information that your identity provider sends to your service provider so that you know that your service provider is from a trusted source. For SSO, this ID data is in the form of a token that contains identifying information about the user, such as the user's email address and user name.

Admin Console

Keycloak provides a web-based GUI that allows you to "click out" all the configurations your instance needs to function as intended. The Keycloak Management Console provides administrators and developers with a rich and easy-to-use interface for configuring and managing Keycloak. To access the management console, open http://localhost:8080/auth/admin/ it in your browser. You will be redirected to the Keycloak login page where you can log in with the administrator username and password you created in the previous section during the Keycloak installation.

User Identity and Accesses

Keycloak can be used as a standalone user ID and access manager by allowing you to create a user database with custom roles and groups. This information can be further used to authenticate users within the application and protect parts of the application based on predefined roles. Keycloak is an open source identity and access management solution for modern applications and services. Keycloak provides a customizable user interface and supports use cases such as single sign-on (SSO), user registration, and user federation.

External Identity Source Sync

If you currently have a user database, you can use Keycloak to synchronize with such a database. By default, it supports LDAP and Active Directory, but you can use the Keycloak User Storage API to create custom extensions for each user database. Keep in mind that such a solution may not contain all the data that Keycloak needs to be fully functional. So don't forget to make sure that the features you need are working.

Identity Brokering

Keycloak also acts as a proxy between you and some external identity providers or vendors. You can edit the list in the Keycloak administration panel. Identity brokers are intermediary services that connect multiple service providers to different identity providers. As an intermediary service, identity brokers are responsible for establishing a trust relationship with an external identity provider and using that identity to access internal services exposed by the service provider.

Social Identity Providers

In addition, Keycloak allows you to use social identity providers. The social identity provided is a person's social media account. It has built-in support for Google, Twitter, Facebook and Stack Overflow, but all have to be manually configured from the admin panel. A complete list of supported social identity providers and their configuration guides can be found in the Keycloak documentation. Keycloak can be configured to delegate authentication to one or more IDPs. Social login via Facebook or Google+ is an example of identity provider federation.

Pages Customization

Keycloak lets you customize all pages displayed by it to your users. Those pages are in .ftl format so you can use classic HTML  markups and CSS styles to make the page fit your  application style and your company brand. You can even put custom JS scripts as part of pages customization so possibilities are limitless.


How to configure Keycloak

Sapper will drive all login flow through Keycloak. It will be responsible for authentication, session management, external SSO/IDP configuration & login, user management, role management etc.  

  1. Email: If the person does not recognize the tenant's URL at login time, Sapper should be able to find the person's tenant and redirect them to the correct Keycloak realm for login.

  2. Name: In most places, you may need to display your personal information in the table. To do this, you need to keep that person's call within the SapperDB / backend.

  3. Unique userId: Keycloak's person ID, which determines people and executed motion, using a person with the actual person (mapping).

  1. After signing up for Sapper Access, store your user information in the MongoDB user collection field. Also, there will have a pending user subscriptions.

  2. This will send an email to the Sapper CS team & also send one email to the user. 

  3. The Sapper CS team can approve or reject a user's login request through the user interface (UI).

  4. If approved by the Sapper CS team, Sapper system users will create a realm in Keycloak. Client application in the login process area. Create a user with keycloak. Also, basic settings for the Keycloak realm. Roles, policies, etc.  

  5. Users will receive an email with their username and password.

  6. Internally, the system / sapper has a collection for storing client details and realm details in the sapper. This will be needed later to identify / call the internal Keycloak API for this tenant from the Sapper backend.

  7. Here, each tenant of Sapper has a realm in Keycloak. The realm is compatible with Keycloak tenants.

  1. If the Sapper tenant is deactivated, disabled, or access is revoked due to the trial period expired, the system internally disables the scope. Users in that tenant will not be able to log in later.

  1. Users either click a link in the email or go directly to the Sapper URL (eg. Sapper). 

  2. Users can display an input box and enter their email ID.

  3. When you enters the email, the Sapper API finds the user's tenant and sends back the keycloak login URL with the realm.

  4. The user also has the option of specifying a domain name. It depends on the domain system to find the realm and direct the user to Keycloak to log in. This is required if Sapper & Keycloak does not have user credentials and the user logs in for the first time.

  5. The browser will automatically redirect the user to Keycloak for the log in purpose.

  6. Users can provide credentials. If login is enabled, you will be redirected to Sapper and will automatically log in to Sapper.

(If an external SSO / IDP is configured, the user will be redirected to the external SSO for login. After login, the user will always be created in the Keycloak realm).

  1. If the user is already signed in to Keycloak, they do not need to provide their credentials. He will automatically log in to Sapper.

  2. Currently, users can only join one tenant. We will use the email ID as a unique identifier here.

  3. After changing / resetting the password, Sapper redirects the user to Keycloak. This only works if Keycloak is an identity provider. This will not work if the user has already configured IDP with keycloak. This is also true if you forget your password.

  1. System keycloak has default role settings.

  2. The Sapper API allows access to a defined set of roles.

  3. In the first version, permissions are handled at the role level.