Challenge to Implementing "Scalable" Authorization with Keycloak

© Hitachi, Ltd. 2023. All rights reserved.
Challenge to Implementing “Scalable”
Authorization with Keycloak
KUBECON + CLOUDNATIVECON NA 2023
Hitachi, Ltd.
OSS Solution Center
11/07/2023
Yoshiyuki Tabata

1
About the speaker
• Specialist in API authorization
 Consulting for API management infrastructure and authentication/authorization systems in the financial,
public, social, and industrial fields
• Contributor to OSS related to authentication, authorization, and API management
 Keycloak (IAM OSS)
 3scale (API management OSS)
• Other activities
 Speaker at events such as Apidays, API Specifications Conference, OAuth Security Workshop, etc.
 Author of Keycloak books (Japanese) and writer of web articles about IAM (Japanese)
Yoshiyuki Tabata
 Senior OSS Consultant
 Hitachi, Ltd.
 GitHub: @y-tabata
 CNCF Ambassador

1. Importance of Authorization
2. What is "Scalable" Authorization
3. How to Implement Scalable Authorization with Keycloak
Contents
2
4. Advanced Challenge with OPA and CockroachDB

Contents
3

4
What is Authorization
• Authorization is different from Authentication.
• Authentication is the process of verifying an entity's identity.
• Authenticated does not mean Authorized to access all resources.
• Authentication is not always required for accessing resources, there are
public resources that can be accessed without Authentication.
Authorization is the process of verifying that a requested action or
service is approved for a specific entity. (according to NIST Glossary)

5
Authorization in OWASP Top 10 API Security Risks
Three of the top 5 security risks include the word "Authorization".
* OWASP Top 10 API Security Risks - 2023 https://owasp.org/API-Security/editions/2023/en/0x11-t10/
#1 Broken Object Level
Authorization
#3 Broken Object Property
Level Authorization
#5 Broken Function Level
Authorization
#2 Broken Authentication
#6 Unrestricted Access to
Sensitive Business Flows
#8 Security
Misconfiguration
#4 Unrestricted Resource
Consumption
#7 Server Side Request
Forgery
#9 Improper Inventory
Management
#10 Unsafe
Consumption of APIs

6
Authorization in OWASP Top 10 API Security Risks
There are various levels of Authorization.
#1 Broken Object Level Authorization
Must not allow user 101 to obtain user 102's
resources.
#3 Broken Object Property Level
Authorization
Must not allow a general user to change
sensitive object properties like "rank".
#5 Broken Function Level Authorization
Must not allow a general user to call
administrator function.
User 101
GET /users/102
PUT /users/101
{"rank": "gold"}
GET /admin/users/all

Contents
7

8
The Simplest Authorization Implementation
The simplest authorization implementation is implementing it in
application logic.
User
GET /resources/{resourceId} if (user.isAdmin()) {
// can access the protected resource
}

9
The Simplest Authorization Implementation
The simplest authorization implementation is implementing it in
application logic.
User
GET /resources/{resourceId} if (user.isAdmin() || (user.isFullTime()
&& user.isOwner(resource)) ||
group.isResourceManagement() || …) {
}
-> But, as the service grows, the authorization logic quickly gets difficult. Duplicate
implementations are required in multiple places in the application logic for multiple
services.
-> Low scalability...

10
Role Hierarchy Management
There is an approach to ensure scalability by managing roles in a
hierarchical structure.
resource service
Resource
User
User Layer's
Role
Resource Layer's
Role
User 101 User 102
manag
er
director
membe
r
full time
perman
ent
adminis
tration
develo
per
admin user
resource service
role
position
role
employment
status role
department
role

