keycloak/kc-sig-fapi

OAuth SIG (OAuth : Special Interest Group)

Ex FAPI-SIG (Financial-grade API Security : Special Interest Group)

Overview

FAPI-SIG is a group whose activity is mainly supporting Financial-grade API (FAPI) and its related specifications to keycloak.

FAPI-SIG is open to everybody so that anyone can join it anytime. Nothing special need not to be done to join it. Who want to join it can only access to the communication channels shown below. All of its activities and outputs are public so that anyone can access them.

FAPI-SIG mainly treats FAPI and its related specifications but not limited to. E.g., Ecosystems employing FAPI for their API Security like UK OpenBanking, Open Banking Brasil and Australia Consumer Data Right (CDR).

Since June 2023, FAPI-SIG is evolved into OAuth SIG. OAuth SIG will mainly treats OAuth/OIDC and its related security features like FAPI 2.0 to Keycloak.

Scope

Supporting OAuth/OIDC and its related security features to Keycloak.

Roles

Tech Lead : Takashi Norimatsu

Members

Please refer to the list.

Goals

Currently, proposed goals are as follows.

OAuth and OIDC related security features

• OAuth 2.0 Rich Authorization Requests (RAR)

• OpenID for Verifiable Credential Issuance

Nation/Region/Market Specific Features

• EU : PSD2/eIDAS - QWAC Verification Extension

Open Works

Currently, proposed open works are as follows.

• Integrating FAPI conformance tests run into keycloak’s CI/CD pipeline

• Implement security profiles for Apps run on mobile devices

  • RFC 8252 OAuth 2.0 for Native Apps
  • OAuth 2.0 for Browser-Based Apps

• FAPI-RW App2App

Contributions

FAPI related accomplishments by FAPI-SIG and OAuth SIG, other contributors and keycloak development team is as follows.​

Common Security Features

keycloak 14

• Client Policies​

keycloak 24

• Lightweight Access Token
• OAuth Grant Type SPI

Nation/Region/Market Specific Features

keycloak 15

• Brazil : Open Banking Brasil Financial-grade API Security Profile

  mainly by keycloak development team.

Standards​

keycloak 13

• Client Initiated Backchannel Authentication (CIBA) poll mode​

keycloak 14

• FAPI 1.0 Baseline Security Profile​
• FAPI 1.0 Advanced Security Profile​

keycloak 15

• Client Initiated Backchannel Authentication (CIBA) ping mode​

  mainly by keycloak development team.

• FAPI JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)​

  mainly by the contributor outside FAPI-SIG.

• FAPI Client Initiated Backchannel Authentication Profile (FAPI-CIBA)​

• RFC 9126 OAuth 2.0 Pushed Authorization Requests (PAR)

keycloak 18

• OpenID Connect Logout 1.0 for Logout Profiles

  mainly by keycloak development team and the contributor outside FAPI-SIG.

keycloak 20

• UK OpenBanking​ Security Profile

keycloak 23

• RFC 9207 OAuth 2.0 Authorization Server Issuer Identification
• RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• FAPI 2.0 Security Profile Second Implementer’s Draft
• FAPI 2.0 Message Signing First Implementer’s Draft

keycloak 24

• RFC 8032 Edwards-Curve Digital Signature Algorithm (EdDSA)
• The OAuth 2.1 Authorization Framework - Draft version 10

In progress

OpenID for Verifiable Credentials

Format

• Selective Disclosure for JWTs (SD-JWT)
• SD-JWT-based Verifiable Credentials (SD-JWT VC)
• JWT VC
• W3C Verfiable Credentials Data Format(VCDM)

Issurance Protocol

• OpenID for Verifiable Credential Issuance

Other OpenID Connect Extension

• OpenID Connect for Identity Assurance 1.0

Automated Conformance Test Run Environment by this kc-fapi-sig repository

The current environment uses the following software version.

• Keycloak version : 25.0.2
• Conformance-suite version : release-v5.1.17

FAPI 1.0 Advanced (Final)​

• Client Authentication Method : MTLS, private_key_jwt​
• Signature Algorithm : PS256, ES256​
• Request Object Method : plain, PAR​
• Response Mode : plain, JARM​

Keycloak 15.0.2 have achieved certification for all 8 conformance profiles of FAPI 1 Advanced Final (Generic).

FAPI-CIBA (Implementer’s Draft)​

• Client Authentication Method : MTLS, private_key_jwt​
• Signature Algorithm : PS256, ES256​
• Mode : Poll, Ping

Keycloak 15.0.2 have achieved certification for all 4 conformance profiles of Financial-grade API Client Initiated Backchannel Authentication Profile (FAPI-CIBA).

Open Banking Brasil FAPI 1.0

• Client Authentication Method : MTLS, private_key_jwt​
• Signature Algorithm : PS256
• Request Object Method : plain, PAR​
• Response Mode : plain, JARM​

Keycloak 15.0.2 have achieved certification for 8 conformance profiles of Brazil Open Banking (Based on FAPI 1 Advanced Final) except for DCR (Dynamic Client Registration).

Open Finance Brasil FAPI 1.0 (Open Banking Brasil FAPI 1.0 was evolved)

• Client Authentication Method : private_key_jwt​
• Signature Algorithm : PS256
• Request Object Method : PAR​
• Response Mode : plain
• ID token encryption : required

Australia Consumer Data Right (CDR)

• Client Authentication Method : private_key_jwt​
• Signature Algorithm : PS256
• Request Object Method : plain, PAR​
• Response Mode : plain

Keycloak 15.0.2 have achieved certification for all 2 conformance profiles of Australia CDR (Based on FAPI 1 Advanced Final).

UK Open Banking

• Client Authentication Method : MTLS, private_key_jwt​
• Signature Algorithm : PS256
• Request Object Method : plain, PAR​
• Response Mode : plain

OpenID Connect: OpenID Providers

• Basic OP
• Implicit OP
• Hybrid OP
• Config OP
• Dynamic OP
• Form Post OP
• 3rd Party-Init OP

Keycloak 18.0.0 have re-achieved certification for 6 conformance profiles of Certified OpenID Providers except for 3rd Party-Init OP.

OpenID Connect: OpenID Providers for Logout Profile

• Front-Channel OP
• Back-Channel OP
• Session OP
• RP-Initiated OP

Keycloak 18.0.0 have achieved certification for all 4 conformance profiles of Certified OpenID Providers for Logout Profiles.

Note: Session OP and Front-Channel OP of OpenID Provider for Logout Profile conformance tests cannot be automated. These can be passed manually.

FAPI 2.0 Security Profile Second Implementer’s Draft

• FAPI2SP MTLS + MTLS
  • Client Authentication Method : mtls
  • Sender Constrain : mtls
  • OpenID : plain_oauth
  • FAPI Profile : plain​
• FAPI2SP private key + MTLS
  • Client Authentication Method : private_key_jwt
  • Sender Constrain : mtls
  • OpenID : plain_oauth
  • FAPI Profile : plain​
• FAPI2SP OpenID Connect
  • Client Authentication Method : mtls
  • Sender Constrain : mtls
  • OpenID : openid
  • FAPI Profile : plain​

FAPI 2.0 Message Signing First Implementer’s Draft

• FAPI2MS JAR
  • Client Authentication Method : mtls
  • Sender Constrain : mtls
  • OpenID : plain_oauth
  • FAPI Profile : plain​
  • FAPI Request Method : signed_non_repudiation
  • FAPI Response Mode : plain_response
• FAPI2MS JARM
  • Client Authentication Method : mtls
  • Sender Constrain : mtls
  • OpenID : plain_oauth
  • FAPI Profile : plain​
  • FAPI Request Method : signed_non_repudiation
  • FAPI Response Mode : jarm

Passed Conformance Tests per Keycloak version

To ensure that every keycloak version can pass conformance tests, we check if a new Keycloak version pass conformance tests that the older Keycloak version could pass whenever the new Keycloak version is released.

We tagged the environment for every keycloak verion:

Tag	Keycloak version	Conformance-suite version
kc-15.0.2	15.0.2	release-v4.1.38
kc-17.0.0	17.0.0	release-v4.1.41
kc-17.0.1	17.0.1	release-v4.1.41
kc-18.0.0	18.0.0	release-v4.1.42
kc-18.0.2	18.0.2	release-v4.1.42
kc-19.0.1	19.0.1	release-v4.1.45
kc-19.0.2	19.0.2	release-v5.0.3
kc-20.0.0	20.0.0	release-v5.0.6
kc-20.0.1	20.0.1	release-v5.0.6
kc-20.0.2	20.0.2	release-v5.0.7
kc-20.0.3	20.0.3	release-v5.0.12
kc-20.0.5	20.0.5	release-v5.0.14
kc-21.0.0	21.0.0	release-v5.1.0
kc-21.0.1	21.0.1	release-v5.1.0
kc-21.0.2	21.0.2	release-v5.1.2
kc-21.1.0	21.1.0	release-v5.1.2
kc-21.1.1	21.1.1	release-v5.1.2
kc-21.1.2	21.1.2	release-v5.1.5
kc-22.0.0	22.0.0	release-v5.1.5
kc-22.0.1	22.0.1	release-v5.1.5
kc-22.0.2	22.0.2	release-v5.1.5
kc-22.0.3	22.0.3	release-v5.1.7
kc-22.0.4	22.0.4	release-v5.1.8
kc-22.0.5	22.0.5	release-v5.1.9
kc-23.0.0	23.0.0	release-v5.1.15
kc-23.0.1	23.0.1	release-v5.1.15
kc-23.0.2	23.0.2	release-v5.1.15
kc-23.0.3	23.0.3	release-v5.1.15
kc-23.0.4	23.0.4	release-v5.1.15
kc-23.0.5	23.0.5	release-v5.1.15
kc-23.0.6	23.0.6	release-v5.1.15
kc-23.0.7	23.0.7	release-v5.1.15
kc-24.0.0	24.0.0	release-v5.1.15
kc-24.0.1	24.0.1	release-v5.1.15
kc-24.0.2	24.0.2	release-v5.1.16
kc-24.0.3	24.0.3	release-v5.1.16
kc-24.0.4	24.0.4	release-v5.1.16
kc-24.0.5	24.0.5	release-v5.1.16
kc-25.0.0	25.0.0	release-v5.1.17
kc-25.0.1	25.0.1	release-v5.1.17
kc-25.0.2	25.0.2	release-v5.1.17
kc-25.0.4	25.0.4	release-v5.1.21

Keycloak version	FAPI 1.0 Advanced	FAPI-CIBA	Open Banking Brasil FAPI 1.0 (*1,*2)	Open Finance Brasil FAPI 1.0 (*3)	Australia Consumer Data Right (CDR)	UK Open Banking	OpenID Connect OP (*4)	OpenID Connect OP for Logout Profile	FAPI 2.0 Security Profile Implementer’s Draft	FAPI 2.0 Message Signing Implementer’s Draft
15.0.2	x	x	x	-	x	-	-	-	-	-
17.0.0	x	x	x	-	x	-	-	-	-	-
17.0.0-legacy	x	x	x	-	x	-	-	-	-	-
17.0.1	x	x	x	-	x	-	-	-	-	-
17.0.1-legacy	x	x	x	-	x	-	-	-	-	-
18.0.0	x	x	x	-	x	-	x	x	-	-
18.0.0-legacy	x	x	x	-	x	-	x	x	-	-
18.0.2	x	x	x	-	x	-	x	x	-	-
18.0.2-legacy	x	x	x	-	x	-	x	x	-	-
19.0.1	x	x	x	-	x	-	x	x	-	-
19.0.1-legacy	x	x	x	-	x	-	x	x	-	-
19.0.2	x	x	x	-	x	-	x	x	-	-
19.0.2-legacy	x	x	x	-	x	-	x	x	-	-
20.0.0	x	x	x	-	x	x	x	x	-	-
20.0.1	x	x	x	-	x	x	x	x	-	-
20.0.2	x	x	x	-	x	x	x	x	-	-
20.0.3	x	x	x	-	x	x	x	x	-	-
20.0.5	x	x	x	-	x	x	x	x	-	-
21.0.0	x	x	x	-	x	x	x	x	-	-
21.0.1	x	x	x	-	x	x	x	x	-	-
21.0.2	x	x	x	-	x	x	x	x	-	-
21.1.0	x	x	x	-	x	x	x	x	-	-
21.1.1	x	x	x	-	x	x	x	x	-	-
21.1.2	x	x	x	-	x	x	x	x	-	-
22.0.0	x	x	x	-	x	x	x	x	-	-
22.0.1	x	x	x	-	x	x	x	x	-	-
22.0.2	x	x	x	-	x	x	x	x	-	-
22.0.3	x	x	x	-	x	x	x	x	-	-
22.0.4	x	x	x	-	x	x	x	x	-	-
22.0.5	x	x	x	-	x	x	x	x	-	-
23.0.0	x	x	-(*5)	-(*5)	x	x	x	x	x	x
23.0.1	x	x	x	x	x	x	x	x	x	x
23.0.2	x	x	x	x	x	x	x	x	x	x
23.0.3	x	x	x	x	x	x	x	x	x	x
23.0.4	x	x	x	x	x	x	x	x	x	x
23.0.5	x	x	x	x	x	x	x	x	x	x
23.0.6	x	x	x	x	x	x	x	x	x	x
23.0.7	x	x	x	x	x	x	x	x	x	x
24.0.0	x	x	x	x	x	x	x	x	x	x
24.0.1	x	x	x	x	x	x	x	x	x	x
24.0.2	x	x	x	x	x	x	x	x	x	x
24.0.3	x	x	x	x	x	x	x	x	x	x
24.0.4	x	x	x	x	x	x	x	x	x	x
24.0.5	x	x	x	x	x	x	x	x	x	x
25.0.0	x	x	x	x	x	x	x	x	x	x
25.0.1	x	x	x	x	x	x	x	x	x	x
25.0.2	x	x	x	x	x	x	x	x	x	x
25.0.4	x	x	x	x	x	x	x	x	x	x

Note: Keycloak legacy (wildfly) is no longer supported since keycloak 20.

*1 : Up to Implementer's Draft version 2, Open Banking Brazil Security Profile. From Implementer's Draft version 3, Open Finance Brazil Security Profile. Its conformance test is no longer supported since conformance suite version 5.1.11. Therefore, its conformance test is conducted by the conformance suite version 5.1.10.

*2 : Its conformance test is supported by conformance suite version 5.1.11.

*3 : Except for Dynamic Client Registration (DCR) conformance profile.

*4 : Except for 3rd Party-Init OP conformance profile.

*5 : ISSUE-25022

Other Contributions

Conferences

OAuth Security Workshop 2024 (Auditorium Antonianum, Rome, Italy, April 11, 2024)

• Title: Supporting OAuth 2.0 Based Security Profiles to Open-source Software - from Implementation to Operation
• URL: https://oauth.secworkshop.events/osw2024/agenda-thursday-osw-2024

KubeCon + CloudNativeCon Europe 2024 (Paris Expo Porte de Versailles, Paris, France, March 22, 2024)

• Title: The Leading Edge of AuthN and AuthZ by Keycloak
• URL: https://kccnceu2024.sched.com/event/1YhiQ/the-leading-edge-of-authn-and-authz-by-keycloak-takashi-norimatsu-hitachi-thomas-darimont-codecentric-ag

OpenID Summit Tokyo 2024 (Shibuya Stream Hall, Tokyo, Japan, January 19, 2024)

• Title: Implementing OAuth 2.0-based Security Profiles on Open-source Software
• URL: https://www.openid.or.jp/summit/2024/en/

KubeCon + CloudNativeCon North America 2023 (McCormick Place West, Chicago, Illinois, United States of America, November 7, 2023)

• Title: 10 Years of Keycloak - What's Next for Cloud-Native Authentication and OIDC?
• URL: https://kccncna2023.sched.com/event/1R2mH/10-years-of-keycloak-whats-next-for-cloud-native-authentication-and-oidc-alexander-schwartz-red-hat-takashi-norimatsu-hitachi-ltd

Keyconf 23 (Level39, London, United Kingdom, June 16, 2023)

please see keyconf 23.

