CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them.
- Should be possible to authenticate users by certificate without database of all certificates - does not matter if in LDAP, keystore or anything, CA certificate should be sufficient. (Database of users alone can stay required.)
- To provide replacement for legacy truststore authentication (see Client-Cert SSL Authentication Migration)
To obtain user identity authenticated using SSL certificate it is necessary to use CLIENT_CERT http-authentication-mechanism. It use security-realm to verify X509Evidence. The security realm usually contain database of user identities with their certificates and verify the certificate against it. There are currently two realms which allows support this type of evidence:
- LdapSecurityRealm - requires to have certificate serial/digest of something in LDAP
- KeyStoreBackedSecurityRealm - which requires to have certificates of all users in the keystore (CA certificate is not sufficient)
To provide legacy truststore authentication replacement it should be possible to authenticate users only by CA signature on their certificates, without database of all certificates. Not everytime is such database desirable or possible.
To provide an option of CLIENT-CERT mechanism to skip X509Evidence verification. The identity will still need to exist in security realm, but information about certificates will not have to be there.
The verification needs to stay enabled by default for back compatibility and to not decrease security when keeping old configuration on upgrade.
There is still needed database of users for authorization. Post-realm-principal-transformer can be used to transform any username to one constant dummy user, whose authorization attributes would be shared by all users authenticated using certificate.
Jan Kalina - firstname.lastname@example.org
Martin Choma - email@example.com
Priyanka Nag - firstname.lastname@example.org