[
https://java.net/jira/browse/JASPIC_SPEC-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=384877#comment-384877 ]
alex.kosowski commented on JASPIC_SPEC-17:
------------------------------------------
The JSR 375 EG proposes moving JASPIC_SPEC-17 to
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC. JSR 375 is focused on Application Development security ease of use, and adding an ease-of-use layer on top of JASPIC seems appropriate for JSR 375.
> Servlet profile specific types to increase ease of use
> ------------------------------------------------------
>
> Key: JASPIC_SPEC-17
> URL: https://java.net/jira/browse/JASPIC_SPEC-17
> Project: jaspic-spec
> Issue Type: New Feature
> Reporter: arjan tijms
>
> 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|http://docs.oracle.com/javaee/6/api/javax/servlet/GenericServlet.html] which is protocol independent and an [HtppServlet|http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServlet.html] 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|http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-web/7.1.0.Beta1b/org/jboss/as/web/security/jaspi/modules/WebServerAuthModule.java#WebServerAuthModule] as a Servlet Profile specific base class for a ServerAuthModule, and in OmniSecurity we're prototyping a base class as well with [HttpServerAuthModule|http://code.google.com/p/omnisecurity/source/browse/src/org/omnifaces/security/jaspic/HttpServerAuthModule.java].
> 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.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)