Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native Environment

© Hitachi, Ltd. 2024. All rights reserved.
Exploring Best Practice for Implementing
Authn and Authz in a Cloud-Native Environment
Open Source Summit Japan 2024
Hitachi, Ltd.
OSS Solution Center
10/29/2024
Yoshiyuki Tabata

1. Difficulty to Implement Authentication and Authorization
2. Current Trends of Authentication and Authorization
3. Best Practices for Designing Authn and Authz
Contents
1
4. Exploring Best Practices for Implementing Authn and Authz

2
Speaker
• Specialist in Identity and Access Management (IAM) and API
➢ Consulting for designing API and Authn/Authz platforms for about 10 years
• Community Contributor
➢ Contributing actively to CNCF TAG Security
➢ Contributing some important functions to OSS such as Keycloak (IAM OSS)
• Other activities (as CNCF Ambassador)
➢ Providing talks at events such as KubeCon, Apidays, All Day DevOps, etc
➢ Writing books and articles about Keycloak and IAM
➢ Hosting CNCF meetups in Japan
Yoshiyuki Tabata
➢ Senior OSS Consultant at Hitachi, Ltd.
➢ CNCF Ambassador / Cloud Native Community Japan
organizer / Cloud Native Security Japan founder
➢ LinkedIn: @ytabata, X: @yo_tabata,
GitHub: @y-tabata

Contents
3

4
What is Authentication / Authorization
Authentication (Authn) is the process of verifying an entity's identity.
Authorization (Authz) is the process of verifying that a requested
action or service is approved for a specific entity.
entities resources / APIs
request
Authentication
Who/What does request
resources?
Authorization
Can the entity take some
action regarding resources?

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

6
Authorization in OWASP Top 10 API Security Risks
Authorization is the most significant security risk, with 3 risks
ranking in the top 5.
#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

7
Various Standards for Authentication
This year marks 10 years since OpenID Connect 1.0 was published.
In recent years, various standards have been published to address various
attacks and social needs, and more will likely increase in the future.
Standards:
OSS: …
OIDF standardizes
IETF standardizes
OASIS
standardizes
W3C standardizes
…
SAML 2.0
Web Authentication
OpenID Connect
Core 1.0
RFC6749:
OAuth 2.0
extend
FAPI 1.0 FAPI 2.0
OAuth
2.1
OID4VCI
OpenID Connect
Discovery 1.0
RFC 7636:
PKCE
RFC 6750: Bearer
Token
RFC 9449:
DPoP
RFC 7662: Token
Introspection
RFC 8693: Token
Exchange
OpenID Connect
DCR 1.0
RFC 8705: OAuth
MTLS
RFC 8628:
Device Flow
CIBA
FAPI-CIBA
JARM

8
No Standards and Various OSS for Authorization
There is no standard and there are a lot of excellent OSS.
Currently, OIDF AuthZEN WG is working to develop standards to address
this situation.
No standards for communicating
authorization information
…
Standards:
OSS:

Contents
9

10
Current Trend of Authentication
In a cloud-native environment, not only User Authentication like
OIDC, but also Workload Authentication is becoming increasingly
important.
In today's world, with an increasing number of complex software functions
being built and deployed as workloads, IETF Workload Identity in Multi
System Environments (WIMSE) WG was established in 2024 and is
developing standards for workload authentication.
Current Active Internet-Drafts Date Description
WIMSE Service to Service
Authentication
2024-08-15 Describes protocols for two workloads to verify
each other's identity.
Workload Identity in a Multi System
Environment (WIMSE) Architecture
2024-07-08 Describes workload identity and its use cases.
Best Current Practice for OAuth 2.0
Client Authentication in Workload
Environments
2024-07-08 Describes OAuth 2.0 client authentication method
in workload environments utilizing service account
token volume projection and RFC7523.