Apidays Paris 2022 (Cité des sciences et de l'industrie, Paris, France, December 6, 2022)

• Title: Securing APIs in Open Banking - Financial-grade API security profile implementation to open-source software
• URL: https://speakerdeck.com/apidays/apidays-paris-2022-securing-apis-in-open-banking-takashi-norimatsu-hitachi

OAuth Security Workshop 2021 (Virtual Event, December 1, 2021)

• Title: Consideration on how to apply multiple FAPI and its related security profiles dynamically
• URL: https://www.youtube.com/watch?app=desktop&v=_ei7e8aOfkY

Referred academic paper

Policy-Based Method for Applying OAuth 2.0-Based Security Profiles

• Journal: IEICE Transactions on Information and Systems, Volume E106.D-9, pp.1364-1379, Institute of Electronics, Information and Communications Engineers (IEICE), Septempber 1, 2023.
• DOI: https://doi.org/10.1587/transinf.2022icp0004
• URL: https://www.jstage.jst.go.jp/article/transinf/E106.D/9/E106.D_2022ICP0004/_pdf

Oral presentation of refereed international conference paper

Flexible Method for Supporting OAuth 2.0 Based Security Profiles in Keycloak

• Proceedings: Lecture Notes in Informatics (LNI) Proceedings of Open Identity Summit 2022, P-325, pp.87-98, DTU Compute, Lyngby, Denmark, July 7-8, 2022.
• DOI: https://doi.org/10.18420/OID2022_07
• DBLP: https://dblp.uni-trier.de/rec/conf/openidentity/NorimatsuNY22
• URL: https://dblp.uni-trier.de/rec/conf/openidentity/2022
• URL: https://dblp.uni-trier.de/db/conf/openidentity/openidentity2022.html#NorimatsuNY22

Communication Channels

Not only OAuth SIG member but others can communicate with each other by the following ways.

• Slack : Cloud Native Computing Foundation (CNCF) slack's channel #keycloak-oauth-sig
• Mail : Google Group keycloak developer mailing list
• Chat : Zulip Chat stream (#dev-sig-fapi)
• Meeting : Web meeting on a regular basis

Automated Conformance Test Run Environment

Please see conformance-tests-env.

License

• Apache License, Version 2.0

kc-sig-fapi's Issues

Integrating FAPI-RW conformance tests run into keycloak’s CI/CD pipeline

It is helpful to run FAPI-RW conformance tests automatically on keycloak’s CI/CD pipeline like the existing arquillian integration tests.

It can keep keycloak to comply with FAPI-RW whenever any PR is merged.

It seems too much complicated to treat this task by one issue so that decomposing it into several sub tasks might be preferable.

keycloak does not check whether Request Object include "redirect_uri" claim and return appropriate error

According to FAPI-RW-5.2.3-8(https://openid.net/specs/openid-financial-api-part-2-ID2.html#public-client), FAPI-R-5.2.3-8(https://openid.net/specs/openid-financial-api-part-1-ID2.html#public-client) and OIDCC-3.3.2.6 (https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthError) because FAPI RW uses hybrid flow :

• check whether Request Object does include "redirect_uri" claim
• check whether the value of "redirect_uri" query parameter matches the value of "redirect_uri" claim in the request object exactly
• if not, return the error (error=invalid_request_object) from authorization endpoint such that
  HTTP/1.1 302 Found
  Location: https://client.example.com/cb#error=invalid_request_object&state=xyz

Confirm all FAPI R/W OP w/ Private key conformance tests are passed by the released keycloak

Confirm all FAPI R/W OP w/ Private Key conformance tests are passed by the released keycloak to which all PRs for FAPI-RW are merged.

We can work with this issue after the following events :

• All PRs for FAPI-RW are merged.
• keycloak is released to which all PRs for FAPI-RW are merged.
• Container image for this version of keycloak is released.

Please note that the test environment is clarified and recorded (e.g. conformance test ver, keycloak ver, etc..).

Break down FAPI-CIBA (poll) implementation task into separate sub tasks

After the completion of #49, break down FAPI-CIBA (poll) implementation task into separate sub tasks that can be done in parallel.

keycloak does not check whether Request Object include "state" claim and return appropriate error

According to FAPI-RW-5.2.3-8(https://openid.net/specs/openid-financial-api-part-2-ID2.html#public-client), FAPI-R-5.2.3-9(https://openid.net/specs/openid-financial-api-part-1-ID2.html#public-client) and OIDCC-3.3.2.6 (https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthError) because FAPI RW uses hybrid flow :

• check whether Request Object does include "state" claim
• check whether the value of "state" query parameter matches the value of "state" claim in the request object exactly
• if not, return the error (error=invalid_request_object) from authorization endpoint such that
  HTTP/1.1 302 Found
  Location: https://client.example.com/cb#error=invalid_request_object&state=xyz

How to cancel authentication by a user during authentication and authorization flow

Test modules FAPIRWID2UserRejectsAuthenticationWithMTLS and FAPIRWID2UserRejectsAuthenticationWithPrivateKeyAndMTLSHolderOfKey requires cancellation of authentication by the user.

client_jwks_server returns all client's public keys

When the client 1 sends an authz request with the request object signed by using the client 2's private key, conformance test expects that the authz server returns error. However, the keycloak accepts such the authz request.

The reason why is that keycloak-fapi environment's client_jwks_server returns all client's public keys.

Therefore, on request object verification, the keycloak loads not only the client 1's public key but also the client 2's public key and retrieve the client 2's public key by using a search key of "kid" in the request object.

FAPI-RW-8.5-2: DisallowTLS10, DisallowTLS11, DisallowInsecureCipher

The server accepted a TLS 1.0 and 1.1 connection. This is not permitted by the specification. Also, the server accepted a disallowed cipher: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.

https://openid.net/specs/openid-financial-api-part-2-ID2.html#tls-considerations

Duplicate usage of JWS Client Assertion for client authentication

In "Attempting reuse of client2's authorisation code & testing if access token is revoked", the test code tries to check whether an authorization server (keycloak) returns error following RFC 6749 section 5 when it receives the same authorization code that has already been used and the corresponding tokens has been issued in return to it.

In test codes, the client generated the JWS Client Assertion for client authentication and sent it along with an authorization code to an authorization server. The authorization server returned an tokens in return to this authorization code. Next, the client send the same JWS Client Assertion for client authentication along with the same authorization code to the authorization server. The test codes expected the authorization server returns 400 Bad Requestでerror=invalid_grant. However, keycloak returned 400 Bad Reqeust error=unauthorizad_client.

The reason why is that keycloak seemed to judge that Replay Attack occured. The test codes use the same JWS Client Assertion on the first and second time for aquiring tokens.

I think the test codes should use the different JWS Client Assertion on each first and second time for aquiring tokens because this test case is for checking duplicate usage of Authorization Code.

As an aside, the same test case in [MTLS] test plan returns SUCCESS because [MTLS] test plan adopt [MTLS] section 2 as client authentication, not JWS Client Assertion.

Clarify issues to pass all FAPI R/W OP w/ MTLS conformance tests

By re-running the latest FAPI R/W OP w/ MTLS conformance tests against the latest keycloak to clarify issues to pass all FAPI R/W OP w/ MTLS conformance tests.

Resource Server related FAILURE : Content-type HTTP header

EnsureResourceResponseContentTypeIsJsonUTF8 checks Content-type HTTP header from Resource Server.

To pass these tests, the resource server defined as "resourceUrl" in the config file needs to be configured to satisfy Content-type HTTP header related requirements (FAPI-R-6.2.1-9, 10).

These test should be omitted because the test plan is for the authorization server (keycloak), not the resource server.

FAPI-CIBA Implementation Internals : Use Only Auth Result Cache by Infinispan For CIBA Flow Session Binding

The design document for FAPI-CIBA states that it requires Auth Result Cache() by Infinispan for CIBA flow session binding.
However, the current CIBA prototype implementation uses one additional Infinispan Cache called Auth Req Context Cache.

The goal of this issue is to modify the CIBA prototype implementation to use only "Auth Result Cache" for CIBA flow session binding by following the design document for FAPI-CIBA.

To do so, the following tasks needs to be done.

"Auth Req Context Cache" is removed by storing data in "Auth Req Context Cache" to auth_req_id itself.

• change auth_req_id format to accomodate the data that have currently been stored in "Auth Req Context Cache"
• support JWS for this auth_req_id

For CIBA flow session binding between keycloak and Decouple Auth Server, Auth Result ID is used instead of decoupled_auth_id.

Task lists and their progresses are as follows.

• Investigate RFC 8417 Security Event Token (SET)

  • Investigate SET to clarify whether it can be used as the basis format for JWT formatted state transfer auth_req_id whose representation is changed from Handle(Reference) Token to an Assertion(Self-contained) Token

• Determine auth_req_id representation in JWT

  • Determine fields included in JWT formatted auth_req_id by considering the following information type
    • CIBA protocol related information
    • information used for verifying JWT's integrity

• Support JWT formatted auth_req_id

  • Implement JWT formatted auth_req_id
  • use this JWT formatted auth_req_id on communication between keycloak and Consumer Device(CD) which handle this JWT auth_req_id as reference token as usual
  • Run existing CIBATest for regression

• Support JWS for auth_req_id

  • Implement JWS for auth_req_id by the following signature algorithms by considering that both the producer and the consumer of this auth_req_id is keycloak the same as Refresh Token
    • HS256
    • HS384
    • HS512
  • Run existing CIBATest for regression (CD still handles this JWT auth_req_id as reference token as usual)

• Support JWE for auth_req_id

  • Implement JWE for auth_req_id by the following key management and content encryption algorithm by considering that both the producer and the consumer of this auth_req_id is keycloak the same as Refresh Token
    • Key Management Algorithm for Key Encryption Key (KEK) : "alg"
      • dir
    • Content Encryption Algorithm for Content Encryption Key (CEK) : "enc"
      • A128CBC-HS256
      • A192CBC-HS384
      • A256CBC-HS512
      • A128GCM
      • A192GCM
      • A256GCM
  • Run existing CIBATest for regression (CD still handles this JWT auth_req_id as reference token as usual)

• Support settings for JWS and JWE for auth_req_id

  • Realize these settings as CIBA Policy

• Remove Auth Req Context Infinispan Cache

Resource Server needs to check whether the received Access Token from Client is still valid or not

CallAccountsEndpointWithBearerTokenExpectingError checks whether Resource Server returns error when it receives Access Token that became invalid due to some reason (double usage of Authz Code).

Resource Server needs to have capability of checking whether received Access Token is valid or not.

To do so, Resource Server asks keycloak for it by Token Introspection, and returns error to the Client if it is invalid.

Confirm all FAPI R/W OP w/ MTLS conformance tests are passed by the locally built keycloak

Confirm all FAPI R/W OP w/ MTLS conformance tests are passed by the locally build keycloak that the following issues are resolved (not yet sent as PRs).

• KEYCLOAK-15236
• KEYCLOAK-14195
• KEYCLOAK-14204
• KEYCLOAK-14205

clarified by #41

FAPI-CIBA Backchannel Authentication Request : support User Code

The design document for FAPI-CIBA states that it requires to support user_code (User Code).
However, the current CIBA prototype implementation does not support it.

The goal of this issue is to implement on the CIBA prototype implementation user_code (User Code) by following the design document for FAPI-CIBA.

keycloak's app server does not reject connection without client certificate

To pass these tests, the keycloak's application server (wildfly) rejects HTTPS connection without client certificate.

The following might be helpful :

• https://www.keycloak.org/docs/latest/server_admin/index.html#_enable-mtls-wildfly

• https://docs.jboss.org/author/display/WFLY10/Undertow+subsystem+configuration
  HTTPS Listener - verify-client

Clarify the gap between prototype and merged design document

Clarify the gap between prototype in #47 and merged design document in #48. List up their differences.

Develop prototype of CIBA supported keycloak

Develop prototype of CIBA supported keycloak to clarify whether CIBA can be actually supported to keycloak and how difficult it is.

OIDCC-5.5.1.1: acr value in id_token is not (one of the) requested values

Test module ValidateIdTokenACRClaimAgainstRequest checks acr value in id_token which is requested in the request object below.

{
  "client_id": "client2-private_key_jwt-ES256-ES256",
  "redirect_uri": "https://conformance-suite.keycloak-fapi.jic.openstandia.jp/test/a/keycloak/callback?dummy1=lorem&dummy2=ipsum",
  "scope": "openid",
  "claims": {
    "id_token": {
      "acr": {
        "value": "urn:mace:incommon:iap:silver",
        "essential": true
      }
    }
  },
  "state": "8G4PNJ7mqc",
  "nonce": "WCVm9YfSFu",
  "response_type": "code id_token"
}

OIDCC-5.5.1.1 says:

If the acr Claim is requested as an Essential Claim for the ID Token with a values parameter requesting specific Authentication Context Class Reference values and the implementation supports the claims parameter, the Authorization Server MUST return an acr Claim Value that matches one of the requested values.

But keycloak with default settings doesn't handle the essential acr claim. It returns "0" or "1". "0" is used when the user is authenticated by SSO Cookie. "1" is used in the others. To pass this test, keycloak needs to return "urn:mace:incommon:iap:silver".

In production, developers need to configure the authentication flows, authenticator, and protocol mappers to meet their customer's requirements. By these configurations, keycloak can return appropriate acr value correspond to requested acr claim.

For the conformance suite, we don't need production-level authentication. It's out of the scope of the conformance suite. IMO, it's enough to set up a protocol mapper to return "urn:mace:incommon:iap:silver" to pass this test.

Clarify issues to pass all FAPI R/W OP w/ Private Key conformance tests

By re-running the latest FAPI R/W OP w/ Private Key conformance tests against the latest keycloak to clarify issues to pass all FAPI R/W OP w/ Private Key conformance tests.

keycloak does not check whether Request Object expired based on "exp" claim and return appropriate error

According to FAPI-RW-5.2.2-13(https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server), Request Object shall contain "exp" claim, and it implies that the authz server should rejects the client request with Request Object which has already been expired by judging "exp" claim value. Test case expects "invalid_request_object" error.

Support to check whether "nonce" as a query parameter matches "nonce" claim in a request object and return appropriate error

According to FAPI-RW-5.2.3-8(https://openid.net/specs/openid-financial-api-part-2-ID2.html#public-client), FAPI-R-5.2.3-8(https://openid.net/specs/openid-financial-api-part-1-ID2.html#public-client), nonce is included in both query parameters and a request object and have the same value. keycloak need to check it and return an appropriate error.

Confirm all FAPI R/W OP w/ Private Key conformance tests are passed by the locally built keycloak

Confirm all FAPI R/W OP w/ MTLS conformance tests are passed by the locally build keycloak that the following issues are resolved (not yet sent as PRs).

• KEYCLOAK-15448
• KEYCLOAK-14195
• KEYCLOAK-14204
• KEYCLOAK-14205

clarified by #42

Consider alternative for keycloak-gatekeeper used in FAPI-RW conformance test run environment

The conformance test run environment uses keycloak-gatekeeper.

According to https://groups.google.com/forum/#!topic/keycloak-dev/Jb5iqo3kHXY , the keycloak-gatekeeper and its successor Louketo becomes EOL. Therefore, an alternative for keycloak-gatekeeper is needed in the long run.

It is helpful if someone propose this alternative and replace the current keycloak-gatekeeper with it.

keycloak's app server does not reject TLS1.0, 1.1, insecure cipher suites defined in FAPI-RW-8.5-2

To pass these tests, the keycloak's application server (wildfly) accept only TLSv1.2 and cipher suites defined in FAPI-RW-8.5-2 in Handshake, and reject others.

The following might be helpful :

• https://www.keycloak.org/docs/latest/server_admin/index.html#_enable-mtls-wildfly

• https://docs.jboss.org/author/display/WFLY10/Undertow+subsystem+configuration
  HTTPS Listener - enabled-cipher-suites

• https://stackoverflow.com/questions/33684451/wildfly-ssl-protocol-tlsv1-2-configuration

OAuth2 Client Authentication in [MTLS] : support Server Metadata and Client Registration

keycloak(6.0.0) has already implemented OAuth2 Client Authentication in the way defined in Section 2 of [MTLS]. However, it has not yet supported its Server Metadata advertisement and Client Registration.

FAPI-CIBA Backchannel Authentication Request : support login_hint_token

The design document for FAPI-CIBA states that it requires to support login_hint_token.
However, the current CIBA prototype implementation does not support it.

The goal of this issue is to implement on the CIBA prototype implementation login_hint_token by following the design document for FAPI-CIBA.

Resource Server related FAILURE : received access token verification

Some test module like fapi-rw-id2-ensure-request-object-with-multiple-aud-succeeds-with-mtls and fapi-rw-id2-ensure-request-object-with-multiple-aud-succeeds-with-private-key-and-mtls-holder-of-key checks whether a resource server returns error when it receives invalid access token.
To pass these tests, the resource server verify whether received access token is valid or not by token introspection and returns appropriate response.

Error Response on receiving some token request with other's client certificate in TLS handshake

test module : FAPIRWID2EnsureClientIdInTokenEndpointWithMTLS

When the authz server(keycloak) receives a token request by some client(say client2) including a authorization code issued to other client(say client1) with this client(client1)'s client certificate in TLS handshake, it returns 400 Bad Request / error="unauthorized_client".

CheckTokenEndpointHttpStatus401 and CheckErrorFromTokenEndpointResponseErrorInvalidClient expects 401 Unauthorized / error="invalid_client" while keycloak returns 400 Bad Request / error="unauthorized_client".

Write design document of keycloak's CIBA support

Based on the prototype in #47 , Write design document of keycloak's CIBA support, submit it to keycloak-community repository, and be merged.

OAuth2 Client Authentication in private_key_jwt : support ES256 or PS256

FAPI-RW-ID2(Implementer's Draft ver 2) 5.2.2. Authorization server 14 states that an authorization server shall support at least either [MTLS]
Section 2 or OIDC 9. Client Authentication private_key_jwt as OAuth2 Client Authentication

If supporting private_key_jwt, we need to consider that FAPI-RW-ID2 8.6. JWS algorithm considerations 1 states that at least ES256 or PS256 shall be supported in private_key_jwt.

The current version of keycloak(6.0.0) has already supported private_key_jwt, but only supported RS256 in private_key_jwt.

keycloak does not check whether Request Object include "nonce" claim and return appropriate error

According to FAPI-RW-5.2.3-8(https://openid.net/specs/openid-financial-api-part-2-ID2.html#public-client), FAPI-R-5.2.3-8(https://openid.net/specs/openid-financial-api-part-1-ID2.html#public-client) and OIDCC-3.3.2.6 (https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthError) because FAPI RW uses hybrid flow :

• check whether Request Object does include "nonce" claim
• check whether the value of "nonce" query parameter matches the value of "nonce" claim in the request object exactly
• if not, return the error (error=invalid_request_object) from authorization endpoint such that
  HTTP/1.1 302 Found
  Location: https://client.example.com/cb#error=invalid_request_object&state=xyz

Resource Server related FAILURE : OB-6.2.1-2

CallAccountsEndpointWithBearerTokenExpectingError checks whether a resource server returns an error when a client 1 send an access token issued to a client 2. It checks a requirement of OpenBanking Security Profile section 6.2.1-2.

To pass these tests, the resource server defined as "resourceUrl" in the config file needs to be configured to satisfy a requirement of OpenBanking Security Profile section 6.2.1-2.

This requirement tells that the resource server with the FAPI endpoints shall verify that the client identifier bound to the underlying mutually authenticated TLS transport session matches the client that the access token was issued to. That means we shall use [MTLS] as client authentication, not private_key_jwt. Therefore, this check should be omitted for private_key_jwt testplan.

These test should be omitted because the test plan is for the authorization server (keycloak), not the resource server. And, this test is for OpenBanking Security Profile, not FAPI.

FAPI-RW-5.2.3-3: claims_parameter_supported must be: true

The test module CheckDiscEndpointClaimsParameterSupported expects the discovery endpoint returns claims_parameter_supported = true. But keycloak returns false.

FAPI-RW-5.2.3-3 describes the client shall request user authentication by requesting the acr claim as an essential claim. It means OP needs to support use of the claims parameter.
When OP supports the parameter, the discovery endpoint should return claims_parameter_supported = true.

FAPI-CIBA Implementation Internals : Use Only Auth Result Cache on Communication with Decoupled Auth Server

The design document for FAPI-CIBA states that it requires Auth Result ID for CIBA flow session binding between keycloak and Decouple Auth Server.
However, the current CIBA prototype implementation uses decoupled_auth_id, not Auth Result ID.

The goal of this issue is to modify the CIBA prototype implementation to use Auth Result ID for CIBA flow session binding between keycloak and Decouple Auth Server by following the design document for FAPI-CIBA.

Task lists and their progresses are as follows.

• Clarify which parts are affected and how by removing Decoupled Req Cache
  • Clarify which fields of Decoupled Req Cache are used and how
• Migrate some Decoupled Req Cache fields to Auth Result Cache if necessary
  • Move the fields of Decoupled Req Cache identified by the previous task to Auth Result Cache
  • Run existing CIBATest for regression
• Remove Decoupled Req Cache
  • On communication between keycloak and Decoupled Auth Server, replace decoupled_auth_id with Auth Result ID, which requires changing the source of reference implementation of Decoupled Auth Server and the interface specification between keycloak and Decoupled Auth Server
  • Running existing CIBATest for regression

keycloak does not check whether Request Object's "aud" indicates keycloak and return appropriate error if not

OpenID Connect section 6.1 (https://openid.net/specs/openid-connect-core-1_0.html#RequestObject) tells that

The aud value SHOULD be or include the OP's Issuer Identifier URL.
Test case expects "invalid_request_object" error.

FAPI-CIBA Backchannel Authentication Request : encrypt/decrypt login_hint

The design document for FAPI-CIBA states that it requires login_hint encryption and decryption.
However, the current CIBA prototype implementation does not support it.

The goal of this issue is to implement on the CIBA prototype implementation login_hint encryption and decryption by following the design document for FAPI-CIBA.

FAPI-CIBA Backchannel Authentication Request : support id_token_hint

The design document for FAPI-CIBA states that it requires to support id_token_hint.
However, the current CIBA prototype implementation does not support it.

The goal of this issue is to implement on the CIBA prototype implementation id_token_hint by following the design document for FAPI-CIBA.

Resource Server related FAILURE : x-fapi-interaction-id

CheckForFAPIInteractionIdInResourceResponse and EnsureMatchingFAPIInteractionId checks x-fapi-interaction-id (FAPI-R-6.2.1-11, 12) in HTTP response header from Resource Server.

To pass these tests, the resource server defined as "resourceUrl" in the config file needs to be configured to satisfy x-fapi-interaction-id related requirements (FAPI-R-6.2.1-11, 12).

These test should be omitted because the test plan is for the authorization server (keycloak), not the resource server.

FAPI-CIBA Backchannel Authentication Request : support Signed Authentication Request

The design document for FAPI-CIBA states that it requires to support request (Signed Authentication Request).
However, the current CIBA prototype implementation does not support it.

The goal of this issue is to implement on the CIBA prototype implementation request (Signed Authentication Request) by following the design document for FAPI-CIBA.

keycloak does not refuse response_type parameter other than response_type=code id_token or code id_token token

FAPI-RW-5-2.2 implies that an authorization server shall refuse response_type parameter other than response_type=code id_token or code id_token token.

keycloak should return error=unsupported_response_type to Client via user's Browser's redirection.

Such the refusion might been adopted per Client.

keycloak does not check whether Request Object include "scope" claim and return appropriate error

According to FAPI-RW-5.2.3-8(https://openid.net/specs/openid-financial-api-part-2-ID2.html#public-client), FAPI-R-5.2.3-7(https://openid.net/specs/openid-financial-api-part-1-ID2.html#public-client) and OIDCC-3.3.2.6 (https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthError) because FAPI RW uses hybrid flow :

• check whether Request Object does include "scope" claim
• check whether the value of "scope" query parameter matches the value of "scope" claim in the request object exactly
• if not, return the error (error=invalid_request_object) from authorization endpoint such that
  HTTP/1.1 302 Found
  Location: https://client.example.com/cb#error=invalid_request_object&state=xyz

keycloak does not check whether Request Object include "exp" claim and return appropriate error

According to FAPI-RW-5.2.2-13(https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server) and OIDCC-3.1.2.6(https://openid.net/specs/openid-connect-core-1_0.html#AuthError), keycloak should

• check whether Request Object does include "exp" claim
• if not, return the error (error=invalid_request_object) from authorization endpoint such that
  HTTP/1.1 302 Found
  Location: https://client.example.com/cb?error=invalid_request_object&state=xyz

Advertise "acr" claim in "claims_supported" Server Metadata

FAPIRWCheckDiscEndpointClaimsSupported checks whether "claims_supported" in Server Metadata includes "acr" or not.

keycloak has already support "acr" claim in ID token. Therefore, keycloak should advertise "acr" in "claims_supported" in Server Metadata.

Keycloak (WildFly) returns TLS error when accessing from Chrome or curl

Currently, we setup MTLS in WildFly layer. But I encountered TLS error when I used Chrome or curl command. When I used IE or Edge, they were OK. Also, when I used curl command from the keycloak server, it was OK.

It might be same issue with WFLY-11007 Using OpenShift generated certificates and client auth cause TLS errors. It seem that WildFly returns TLS error when it is configured TLS with client auth.

WildFly debug log

keycloak_1             | 16:09:13,386 DEBUG [io.undertow.request] (default I/O-2) UT005013: An IOException occurred: javax.net.ssl.SSLException: Received fatal alert: record_overflow
keycloak_1             |        at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
keycloak_1             |        at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
keycloak_1             |        at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
keycloak_1             |        at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
keycloak_1             |        at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
keycloak_1             |        at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
keycloak_1             |        at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
keycloak_1             |        at io.undertow.protocols.ssl.ALPNHackSSLEngine.unwrap(ALPNHackSSLEngine.java:265)
keycloak_1             |        at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
keycloak_1             |        at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.unwrap(ALPNLimitingSSLEngine.java:75)
keycloak_1             |        at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:757)
keycloak_1             |        at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:648)
keycloak_1             |        at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:63)
keycloak_1             |        at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1136)
keycloak_1             |        at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
keycloak_1             |        at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)

Error case with curl

curl --version
curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

curl https://as.keycloak-fapi.jic.openstandia.jp/ -v
*   Trying 34.208.200.141...
* TCP_NODELAY set
* Connected to as.keycloak-fapi.jic.openstandia.jp (34.208.200.141) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* error:1408F092:SSL routines:ssl3_get_record:data length too long
* stopped the pause stream!
* Closing connection 0
curl: (35) error:1408F092:SSL routines:ssl3_get_record:data length too long

No error case with curl

curl --version
curl 7.61.1 (x86_64-koji-linux-gnu) libcurl/7.61.1 OpenSSL/1.0.2k zlib/1.2.7 libidn2/2.0.4 libssh2/1.4.3 nghttp2/1.31.1
Release-Date: 2018-09-05
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy Metalink
[ec2-user@ip-172-31-4-86 keycloak-fapi]$ curl https://as.keycloak-fapi.jic.openstandia.jp/ -v
*   Trying 34.208.200.141...
* TCP_NODELAY set
* Connected to as.keycloak-fapi.jic.openstandia.jp (34.208.200.141) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=as.keycloak-fapi.jic.openstandia.jp
*  start date: May 22 00:22:19 2019 GMT
*  expire date: Aug 20 00:22:19 2019 GMT
*  subjectAltName: host "as.keycloak-fapi.jic.openstandia.jp" matched cert's "as.keycloak-fapi.jic.openstandia.jp"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xa2bb70)
> GET / HTTP/2
> Host: as.keycloak-fapi.jic.openstandia.jp
> User-Agent: curl/7.61.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< last-modified: Mon, 04 Mar 2019 07:16:57 GMT
< content-length: 1087
< content-type: text/html
< accept-ranges: bytes
< date: Thu, 23 May 2019 16:05:33 GMT
<
<!--
  ~ Copyright 2016 Red Hat, Inc. and/or its affiliates
  ~ and other contributors as indicated by the @author tags.
  ~
  ~ Licensed under the Apache License, Version 2.0 (the "License");
  ~ you may not use this file except in compliance with the License.
  ~ You may obtain a copy of the License at
  ~
  ~ http://www.apache.org/licenses/LICENSE-2.0
  ~
  ~ Unless required by applicable law or agreed to in writing, software
  ~ distributed under the License is distributed on an "AS IS" BASIS,
  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  ~ See the License for the specific language governing permissions and
  ~ limitations under the License.
  -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
    <meta http-equiv="refresh" content="0; url=/auth/" />
    <meta name="robots" content="noindex, nofollow">
    <script type="text/javascript">
        window.location.href = "/auth/"
    </script>
</head>
<body>
    If you are not redirected automatically, follow this <a href='/auth'>link</a>.
</body>
</html>
* Connection #0 to host as.keycloak-fapi.jic.openstandia.jp left intact

Confirm all FAPI R/W OP w/ MTLS conformance tests are passed by the released keycloak

Confirm all FAPI R/W OP w/ MTLS conformance tests are passed by the released keycloak to which all PRs for FAPI-RW are merged.

We can work with this issue after the following events :

• All PRs for FAPI-RW are merged.
• keycloak is released to which all PRs for FAPI-RW are merged.
• Container image for this version of keycloak is released.

Please note that the test environment is clarified and recorded (e.g. conformance test ver, keycloak ver, etc..).

Error Response on receiving some client's JWS Client Assertion signed by other client's private key

test module : FAPIRWID2EnsureClientIdInTokenEndpointWithPrivateKeyAndMTLSHolderOfKey

When the authz server(keycloak) receives some client's(say client2) JWS Client Assertion signed by other client's(say client1) private key, it returns 400 Bad Request / error="unauthorized_client".

CheckTokenEndpointHttpStatus401 and CheckErrorFromTokenEndpointResponseErrorInvalidClient expects 401 Unauthorized / error="invalid_client"

In keycloak, JWTClientAuthenticator processes JWS Client Assertion. At first, it read "sub" as client_id (https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) and searches the public key registered by this client identified by client_id, along with "kid" in JWS Client Assertion's JOSE Header.

In this case, keycloak looks into client2's public key store to find client1's public key, which leads to "not find".

Error Response on receiving some token request without the client certificate in TLS handshake

When the authz server(keycloak) receives a token request by some client without the client certificate in TLS handshake, it returns 400 Bad Request / error="unauthorized_client".

CheckTokenEndpointHttpStatus401 and CheckErrorFromTokenEndpointResponseErrorInvalidClient expects 401 Unauthorized / error="invalid_client" while keycloak returns 400 Bad Request / error="unauthorized_client".

From release-v3.2.6, it seems to be OK that test suite can accept the following error patterns :

400 error=invalid_request
400 error=invalid_client
401 error=invalid_client

FAPI-CIBA Realm Settings (CIBA Policy) overriden by Client Settings

The design document for FAPI-CIBA states that it requires Realm Settings for CIBA called CIBA Policy and it can be overriden by each Client Setting.
However, the current CIBA prototype implementation does not support the Client Setting for CIBA that can override the Realm Setting for CIBA.

The goal of this issue is to implement on the CIBA prototype implementation this override by following the design document for FAPI-CIBA.

FAPI-CIBA Implementation Internals : Token Request Throttling Information Not Cluster-wide Sync

The design document for FAPI-CIBA states that it requires No.3 method for Token Request Throttling, namely keycloak does not share information on Token Request Throttling among other nodes in the cluster.
However, the current CIBA prototype implementation employes No.2 method, namely keycloak shares information on Token Request Throttling among other nodes in the cluster.

The goal of this issue is to modify the CIBA prototype implementation to use No.3 method for Token Request Throttling by following the design document for FAPI-CIBA.