What is a Security Realm?
A security realm in Payara Server is a component used to authenticate users. Despite all the complicated terminology used in Java EE security, which is not helped by different application servers having their own terminology to describe the same thing, that’s fundamentally all it is. The ‘certificate’ realm is a Payara Platform-specific component used to authenticate users using a certificate store. This will be used, for example, in client certificate authentication.
What Are the New Changes to the Realm in Payara Server 5.192?
Before Payara Server 5.192, any client certificate had to be referred to using it’s full distinguished name. This followed RFC 2253, which generally looked like so:
CN=Matt Gill,O=Payara Services,C=GB
In some particular cases, this name would be huge, resulting in payara-web.xml entries like this:
<security-role-mapping>
<role-name>secure-role</role-name>
<group-name>secure-group</group-name>
<principal-name>EMAILADDRESS=example-user@payara.fish, CN=Example User, O=Payara Services, L=Malvern, ST=Worcestershire, C=GB</principal-name>
</security-role-mapping>
Obviously this is not ideal. Payara Platform 5.192 introduced a property called:
common-name-as-principal-name
to the certificate realm. When set to true, each certificate can instead be referenced by only its common name. This would change the massive code block above to a more manageable:
<security-role-mapping>
<role-name>secure-role</role-name>
<group-name>secure-group</group-name>
<principal-name>Example User</principal-name>
</security-role-mapping>
How Do I Configure This Feature?
See our documentation for information on how to configure this property. The server should be restarted once the configuration option is set. Once configured correctly, certificates can be referenced anywhere using just the common name instead of the full distinguished name.
What Now?
This feature helps with just a small part of Java EE security. Java EE security is a much larger topic which, as mentioned before, is rather confusing in places. If Java EE security still seems rather confusing, check out our blog explaining the different security components and what they do.
Give Payara Server 5.192 a Try:
4 minutes
Great to be able to map just the CN. Strange this hasn’t been in the Java EE standards. Our architect steers us away from using product specific features, and we can only really use it if we must.
As you guys are leading the Java EE Security project , are you planning to put this certificate feature in Java EE Security and Soteria?
Hi Paul,
As Jakarta EE is now open source we’re hoping there will be more momentum on adding things like this! We will open this issue on the project, and we hope to be able to see it implemented as soon as possible.
Kind regards,
Matt
Hi Matt,
Thanks! This is quite important to have. Certificates are so powerful, but have been left in the dark for ages.
One more question, you don’t have to hope to have it implemented, have you? You can just do it as leaders, or do you still have to get permission from Oracle or Eclipse?
Hi Paul,
It depends on exactly which specification exactly this issue concerns. We’re investigating the best way to add this to Jakarta but, depending on which specification is the most appropriate, we may have more or less power to directly implement it.
Rest assured we don’t plan to ignore this, however.
Kind regards,
Matt
Hi Matt,
Thanks for your reply again. What are the options you are looking at?
Java EE Security has the realms, but Servlet has the client-cert auth, is that what you mean? You are leading Java EE Security, but not Servlet are you?
Because this is a realm and mapping issue, I think it should go in Java EE Security?