JASPIC as it's currently defined has an exceptionally flexible and abstract API. It can handle authentication for different kinds of environments, which are defined in profiles. Profiles demand certain behavior and specific keys to be present in otherwise generic maps that are used throughout the API.
While this indeed makes the API flexible, it comes at the cost of a reduced ease-of-use. Developers wishing to program for e.g. the Servlet Profile have to read through documentation to see in what way they need to fulfill the contract of the profile and which keys can be inserted or retrieved from the mentioned maps. A certain amount of casting from type Object is also required to work with the profile.
This required effort can likely be significantly reduced by the introduction of specific Java types for a profile. The Servlet spec uses something similar to this. There is a GenericServlet which is protocol independent and an HtppServlet that's provided as a convenience for HTTP usage (which is overwhelmingly the common usage).
In practice those specific types are already created by JASPIC users, e.g. JBoss uses WebServerAuthModule as a Servlet Profile specific base class for a ServerAuthModule, and in OmniSecurity we're prototyping a base class as well with HttpServerAuthModule.
A standardized convenience ServerAuthModule base class for the Servlet Profile could have the following properties:
- Default implementation of getSupportedMessageTypes returning the two mandated classes.
- Default initialize that just stores the incoming parameters for later retrieval
- Default secureResponse just returning a success status
- Default cleanSubject that just removes the Principals from the given Subject
- A new validateRequest method that has HttpServletRequest and HttpServletResponse as parameters and perhaps a context object of some kind (e.g. called HttpMsgContext or something similar (just like ServletContext, FacesContext, etc).
The context object mentioned above can contain a number of convenience methods for working with the Servlet Profile, e.g.
- an isProtected method corresponding to the javax.security.auth.message.MessagePolicy.isMandatory key.
- a registerWithContainer(String, List<String>) method as a convenience shortcut for working directly with the CallerPrincipalCallback and GroupPrincipalCallback
- a setRegisterSession and isRegisterSession corresponding to the javax.servlet.http.registerSession key.
- getters for the (raw) MessageInfo, Subject parameters of the super validateRequest method and the CallbackHandler that was passed into the initialize method.
The above mentioned types, names, and semantics are just examples to kickoff a discussion about this matter. Note that the proposed convenience types and methods are just conveniences and should never be the only way to work with the API.