org.jboss.as.webservices.util.SubjectUtil includes logic that uses the java.security.acl.Group class when translating to/from Elytron SecurityIdentity objects and Subject instances that theoretically might have old-style "CallerPrincipal" and "Roles" principals.

I propose to add a static initializer to check if Group is loadable, and if it is not bypass the code that uses it.

For the 'fromSecurityIdentity' method, if Group is not loadable simply store individual NamePrincipal objects for each role, and skip adding the 'CallerPrincipal' group. The CXF DefaultSecurityContext looks like it will handle a Subject configured that way. Logic there and in JBossWS SubjectCreatingInterceptor and SubjectCreatingPolicyInterceptor work by examining the Subject's principals and taking the first that isn't a 'Group' as the subject's identity, and then DefaultSecurityContext will treat other principals as being role names. So, as long as the securityIdentity.getPrincipal() is the first principal added to the Subject, other principals can be added that represent roles using NamePrincipal and not a Group.

The technique of using the 'CallerPrincipal' Group I believe is a JBoss/WildFly-specific thing done by legacy security code, and any WF code running on JDK 14 or later will not be using logic that finds the 'caller principal' that way; it will be using Elytron.

For the 'convertToSecurityIdentity' method, if the Group class is not loadable then it's not possible for the Subject to have any instances of it to iterate over to populate the SecurityIdentity.