11
Current Trend of Authorization
Authorization is recognized as the most important security risk, and
while there is a demand for dynamic and fine-grained authorization
schemes.
OIDF Authorization Exchange (AuthZEN) WG was established in 2023
and is developing standards for authorization.
Current Drafts Date Description
Authorization API 1.0 2024-09-15 Describes API specification between Policy
Decision Points (PDP) and Policy Enforcement
Points (PEP).

Contents
12

13
Best Practice of Authentication (User Authentication)
Assess the adverse impact of failures and choose the appropriate
user authentication methods among the many available, following
NIST SP 800-63 Digital Identity Guidelines.
Revision 4 of NIST SP 800-63 is currently available as a draft.
Authenticator Assurance Levels (AAL) Permitted Authentication
AAL1 single-factor authentication like password
authentication
AAL2 multi-factor authentication like synced passkey
based on W3C Web Authentication (WebAuthn)
AAL3 multi-factor cryptographic authentication like
device-bound passkey based on WebAuthn

14
User authentication does not need to be implemented individually in
the workload but is typically delegated to an IdP such as Keycloak.
When delegating user authentication, choose the appropriate federation
protocol, following NIST SP 800-63.
Federation Assurance Levels (FAL) Federation Protocols
FAL1 OIDC implicit flow
SAML Web SSO profile
FAL2 OIDC authorization code flow
SAML artifact binding profile
FAL3 OIDC holder-of-key ID token (no standard)
SAML Holder-of-Key profile

15
When adopting OIDC, more specific implementation will be decided
concerning OAuth 2.0 Security Best Current Practice, which
summarizes the latest security recommendations for OAuth 2.0.
OIDC has a high affinity for cloud-native environments and is often adopted
because it is based on OAuth 2.0, the standard for API protection.
Threat examples Mitigations
Cross-Site Request Forgery (CSRF) RFC7636: Proof Key for Code Exchange (PKCE)
Misuse of Stolen Access Tokens RFC8705: OAuth 2.0 Mutual-TLS Client
Authentication and Certificate-Bound Access
Tokens (OAuth MTLS)
RFC9449: OAuth 2.0 Demonstrating Proof of
Possession (DPoP)

16
Node Node
Best Practice of Authentication (Workload Authentication)
The current mainstream is mTLS authentication using X.509
certificates with a SPIFFE-compliant implementation such as SPIRE.
Some ways to interact with SPIRE Agent include implementing its client with
SPIFFE Library, using SPIRE Helper utility, or using Envoy Proxy.
Workload Workload
SPIRE Agent SPIRE Agent
SPIRE Server
mTLS
x.509 certificates
x.509 certificates
workload identities workload identities

17
Best Practice of Authorization
Separate authorization logic from application logic using the P*P
architecture defined in XACML and NIST SP 800-162.
By separating the authorization logic, workloads are freed from having to
keep up with the complexity of authorization conditions as the service grows.
entities (subjects) resources / APIs (objects)
1. unauthorized request Policy
Enforcement
Point (PEP)
4. authorized request
Policy
Decision
Point (PDP)
Policy
Information
Point (PIP)
Policy
Administration
Point (PAP)
authorization
policies data
2. authorization
delegation
3. authorization
decision

18
Depending on your use case, choose the PDP authorization model
between Attribute-Based Access Control (ABAC) and
Relationship-Based Access Control (ReBAC).
Enforcement
Point (PEP)
Policy
Decision
Point (PDP)
Policy
Information
Point (PIP)
Policy
Administration
Point (PAP)
authorization
policies data
2. authorization
delegation
3. authorization
decision

19
Depending on your use case, choose the PDP authorization model
between Attribute-Based Access Control (ABAC) and
Relationship-Based Access Control (ReBAC).
ABAC (Policy as Code) ReBAC (Policy as Graph)
Features Good at very fine-grained
authorization, including depending on
dynamic attributes such as time and
location.
Good at authorization using complex
hierarchical relationships.
Use case
example
Managers who are in APAC can view
Trade Confidential files during
business hours.
Users who are assigned the Member
role of the Development team will also
be granted the Edit role for all files in
that folder if the Development team is
the parent of that folder.
Representative
implementation
Open Policy Agent (OPA) OpenFGA

