Split SubjectParser code in Application server specific classes

[glassfishrobot]

The SubjectParser contains package names for different servers within Strings.

This leads to some unmaintainable code.

Proposal (see also https://github.com/javaee-security-spec/soteria/issues/69#issuecomment-308394262) is to create separate maven artifacts with the application server specific code.

Proposal

• Interface with methods to retrieve caller and groups (getGroupsFromPrincipals, getCallerPrincipalFromPrincipals, ...)
• Server specific project contains an implementation of the interface which is defined as CDI bean. CdiUtils#getBeanReference(java.lang.Class<T>, java.lang.annotation.Annotation...) can be used then to retrieve the implementation.

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/security-soteria/issues/71
• Original Issue Raised By:@rdebusscher
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@wmhopkins Commented Copying comments from description of duplicate issue #159:

The SPI plugins, like SubjectParser, that SecurityContext depends on to return the correct values on various platforms need to be refactored. Ideally, this would be structured as a per-platform SPI implementation that handles all necessary methods for platform, rather than, as currently, a single delegate class with lots of per-platform conditional code in the body of many methods. The latter approach results in a large class that's difficult to understand and maintain. It's too easy to return the wrong result when trying to implement a method that works for all platforms.

As an example, the current implementation of SubjectParser.doGetCallerPrincipalFromPrincipals() begins with a large case statement, checking for a large number of platform-specific principal types, before delegating to HttpServletRequest or EJBContext if none of the specific types are found. That implementation is very brittle in the face of changes to a platform, or if an application chooses to use one of the listed types in a non-standard way.

See also issues #158 and #133, and PR #140.

[ggam]

Just a note that I'm right now working on this.