Moved client cert checking into Authenticator #273
Conversation
…or client certs is implemented as an Authenticator instead. Partially implements jolokia#223, but it retains backward compatibility with the current configuration.
… is used when you enable basic auth and client cert based auth at the same time.
| for (Rdn rdn : principal.getRdns()) { | ||
| if (!certPrincipalRdns.contains(rdn)) { | ||
| throw new SecurityException("Principal " + certPrincipal + " not allowed"); | ||
| } |
There was a problem hiding this comment.
I will take over the fix from the other PR here.
|
LGTM, thanks ;) I will update the documentation accordingly. A new Jolokia release (1.3.4) is expected at the end of this or beginning of next week. |
|
There will be still a problem for our use case, since the client certificate will be validated still that is signed by a CA. This happens before the authenticators are called, when setting up the HTTPS subsystem. So I'm afraid that its not possible to have SSL with allowing both, client cert authentication and basic authentication without a prior client cert verification. The authenticator is used only for some extra checks, like whether the presented certificate is indeed a client certificate (and not a server certificate), and whether the enclosed principal matches a configured value. The check, whether a client cert is presented and whether it is signed by a given CA (stored in the keystore) happens before, internally in the HttpsServer which we cant influence much except for configuring it. |
|
Yeah I think that limitation is ok. In the case a client does not have cert trusted by the CA, he should not do SSL with the cert at all. |
|
But how can you provide a Pod specific client cert signed by the OpenShift CA when running from a Pod ? |
Also support enabling client cert and other auth modes at the same time.