Closed tkan145 closed 2 months ago
APIcast does not validate the client (downstream) certificate as regular validation, it only does validation specified in OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. Am I right? If so, shouldn't APIcast validate the certificate as well (it would require cacerts that signed the client cert)?
According to the spec, we only need to verify the thumbprint. And I think user can use TLS Client Certificate Validation if they wish to validate the certificate.
In the verification steps, there is an unknown "keycloak_mtls.json". Maybe leftovers of past tries? Good catch! I tried to automate dev-env and provide necessary information to make testing easier. I will submit another PR to update dev-env once this one is merged.
In the verification steps, make gateway command is missing. (which somewhat important :) ) Hehe fixed.
The verification steps tell that the created client should have enabled the "OAuth 2.0 Mutual TLS Certificate Bound Access Token". Is this really necessary? Maybe it is the setting that adds the cnf claim to the JWT?
Yes it is the settings that will calculate the certificate hash and adds cnf
claim to the JWT.
There is no user generated in keycloak. That means that there is no need for users in keycloak and the client cert is enough as user ID? If so, any user with a certificate signed with the same cacert defined for keycloak can get the token?
I believe so, FAPI spec also pointed it out as below:
The use of [MTLS](https://tools.ietf.org/html/rfc8705) for client authentication and sender constraining
access tokens brings significant security benefits over the use of shared secrets. However in some
deployments the certificates used for [MTLS](https://tools.ietf.org/html/rfc8705) are issued by a Certificate
Authority at an organization level rather than a client level. In such situations it may be common for an
organization with multiple clients to use the same certificates (or certificates with the same DN) across
clients. Implementers should be aware that such sharing means that a compromise of any one client, would
result in a compromise of all clients sharing the same key.
The verification steps miss the client configuration "allow regexp pattern"
Fixed
I wonder if this "OAuth 2.0 Mutual TLS Certificate Bound Access Token" use case deserves its own dev env. Mainly because if I want to reproduce this, I would need to come back to this PR and re-do the verification steps. If not dev-env, maybe developer oriented readme?? what do you think?
Agree
No need to get the APICast IP, just need to update the docker-compose.yml and add 8443 port to the gateway service:
:+1:
What
This PR support https://issues.redhat.com/browse/THREESCALE-11019.
Verification steps:
Prepare certificates
Generate CA certificate
changeit
as keystore passwordGenerate a certificate signing request (CSR) for the HTTPS keystore.
yes
toTrust this certificate? [no]:
questionWe can verify the certificates are imported with below command.
Generate client certificate
Generate APIcast certificates
Repeat the step above and generate the client certificate
Once the certificate are generated, we are ready to deploy Keycloak
Deploy
https://localhost:9443
admin:adminpass
basic
realmClients -> Create client
Credentials
tab and selectX509 Certificate
asClient Authenticator
Subject DN
, in this test we use(.*?)(?:$)
. Then clickSave
Advanced
tab, and then scroll down toAdvance settings
and enableOAuth 2.0 Mutual TLS Certificate Bound Access Token
-> clickSave
Request token
Now we have everything set up, we can use curl to authenticate with the client certificate to get the access token.
cnf
claim and its value is certificate sha256 thumbprint. The resource server (APIcast) will use this thumbprint to validate if the same user is making the request. For example:Now we are ready to test
Send request
Request should failed with
{"error": "invalid_token"}
Send request again with client certificates
Request should return 200