Reader small image

You're reading from  Keycloak - Identity and Access Management for Modern Applications - Second Edition

Product typeBook
Published inJul 2023
PublisherPackt
ISBN-139781804616444
Edition2nd Edition
Right arrow
Authors (2):
Stian Thorgersen
Stian Thorgersen
author image
Stian Thorgersen

Stian Thorgersen started his career at Arjuna Technologies building a cloud federation platform, years before most companies were even ready for a single-vendor public cloud. He later joined Red Hat, looking for ways to make developers' lives easier, which is where the idea of Keycloak started. In 2013, Stian co-founded the Keycloak project with another developer at Red Hat. Today, Stian is the Keycloak project lead and is also the top contributor to the project. He is still employed by Red Hat as a senior principal software engineer focusing on identity and access management, both for Red Hat and for Red Hat's customers. In his spare time, there is nothing Stian likes more than throwing his bike down the mountains of Norway.
Read more about Stian Thorgersen

Pedro Igor Silva
Pedro Igor Silva
author image
Pedro Igor Silva

Pedro Igor Silva is a proud dad of amazing girls. He started his career back in 2000 at an ISP, where he had his first experiences with open source projects such as FreeBSD and Linux, as well as a Java and J2EE software engineer. Since then, he has worked in different IT companies as a system engineer, system architect, and consultant. Today, Pedro Igor is a principal software engineer at Red Hat and one of the core developers of Keycloak. His main area of interest and study is now IT security, specifically in the application security and identity and access management spaces. In his non-working hours, he takes care of his planted aquariums.
Read more about Pedro Igor Silva

View More author details
Right arrow

Chapter 1

  1. Yes. Keycloak distributes container images for Docker, which runs on Kubernetes. There is also a Kubernetes Operator for Keycloak that makes it easier to install and manage Keycloak on Kubernetes.
  2. The Keycloak admin console provides an extensive console to allow you to configure and manage Keycloak, including managing applications and users.
  3. The Keycloak account console provides a self-service console for end users of your applications to manage their own accounts, including updating their profile and changing their password.

Chapter 2

  1. The application redirects the user to the login pages provided by Keycloak. Following authentication, the user is redirected back to the application and the application obtains an ID token from Keycloak that it can use to discover information about the authenticated user.
  2. For an application to be permitted to authenticate users with Keycloak, it must first be registered as a client with Keycloak.
  3. The application includes an access token in the request, which the backend service can verify to decide whether access should be granted.

Chapter 3

  1. OAuth 2.0 enables an application to obtain an access token that grants access to a set of resources provided by a different application on behalf of the user.
  2. OpenID Connect adds an authentication layer on top of OAuth 2.0.
  3. OAuth 2.0 does not define a standard format for tokens. By leveraging JWT as the token format, applications are able to directly verify and understand the contents of the token.

Chapter 4

  1. Through the Discovery endpoint, an application can find out a lot of useful information about an OpenID Provider, which allows it to automatically configure itself to a specific provider.
  2. The application retrieves an ID token, a signed JWT, from the OpenID Provider, which contains information about the authenticated user.
  3. By adding a protocol mapper, or a client scope, to a client you can control exactly what information is included in the ID token that is made available to an application.

Chapter 5

  1. An application can leverage the OAuth 2.0 Authorization Code grant type to obtain an access token from the authorization server. The application then includes the access token in the request sent to the REST API.
  2. An access token can be limited through the use of the audience, roles, or scopes.
  3. A service can either invoke the token introspection endpoint to verify the access token, or if the token is a JWT, it can verify and read the contents of the token directly.

Chapter 6

  1. As an SPA is running in the browser, it cannot use a confidential client directly, which results in a greater risk if a refresh token is leaked. For this reason, it is more secure to have a backend running in a web server that can use a confidential client and store tokens on the server side.
  2. No, any type of application can use OAuth 2.0 through an external user agent to obtain an access token, and many different types of services have support for bearer tokens.
  3. An application should never collect user credentials directly as this increases the chance of credentials being leaked and provides the application with full access to the user account. For this reason, native and mobile applications should use an external user agent to authenticate with Keycloak.

Chapter 7

  1. In this chapter, you were presented with different integration options for different programming languages and platforms. If the programming language you are using already supports OpenID Connect, even if this is being done through a library or framework, you should consider using it. Alternatively, you can also use a reverse proxy such as Apache HTTP Server.
  2. No, the Keycloak adapters were created when there were not many trusted client libraries. Nowadays, programming languages, and the frameworks built on top of these languages, already provide support for OpenID Connect. As a rule of thumb, do the opposite: only consider using any of the Keycloak adapters if you are left with no other option.
  3. If you are using Reactive Native, you might want to look at https://github.com/FormidableLabs/react-native-app-auth/blob/main/docs/config-examples/keycloak.md. There you should find examples on how to use it with Keycloak. Remember that Keycloak is a fully...

Chapter 8

  1. When you put data into tokens, they actually grow disproportionately in size. One option to help here is to include only the minimum information that your application needs and, for additional information, to use the token introspection endpoint. The drawback is that your application will need an additional request to Keycloak when serving requests. You should also consider disabling the Full Scope Allowed setting in your client settings, so that only information relevant to your client is included in tokens.
  2. Realm roles should be used to represent the user’s role within an organization. These roles have the same semantics regardless of the clients created in a realm. On the other hand, the semantics for a client role are specific to the client they belong to. In this chapter, we created a realm role and a client role using the same name: manager. While the realm role could represent users with the role of manager in an organization, the manager...

