-
-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MTLS client authentication and certificate bound access tokens #661
Comments
@aeneasr I have an implementation for this that I can contribute. Please let me know if there's interest. |
I think until RFC becomes a standard and not just proposed standard, this will not be accepted. |
It isn't draft. It's been the only full RFC for sender constrained access tokens. You might be thinking about DPoP. |
Oh, sorry. I misread. Ignore my comment. |
If we implement Regarding the mTLS handshake, would that not be trivial to implement using Go's HTTPS infrastructure? Or are there specifics required to deal with mTLS? |
@aeneasr With regards to the mTLS handshake, the infrastructure is unlikely to use the OAuth provider as the edge. SSL handshakes would be typically intercepted at an edge service like F5, Akamai, Cloudflare etc and the typical architecture I have seen is where they perform the mutual trust handshake and send down the client certificate as a header to the OAuth provider. Also, this is Fosite and not Hydra. Certainly the web interface to enforce mTLS can be added to Hydra. |
I see, that makes a lot of sense. Is the header where the certificate is included somehow standardized across these providers? Regarding |
@aeneasr You really need to learn how to take vacation 😁 The header approach is very common. Akamai, for example, offers the ability to include the full PEM and/or parsed PEM attributes. Most proxies offer this, nginx included. I suggest if Oathkeeper (the ory proxy? Cool names BTW) doesn't, you might consider enhancing it to make this available for people who want to use a pure ory solution with DNS resolution leading direct to Oathkeeper. In my own implementation, we use Akamai as the SSL termination point and it does the job of sending down the PEM post-mTLS handshake. I can see the value of Edit: Your question regarding a standard cert header name... there isn't one, which is why I am proposing this as a new property we add to compose.Config ( |
I see, that makes sense to me! Is the format at least standardized?
That makes sense to me, I think it will be useful for guides and examples that allow one to get off the ground quickly!
That's a good proposal, we'll include it in the scope of the Ory Oathkeeper refactoring :)
I know 😅 |
The certificate format is usually url-encoded pem but the proxy may also have the ability to send certificate attributes and computed values. Here's a snippet from Cloudflare:
I know Akamai can be configured to send the pem cert. |
I see, in that case it probably makes sense to have an interface defined which can be implemented for different providers (Akamai, Cloudflare, ...) as it sounds like everyone is doing this a little differently? That way, we could probably do away with the custom header config and just rely on the provider? We can also implement a generic provider which is a bit configurable to cover common use cases? |
OK that makes sense. Maybe a tailored session interface that provides functions to get pem or specific attributes or the computed fingerprint? |
makes sense! |
Hello contributors! I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic. Unfortunately, burnout has become a topic of concern amongst open-source projects. It can lead to severe personal and health issues as well as opening catastrophic attack vectors. The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone. If this issue was marked as stale erroneously you can exempt it by adding the Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you! Thank you 🙏✌️ |
I have a little bit of information about this, though fairly unhelpful as it was basically already mentioned. It seems that other providers provide instructions for the proxy admin on how it is to be configured. For example this is KeyCloak's instructions. The interface is easily the best option as already mentioned as it's provider agnostic. Reasonably it could be accompanied with an implementation which just requires the appropriate header names which assumes the contents are using the url-encoded PEM which should suffice for most cases. |
Yes, I need to get back to contributing here. Assuming this is still of interest, I will try to get this in place over the next couple weeks. |
Hello contributors! I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic. Unfortunately, burnout has become a topic of concern amongst open-source projects. It can lead to severe personal and health issues as well as opening catastrophic attack vectors. The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone. If this issue was marked as stale erroneously you can exempt it by adding the Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you! Thank you 🙏✌️ |
Preflight checklist
Context and scope
The context of this implementation is covered by the RFC. The proposal is to support
tls_client_auth
(but notself_signed_tls_client_auth
) and certificate based token binding.Goals and non-goals
Goals
Non goals
self_signed_tls_client_auth
The design
The proposal is to add the following:
CertBoundTokenSession
that exposes functions such asGetCertificate
andSetConformationClaim
CertBoundTokenHandler
that generates the thumbprint and implements the token handler interfaceTLSAuthenticatedClient
interface that extends theClient
interface to add functions that indicate the certificate attribute to be compared and whether certificate binding is enabled.TLSAuthenticatedClient
.APIs
N/A. This is an update to Fosite.
Data storage
No new storage interface required.
Code and pseudo-code
No response
Degree of constraint
No response
Alternatives considered
No response
The text was updated successfully, but these errors were encountered: