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

© Hitachi, Ltd. 2024. All rights reserved.
Exploring Best Practices for Implementing
Authn and Authz in a Cloud-Native Environment
All Day DevOps 2024
Hitachi, Ltd.
OSS Solution Center
10/11/2024
Yoshiyuki Tabata

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

3
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 KubeCon, Apidays, Open Source Summit, etc.
 Author of Keycloak books (Japanese) and writer of web articles about IAM (Japanese)
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

4
Contents

5
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?

6
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

7
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

8
Contents

9
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

10
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:

11
Contents

12
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.

13
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).

14
Contents

15
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

16
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

17
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)

18
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

19
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

20
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

21
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

22
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

23
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)

24
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

25
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

26
Summary of Best Practice
 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

27
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

28
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/11/2024
Hitachi, Ltd.
OSS Solution Center
END
Exploring Best Practices for Implementing
Authn and Authz in a Cloud-Native Environment
29

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

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

More Related Content

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

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

Recently uploaded (20)

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