[
https://java.net/jira/browse/JASPIC_SPEC-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=384900#comment-384900 ]
arjan tijms commented on JASPIC_SPEC-17:
----------------------------------------
{quote}.but you might want to take a look at it
https://java.net/projects/nobis/sources/git/content/Nobis/authentication/relying-party-utilities/src/main/java/org/glassfish/nobis/auth/rp/util/ServletSamHelper.java {quote}
Thanks for the pointer. Yes, that one is indeed a similar kind of helper / ease of use class.
{quote}I am not sure I fully understand the need for a new context object, but perhaps you are looking for some form of unification of initialization and request processing contextual objects of the existing SPI {quote}
The context object is not intended to really introduce any new capabilities, but just encapsulate the various data items a SAM uses in one convenient to use utility class.
For instance, the proposed {{AuthStatus notifyContainerAboutLogin(String username, List<String> roles)}} utility method would need for its implementation at least the (client) subject, and the handler. The idea here is that this context object holds these two data items in addition to things like the message info object and module options.
That way the user doesn't have to pass these data items to the methods that need them all the time. If the {{notifyContainerAboutLogin}} method would be a base class method that naturally wouldn't be needed either, but an additional wish (not stated in this issue) is to not have an HTTP specific base class, but to delegate to an HTTP specific SAM-like type. This type would then get the (subject, handler, module options, message info, ...) via one "holder" (context) object instead of via 5 or more separate parameters.
I experimented with such context object here:
https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/core/HttpMsgContext.java
It can be seen in action here:
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
(in the delegation variant, the {{TokenAuthModule}} would not extend {{HttpServerAuthModule}} but probably implement some interface instead and possibly have a CDI qualifier annotation)
Of course all of the utility/helper code implemented thus far is just to experiment with the various ideas.
> 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)