Authorization Strategies

In the previous chapter, you learned about the options for integrating with Keycloak using different programming languages, frameworks, and libraries. You learned how to obtain tokens from Keycloak and use these tokens to authenticate users.

This chapter will focus on the different authorization strategies you can choose from and how to leverage them to enable authorization for your applications using different access control mechanisms such as role-based access control (RBAC), group-based access control (GBAC), OAuth2 scopes, and attribute-based access control (ABAC), as well as learning how to leverage Keycloak as a centralized authorization server to externalize authorization from your applications. You will also learn about the differences between these options and how to choose the best strategy for you.

By the end of this chapter, you will have a good understanding of how you can leverage Keycloak authorization capabilities and choose the right...

Understanding authorization

Any authorization system will try to help you to answer the question of whether a user can access a resource and perform actions on it.

The answer to this question usually involves questions such as the following:

• Who is the user?
• What data is associated with the user?
• What are the constraints for accessing the resource?

By getting the answers to these three questions, we can then decide if access should be granted based on the data associated with the user and the constraints that govern access to the resource.

As an identity provider, Keycloak issues tokens to your applications. As such, applications should expect authorization data from these tokens. Tokens issued by Keycloak carry information about the user and the context in which the user was authenticated; the context may contain information about the client the user is using or any other information gathered during the authentication process.

The constraints...

Using RBAC

Probably one of the most-used access control mechanisms, RBAC allows you to protect resources depending on whether the user is granted a role. As you learned in previous chapters, Keycloak has built-in support for managing roles, as well as for propagating those roles to your applications using tokens.

Roles usually represent a role a user has in either your organization or in the context of your application. As an example, users can be granted an administrator role to indicate they act as someone allowed to access and perform actions on any resource in your application. Or, they can be granted a people-manager role to indicate that they act as someone allowed to access and perform actions on resources related to their subordinates.

As you learned from previous chapters, Keycloak has two categories of roles: realm and client roles. Roles defined at the realm level are called realm roles. These roles usually represent the user’s role within an organization...

Using GBAC

Keycloak allows you to manage groups for your realms. Users are put into groups to represent their relationship with a specific business unit in your organization (mapping your organization tree) or just grouped together according to their role in your applications, such as when you want to have a specific group for users that can perform administrative operations.

Usually, groups and roles are used interchangeably, and this causes some confusion when defining a permission model. In Keycloak, there is a clear separation between these two concepts where, different from roles, groups are meant to organize your users and grant permissions according to the roles associated with a group.

By allowing assigning roles to groups, Keycloak makes it a lot easier to manage roles for multiple users without forcing you to grant and revoke roles for each individual user in your realm.

Groups in Keycloak are hierarchical, and when tokens are issued, you can traverse the hierarchy...

Using OAuth2 scopes

At its core, Keycloak is an OAuth2 authorization server. In pure OAuth2, there are two main types of applications: clients and resource servers.

As you learned from previous chapters about OAuth2, access tokens are issued to clients so that they can act on behalf of a user, where these tokens are limited to a set of scopes based on the user’s consent.

On the other hand, resource servers are the consumers of access tokens, which they need to introspect to decide whether the client can access a protected resource on the resource server accordingly to the scopes granted by the user.

As you can see, authorization using OAuth2 scopes is solely based on user consent. It is the best strategy when you want third parties integrating with your APIs so that you delegate to your users the decision on whether a third-party application can access their resources. In this strategy, the main point is to protect user information rather than regular resources...

Using ABAC

When users authenticate through Keycloak, tokens issued by the server contain important information about the authentication context. Tokens contain information about the authenticated user and the client to which tokens were issued, as well as any other information that can be gathered during the authentication process. With that in mind, any information carried by a token can be used to authorize access to your applications. They are just claims mapped to tokens.

ABAC involves using the different attributes associated with an identity (represented by a token), as well as information about the authentication context, to enforce access to resources. It is probably the most flexible access control mechanism you can choose, with natural support for fine-grained authorization. Together with token-based authorization, applications using Keycloak can easily enable ABAC to protect their resources.

Token-based authorization is based on introspecting tokens and using the...

Using Keycloak as a centralized authorization server

So far, you have been presented with authorization strategies that rely on a specific access control mechanism. Except for ABAC, these strategies rely on a specific set of data about the user to enforce access to applications. In addition to that, these strategies are tightly coupled with your applications; changes to your security requirements would require changes in your application code.

As an example, suppose you have the following pseudo-code in your application:

If (User.hasRole("manager") {
     // can access the protected resource
}

In the preceding code, we have a quite simple check using RBAC where only users granted a manager role can access a protected resource. What would happen if your requirements changed and you also needed to give access to that same resource to a specific user? Or even grant access to that resource for users granted some other role? Or perhaps leverage ABAC to look at the...

Summary

In this chapter, you learned about the different strategies you can choose from to authorize access to protected resources in your applications. By leveraging token-based authorization, applications should be able to introspect tokens – either locally or through the introspection endpoint – and use their claims to support different access control mechanisms, such as RBAC, GBAC, and ABAC, or use the scopes granted by users to the client application acting on their behalf.

You also learned that Keycloak can be used as a centralized authorization service to decouple authorization from applications, where access decisions are taken by Keycloak based on the resources and policies managed through the server.

In the next chapter, we are going to look at the main steps for running Keycloak in production.

Questions

1. How do you prevent tokens from becoming too big while still providing the necessary data to enforce access to resources at the application level?
2. How do you decide whether a role should be a realm or client role?
3. Is it possible to enforce access based on information gathered during authentication?
4. Is it possible to change how Keycloak maps roles to tokens?
5. Are the preceding two strategies mutually exclusive?

Further reading

For more information on the topics covered in this chapter, refer to the following links:

• Keycloak roles: https://www.keycloak.org/docs/latest/server_admin/#roles
• Keycloak groups: https://www.keycloak.org/docs/latest/server_admin/#groups
• Keycloak protocol mappers: https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers
• Keycloak client scopes: https://www.keycloak.org/docs/latest/server_admin/#_client_scopes
• Keycloak Authorization Services: https://www.keycloak.org/docs/latest/authorization_services

Join our community on Discord

Join our community’s Discord space for discussions with the authors and other readers:

https://packt.link/SecNet