FISH-5769 RFC2253 format with Certificate HAM, fix role verification

[OndroMih]

Description

This is a bug fix.

The problem: When authenticated using @CertificateAuthenticationMechanismDefinition and IdentityStore @CertificateIdentityStoreDefinition, and when a role is mapped to a particular certificate principal in payara-web.xml, the role isn't assigned to the authenticated user. The role is applied if CLIENT_CERT login config mechanism is defined in web.xml.

Proposed solution in this PR:

• in JaccWebAuthorizationManager, if the role isn’t granted (potentially because of the mismatch between PrincipalImpl and CallerPrincipal), check if the current principal class is CallerPrincipal. If that's true, convert it to PrincipalImpl and check for the role again
• In CertificateCredentialImpl, change how the CallerPrincipal is created so that it contains the name in the same RFC2253 that PrincipalImpl uses so that it’s equal with the one in the policy. This will ensure that the PrincipalImpl created from CallerPrincipal is equal to the one in the policy

Important Info

Testing

Manually tested with the reproducer attached to FISH-5769

Testing Environment

Ubuntu

Notes for Reviewers

The policy in JaccWebAuthorizationManager contains the same role policies as in the working case (when using Servlet authentication). These are stored in the file generated/policy/payara-certificate-realm/payara-certificate-realm/granted.policy. These policies are for principal class PrincipalImpl but, if Jakarta Security authentication is used, the passed ProtectionDomain with the authenticated user contains a principal of type CallerPrincipal from Jakarta Security API. The policy object then refuses to add a policy for the role because it doesn’t match the authenticated user principal.

There are more observations:

• Jakarta Security CallerPrincipal class doesn’t override hashCode and equals methods, therefore even 2 instances with the same principal name are not equal. So it doesn’t help if an additional role policy for CallerPrincipal is added to the granted.policy file
• The CallerPrincipal has a slightly different name than the PrincipalImpl. Both contain the certificate's distinguished name but it's in RFC2253 format for PrincipalImpl and in RFC1779 format for CallerPrincipal. For this reason, even if we somehow converted CallerPrincipal to PrincipalImpl, they wouldn't be equal unless we also convert the format of the principal's name. The RFC1779 format contains more spaces between attributes and is obsolete.

[OndroMih]

Jenkins test please

[kalinchan]

jenkins test please

[breakponchito]

LGTM