20
Interaction between PDP and PEP is implemented following OIDF
AuthZEN WG Authorization API 1.0.
Since this specification is still a draft, it is possible to break changes, so it is
necessary to keep a close eye on trends.
Enforcement
Point (PEP)
Policy
Decision
Point (PDP)
Policy
Information
Point (PIP)
Policy
Administration
Point (PAP)
authorization
policies data
2. authorization
delegation
3. authorization
decision

21
Obtain user identities used for authorization following RFC7662:
OAuth 2.0 Token Introspection.
Access token added to Token Introspection request is obtained from API
request.
entities resources / APIs
1. API request w/ access token
(following RFC6750: OAuth 2.0 Bearer Token Usage)
Authorization
Server
2. Token Introspection request
w/ access token
(following RFC7662)

22
In a cloud-native environment, the workload may need to interact
with others. In this case, obtain a token following RFC8693: OAuth
2.0 Token Exchange and use it within a trusted domain.
For details on this interaction, refer to Transaction Tokens, a draft of the
IETF oauth WG.
Trusted Domain
entities
1. API request
w/ access token
Authorization
Server
2. Token Exchange request
w/ access token
Workload Workload
4. API request
w/ new token
3. Token Exchange response
w/ new token

23
Trusted Domain A
If workloads are distributed across multiple trusted domains, obtain a
token for the other trusted domain following RFC8693 and RFC7523:
JWT Profile for OAuth 2.0 Authorization Grants.
For details on this interaction, refer to OAuth Identity and Authorization
Chaining Across Domains, a draft of the IETF oauth WG.
Trusted Domain B
entities
1. API request
w/ access token
Authorization
Server
Workload Workload
6. API request
w/ new access token
Authorization
Server
2. Token Exchange
request w/ access token
3. Token Exchange
response
w/ authz grant JWT
4. Token request
w/ authz grant JWT
5. Token response
w/ new access token

Contents
24

25
Exploring Best Practices for Implementing Authn and Authz
Based on the best practices for designing Authn and Authz explained
so far, we try to integrate Keycloak as the authorization server and
OPA or OpenFGA as the PDP, for realizing one simple Authn and
Authz implementation model.
entities NGINX
(Resource Server, PEP)
Keycloak
(Authorization
Server)
OPA or
OpenFGA
(PDP)
1. Issue access token
(following RFC6749: OAuth 2.0
Authz Framework)
3. Delegate authz
(following Authorization API)

26
Major features
⚫ Supporting standards. ex. OAuth 2.0, OpenID
Connect 1.0, SAML v2, …
⚫ Login with social networks.
⚫ Connect to existing user stores. ex. LDAP,
Active Directory, …
Keycloak
• Keycloak is IAM (Identity and Access Management) OSS.
• Keycloak provides OAuth2 authorization server features and single sign-on features.
• Keycloak is a CNCF incubating project.
Supporting Standard Protocols
Keycloak
LDAP
Active
Directory
RDB
OpenID Connect 1.0
SAML v2
GitHub
X
Facebook
Identity Management
Social Login
OAuth 2.0

27
Based on the best practices for designing Authn and Authz explained
so far, we try to integrate Keycloak as the authorization server and
OPA or OpenFGA as the PDP, for realizing one simple Authn and
Authz implementation model.
entities NGINX
Keycloak
(Authorization
Server)
OPA or
OpenFGA
(PDP)
Authz Framework)
3. Delegate authz

28
There are two key points for integration:
1. How to delegate authorization
2. How to provision attributes to be used for authorization
entities NGINX
Keycloak
(Authorization
Server)
OPA or
OpenFGA
(PDP)
0. Provision attributes
Authz Framework)
3. Delegate authz
Key point 1
Key point 2