11
There is an approach to ensure scalability by managing roles in a
hierarchical structure.
User
GET /resources/{resourceId} if (user.hasRole("resource-
service.admin")) {
}
-> Even if the authorization conditions change later, the change will be absorbed by
the role hierarchy, reducing the impact on application logic.
-> High scalability?

12
As the service grows, the number of roles increases and there is a
risk of "Role Explosion".
resource service xxx service yyy service
Resource
User
User Layer's
Role
Resource Layer's
Role
User 101 User 102 User 103
manag
er
chief
director
membe
r
full time
perman
ent
adminis
tration
sales
develo
per
admin user admin user admin user
resource service
role
xxx service
role
yyy service
role
position role
employment
status role
department
role

13
Furthermore, to authorize users by these roles, multiple services
may need to store duplicate role data.
-> In the end, low scalability…
User
GET /xxx
PUT /yyy
POST /zzz
xxx service
yyy service
zzz service

14
Ideal Scalable Authorization
User
GET /xxx
PUT /yyy
POST /zzz
xxx service
yyy service
zzz service
if (user.can($http_method, $uri)) {
}
To use the same application logic for multiple services and to
eliminate duplicate data as much as possible.
-> Separate authorization from app logic and Centralize authorization data.

Contents
15

16
How to Separate Authorization from Application Logic
To separate authorization from application logic, implementing
authorization logic from scratch or using an external authorization
service is necessary.
• From scratch: If simple-purpose, from scratch, is better. However, it is difficult to
achieve fine-grained authorization.
• External service: Many services allow to definition of general-purpose policies to
achieve fine-grained authorization. However, the more general-purpose policy
definitions are made possible, the higher the learning costs for defining policies tend
to be.
• Here, I will introduce Keycloak's authorization service as a just-right-purpose
authorization service.
• Based on ABAC architecture, act as PDP.
• Configure using GUI ( i.e. Low-code/No-code).

17
Major features
 Supporting standards. ex. OAuth 2.0, OpenID
Connect 1.0, SAML v2, …
 Connect to existing user stores. ex. LDAP,
Active Directory, …
 Login with social networks.
 Policy-based authorization service.
What is Keycloak
• Keycloak is IAM (Identity and Access Management) OSS.
• Keycloak provides OAuth 2.0 authorization server feature and single sign-on.
• Keycloak became a CNCF incubating project this April.
Supporting Standard Protocols
Keycloak
LDAP
Active
Directory
RDB
OpenID Connect 1.0
SAML v2
GitHub
Twitter Facebook
Identity Management
Social Login
OAuth 2.0

18
Keycloak's Authorization Service
User
GET /xxx
xxx service
Keycloak
PEP
PDP
delegate
authorization
authorization
decision
Keycloak enables fine-grained authorization by Resource, Scope,
Policy, and Permission management.
• Resource: the protected resource
• Scope: action that can be performed on
resources
• Policy: condition that must be satisfied to
access or perform operations
• Permission: coupling the policy with the
protected resources and scopes

19
Scalable Authorization w/ Keycloak's Authorization Service
User
GET /xxx
xxx service
Keycloak
PEP
PDP
delegate
authorization
authorization
decision
if (user.can($http_method, $uri)) {
}
Delegating authorization to Keycloak and getting an authorization
decision previously required multiple API requests, but now you can
get an authorization decision with just one API request.
*enhanced in Keycloak 22 (PR#20237), committed by the speaker.
<<delegate authorization>>
POST /realms/{realm}/protocol/openid-connect/token HTTP/1.1
Host: keycloak.example.com
Authorization: Bearer {access token}
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:uma-
ticket&audience={client_id}&response_mode=decision&permiss
ion={uri}#{scope}&permission_resource_format=uri
<<authorization decision>>
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": true
}

20
User
7. API request w/ access token
xxx service
Keycloak
PEP
PDP
8. delegate
authorization w/
access token
9. authorization
decision
According to OAuth 2.0, the standard protocol for API authorization,
the overall flow is as follows.
Client
1. use
10. API response
3. user authentication/authorization
2. authorization request
5. token request
4. authorization response
6. token response
(including access token)
OAuth 2.0 Authorization Server

21
User
7. API request w/ access token
xxx service
Keycloak
PEP
PDP
8. delegate
authorization w/
access token
9. authorization
decision
According to OAuth 2.0, the standard protocol for API authorization,
the overall flow is as follows.
Client
1. use
10. API response
3. user authentication/authorization
2. authorization request
5. token request
4. authorization response
6. token response
(including access token)
OAuth 2.0 Authorization code grant (RFC6749)
OAuth 2.0 Authenticated request (RFC6750)
ABAC
OAuth 2.0 Authorization Server

22
cf. User-Managed Access (UMA) 2.0 Grant
Keycloak is a UMA 2.0-compliant authorization server that provides
most UMA capabilities.
-> Resource owners can define permissions for their resources to third parties.
-> More flexible authorization support is possible with various use cases!
3rd party
GET /xxx
xxx service
Keycloak
PEP
PDP
delegate
authorization
authorization
decision
Resource owner
define permission

Contents
23

24
Centralized Authorization vs Distributed Authorization
Advanced challenge that reducing the disadvantages of
centralized authorization (using Keycloak) compared to
distributed authorization at the edge of each service.
Centralized Authorization Distributed Authorization
Scalability/
Data
Management
✔
• Multiple services do not need to store duplicate
authorization data and authorization logic.
✘
• Multiple services need to store duplicate
authorization data and authorization logic.
Performance ✘
• Services need to access the centralized
authorization service for every API request.
✔
• Services only need to access local authorization
logic.
Availability ✘
• When the centralized authorization service
goes down, all services deny every API
request.
✔
• Even if some services go down, the rest services
go well using their local authorization logic.
Consistency ✔
• Only the centralized authorization service makes
authorization decisions so consistency is
guaranteed.
✘
• Local authorization logics make authorization
decisions individually so consistency is not
guaranteed.

25
Tackle Performance Challenge
Fortunately, Keycloak is in CNCF family and can be built in local
Kubernetes, communication to the centralized authorization service
less has negative impact.
-> When performance requirements are severe, Keycloak can be combined with
OPA.
User
GET /xxx
xxx service
Keycloak
PEP
PAP
delegate
authorization
authorization
decision
OPA MongoDB
event
notification
save authorization data/
check authorization data
PDP PIP

26
Keycloak + OPA
User
GET /xxx
xxx service
Keycloak
PEP
PAP
delegate
authorization
authorization
decision
OPA MongoDB
event
notification
save authorization data/
check authorization data
PDP PIP
• Option-1: OPA as just a cache. Performance improvement can be expected by
simply caching authorization decisions from Keycloak in sidecar OPA. Of course,
there is a trade-off with consistency in authorization decisions.
• Option-2: OPA as PDP. Moving the PDP functions to OPA and dedicating
Keycloak to PAP (notifying policy update events, etc.) is possible, as shown below.
Of course, OPA requires storing duplicate authorization information.

27
Tackle Availability Challenge
Combined with OPA, mentioned before, Keycloak resolves
availability challenge to some extent.
-> For mission-critical services that cannot stop, combined with CockroachDB,
Keycloak can withstand regional failures and operate in multi-cloud environments.
* Keycloak plans to support CockroachDB, but does not officially support it as of September 2023.
Kubernetes Cluster A Kubernetes Cluster B
Keycloak Keycloak Keycloak Keycloak
CockroachDB CockroachDB
CockroachDB
Cluster

28
Keycloak + CockroachDB
Kubernetes Cluster B
Keycloak Keycloak Keycloak Keycloak
CockroachDB CockroachDB
CockroachDB
Cluster
• Even in the event of regional failures or large-scale cloud failures, services can go
well by changing the connection destination.
User
Kubernetes Cluster A

29
Summary
• Authorization is becoming more and more important to security considerations.
-> Three of the top 5 security risks include "Authorization."
• To achieve "Scalable" Authorization, separating authorization from application
logic and centralizing authorization data is the keywords.
• Centralized Authorization vs Distributed Authorization.
-> Combined with OPA / CockroachDB, centralized authorization using Keycloak
can improve performance / availability.

30
Trademarks
• OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other
countries.
• GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other countries.
• Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries.
• NGINX and NGINX Plus are registered trademarks of F5, inc. in the United States and other countries.
• Twitter is a trademark or registered trademark of X Corp. in the United States and other countries.
• Facebook is a trademark or registered trademark of Meta Platforms, Inc. in the United States and other
countries.
• Other brand names and product names used in this material are trademarks, registered trademarks, or
trade names of their respective holders.

Yoshiyuki Tabata
11/07/2023
Hitachi, Ltd.
OSS Solution Center
END
Challenge to Implementing “Scalable”
Authorization with Keycloak
31

33
QR CODE FOR FEEDBACK

Challenge to Implementing "Scalable" Authorization with Keycloak

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Challenge to Implementing "Scalable" Authorization with Keycloak

Similar to Challenge to Implementing "Scalable" Authorization with Keycloak (20)

More from Hitachi, Ltd. OSS Solution Center.

More from Hitachi, Ltd. OSS Solution Center. (20)

Recently uploaded

Recently uploaded (20)

Challenge to Implementing "Scalable" Authorization with Keycloak