Affects Version/s: None
Fix Version/s: EJBCA 6.14.0
Issue discovered during:Integration
Sprint:EJBCA Sprint 14
In order to open up for other types of authentication to the Admin GUI than X.509 Client Certificate, we need to be able to
- disable the hard-coded check that such certificate is present and
- perform other types of authentication (or at least prepare a hook for such)
Existing installations might implicitly rely on this check to prevent tokens of other types full access to the Admin GUI.
→ (runtime overridable) file system variable that defaults to keep require client certificate to ensure to not open up any security issues for existing installations.
Since a rough DBA could add RoleMembers of types that are easy to use (he/she might have a hard time getting a client TLS cert by the right CA).
→ the comment of this property should recommend enabling database integrity protection on at least the RoleMemberData table.
EJBCA'a AdminGUI might rely on assumptions about "dual authenticated TLS being present anyway" that locks down the attack surface. Probably not, but this is the right time to double check this.
- Admin preference settings are currently hard-coded and retrieved based on client certificate finderprint
- WebAuthenticationProviderSessionBean bravely assumes that AuthenticationSubject.credentials is of type Set<X509Certificate>
- We could ask RoleMember*Session for the types of configured matching to future proof this a bit. There is not point in doing Http header auth if there are no such RoleMembers...