29
Keycloak – OPA integration
=> Use OPA's own REST API, but allows parameters to be similar to those of the Authorization API to
some extent.
=> One solution is Option 4 Push Data for External Data usage described in the OPA document. In that
case, it is recommended to use ecosystems such as Styra Enterprise OPA or OPAL.
entities NGINX
Keycloak
(Authorization
Server)
OPA
(PDP)
Authz Framework)
3. Delegate authz
POST /v1/data/authz HTTP/1.1
{
"input": { "subject": { … }, … }
}
using Styra Enterprise
OPA or OPAL
to support pushing
data into OPA

30
Keycloak – OpenFGA integration
entities NGINX
Keycloak
(Authorization
Server)
OpenFGA
(PDP)
Authz Framework)
3. Delegate authz
=> Use OpenFGA's Check API which is completely original.
=> Use OpenFGA's Write API which is completely original. (Prepare the Keycloak Event Listener
SPI Provider that calls the Write API when attributes are changed.)
POST /store/{id}/check HTTP/1.1
{
"tuple_key": { "user": { … }, … }
}
POST /store/{id}/write HTTP/1.1
{
"writes": { "tuple_keys": [ … ] }
}

31
Comparison between OPA and OpenFGA
Before showing a demo, summarize the features of both solutions.
OPA OpenFGA
Authz model that
each OSS is
good at
ABAC ReBAC
How to delegate
authorization
Use OPA's own REST API, but allows
parameters to be similar to those of
the Authorization API to some extent.
Use OpenFGA's Check API which is
completely original.
How to provision
attributes to be
used for
authorization
One solution is Option 4 Push Data for
External Data usage described in the
OPA document. In that case, it is
recommended to use ecosystems
such as Styra Enterprise OPA or
OPAL.
Use OpenFGA's Write API which is
completely original.

32
Summary of Best Practices
➢ Authentication
➢ User Authentication
➢ NIST SP 800-63 Digital Identity Guidelines (AAL and FAL)
➢ OAuth 2.0 Security Best Current Practice
➢ Workload Authentication
➢ SPIFFE
➢ Authorization
➢ Architecture: P*P architecture (XACML / NIST SP 800-162)
➢ PDP and PEP interaction: Authorization API 1.0
➢ Authorization Model: ABAC / ReBAC
➢ User Identity Propagation
➢ External to Internal
➢ RFC6750: OAuth 2.0 Bearer Token Usage
➢ RFC7662: OAuth 2.0 Token Introspection
➢ Internal to Internal (Same Trusted Domain)
➢ RFC8693: OAuth 2.0 Token Exchange
➢ Transaction Tokens
➢ Internal to Internal (Distributed across Multiple Trusted Domains)
➢ RFC8693: OAuth 2.0 Token Exchange
➢ RFC7523: JWT Profile for OAuth 2.0 Authorization Grants
➢ OAuth Identity and Authorization Chaining Across Domains

33
Let’s Join CNCF IAM White Paper PJ and TAG Security APAC!
➢We are currently working on a project to write a white paper
on Identity and Access Management (IAM) to discuss best
practices for authentication and authorization such as those
introduced in this session. If you are interested, don't hesitate
to get in touch with us!
https://github.com/cncf/tag-security/issues/1332
➢The CNCF Security Technical Advisory Group (TAG
Security) APAC region meetings have started every other
week from August 21st! This is in a more friendly time zone
for the security freaks in attendance today, so please join us!
https://zoom-lfx.platform.linuxfoundation.org/meetings/cncf?view=week

34
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.
• X is a trademark or registered trademark of X Corp. 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
10/29/2024
Hitachi, Ltd.
OSS Solution Center
END
Exploring Best Practice for Implementing
Authn and Authz in a Cloud-Native Environment
35

Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native Environment

Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native Environment

More Related Content

Similar to Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native Environment (20)

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

Recently uploaded (20)

Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native Environment