Chapter 9

  1. Yes. It is recommended that you have an active-passive or active-active database so that in the event of failures, you can easily switch database instances. Note, however, that Keycloak keeps as much data as possible in caches, where reads should not be impacted at all depending on how hot the caches are (how much data is cached). Writes, however, will fail until the connection is re-established. Keycloak also supports setting some useful configuration options to improve failover in the event of network failures. You might want to enable background validation of connections to make sure available connections are usable, validate connections prior to obtaining them from the connection pool, or even configure the pool to fail fast when a connection is terminated to avoid validating and iterating over all connections in the pool.
  2. No. The default configuration uses IP multicast to broadcast messages across nodes and form a cluster. The proper configuration depends...

Chapter 10

  1. Yes. As we will see in the following chapters, Keycloak provides a Service Provider Interface (SPI) that allows you to integrate not only with databases but with any other form of identity store.
  2. No. In addition to storing information from LDAP in its own database, Keycloak also caches data for entries that have been imported from LDAP. You have complete control over how information is cached and when it expires. Here, together with the synchronization settings, information from the LDAP directory is periodically updated without it impacting the overall performance of the server.
  3. Keycloak allows you to configure mappers for identity providers. Through these mappers, you can customize how users are created by setting a specific user attribute or setting a specific role when the user authenticates for the very first time.

Chapter 11

  1. Keycloak allows you to customize its look and feel entirely, not just for the pages that were presented in this chapter. As we are going to see in Chapter 13Extending Keycloak, you should be able to change the look and feel of pages by changing the different themes provided by Keycloak. You can find more details in the documentation at https://www.keycloak.org/docs/latest/server_development/#_themes.
  2. WebAuthn requires you to use a FIDO or FIDO2 compliant security device. You should also consider accessing Keycloak using HTTPS and using a valid domain name. WebAuthn is strict about domain names and secure connections if the server is accessed from a different domain than the client. You should also make sure the browser you are using has support for the WebAuthn API. You should also consider looking at the demo on the WebAuthn site to check how your security device works there.

Chapter 12

  1. Most of the time, sessions – both user and client – are not stored in the database. As you learnt from Chapter 9, Configuring Keycloak for Production, sessions are stored in-memory and shared across the different cluster nodes. However, there is a specific type of session called an offline session that is stored in the database. For more details about offline sessions, look at the documentation at https://www.keycloak.org/docs/latest/server_admin/#_offline-access.
  2. User sessions hold state about the authenticated user, regardless of the client. On the other hand, client sessions are bound to the client the user authenticated with and they hold the state about the user within the context of a specific client.
  3. Keycloak provides different ways for revoking tokens and expiring sessions. As you learnt from this chapter, tokens can be revoked by invoking the revocation endpoint and the sessions can be destroyed through the administration console...

Chapter 13

  1. In Keycloak’s code base, SPIs are organized into two main modules, the keycloak-server-spi and keycloak-server-spi-private modules. Public SPIs are located in the keycloak-server-spi module and Keycloak does its best to keep their interfaces backward compatible between releases. These SPIs are also usually documented. On the other hand, private SPIs are not supported in terms of backward compatibility and they usually lack documentation. As a rule of thumb, consider first looking at the SPIs available from the documentation, as they are usually what Keycloak expects people to use for extending the server.
  2. In order to deploy your extensions, you must deploy your extension’s JAR file to the $KC_HOME/providers directory and restart the server. If you are using an optimized server image, you should re-run the build command. For more details about running optimized images, look at the documentation at https://www.keycloak.org/server/configuration#_optimize_the_keycloak_startup...

Chapter 14

  1. There is no such thing as perfectly secure software, and mistakes are frequently made. Luckily, both the Keycloak team and its community are continuously looking for vulnerabilities and are continuously fixing any issues they find. If you don’t update Keycloak, you will not receive these fixes, but anyone wanting to attack your Keycloak server will.
  2. Keycloak stores a lot of sensitive data in the database, which is valuable information to an attacker. If an attacker gains write access to the database, the attacker can make changes that could allow the attacker to gain access to any application secured by Keycloak.
  3. No; only relying on a web application firewall is not a good idea. You will want to enable strong authentication, as well as provide a good level of security within the application itself.
lock icon
The rest of the chapter is locked
You have been reading a chapter from
Keycloak - Identity and Access Management for Modern Applications - Second Edition
Published in: Jul 2023Publisher: PacktISBN-13: 9781804616444
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €14.99/month. Cancel anytime

Authors (2)

author image
Stian Thorgersen

Stian Thorgersen started his career at Arjuna Technologies building a cloud federation platform, years before most companies were even ready for a single-vendor public cloud. He later joined Red Hat, looking for ways to make developers' lives easier, which is where the idea of Keycloak started. In 2013, Stian co-founded the Keycloak project with another developer at Red Hat. Today, Stian is the Keycloak project lead and is also the top contributor to the project. He is still employed by Red Hat as a senior principal software engineer focusing on identity and access management, both for Red Hat and for Red Hat's customers. In his spare time, there is nothing Stian likes more than throwing his bike down the mountains of Norway.
Read more about Stian Thorgersen

author image
Pedro Igor Silva

Pedro Igor Silva is a proud dad of amazing girls. He started his career back in 2000 at an ISP, where he had his first experiences with open source projects such as FreeBSD and Linux, as well as a Java and J2EE software engineer. Since then, he has worked in different IT companies as a system engineer, system architect, and consultant. Today, Pedro Igor is a principal software engineer at Red Hat and one of the core developers of Keycloak. His main area of interest and study is now IT security, specifically in the application security and identity and access management spaces. In his non-working hours, he takes care of his planted aquariums.
Read more about Pedro Igor Silva