Hi,
On Thu, May 7, 2015 at 10:54 AM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> But anyway, I found a few interesting things that maybe needs to be
> clarified.
>
> - How can we define the authentication method in web.xml with JASPIC?
>
> You don't at the moment, which I think is confusing indeed. That's why I
proposed looking at this as the first step of
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-19
What now happens is that when you configure a JASPIC server authentication
module (programmatically or at the container level), it completely replaces
the authentication method defined in web.xml. For clarity the
authentication method should therefore be completely omitted from web.xml.
>
> - How can we define the URL paths which are protected?
>
> In the same that they are defined when one of the four standard
authentication methods are used; via the security-constraint element in
web.xml and annotation equivalents.
>
> - SecurityContext needs to access the JASPIC helper class
> HttpMsgContext, but is not available there.
>
> HttpMsgContext is only available from within an authentication module. I
haven't yet looked at what your SecurityContext exactly does, but I'm
guessing that you try to authenticate using HttpMsgContext at a random
place.
This is not entirely how it works. You can compare this to using
FacesContext in JSF when not actually being in the context of the
FacesServlet.
What you can do however is *trigger* authentication by calling
HttpServletRequest#authenticate. You can do this at any moment during
request processing. This will result in the SAM(s) that you have configured
being called. From the SAM you then use HttpMsgContext.
A static convenience method in the experimental code to do this is this
one:
https://github.com/AdamBien/secspike/blob/master/todo/src/main/java/org/omnifaces/security/jaspic/core/Jaspic.java#L77
>
> - Assumed that when the user isn't authenticated the Principal name is
> *ANONYMOUS* . But this isn't standardized.
>
> In Servlet (and thus the Servlet Container Profile of JASPIC) the
unauthenticated user is presented by a NULL. This is in fact standardized.
However, in EJB there is "some" name that represents the unauthenticated
identity. This name is vendor specific. Some products allow you to define
what this name is, albeit in a vendor specific way. Some vendors indeed use
a string like "ANONYMOUS". IMHO this is a non-ideal situation.
>
> - The point where it fails is that when the programmatic login code
> tries to inform the JASPIC system that there is a logged in user with his
> roles, I get a NullPointerException.
>
>
> java.lang.NullPointerException
> at
> com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler$2.run(BaseContainerCallbackHandler.java:440)
> at
> com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
> at
> com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallerPrincipal(BaseContainerCallbackHandler.java:438)
> at
> com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallback(BaseContainerCallbackHandler.java:198)
> at
> com.sun.enterprise.security.jmac.callback.ServerContainerCallbackHandler.handleSupportedCallbacks(ServerContainerCallbackHandler.java:76)
> at
> com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.handle(BaseContainerCallbackHandler.java:188)
> at
> com.sun.enterprise.security.jmac.callback.ContainerCallbackHandler.handle(ContainerCallbackHandler.java:83)
> at
> org.omnifaces.security.jaspic.core.Jaspic.notifyContainerAboutLogin(Jaspic.java:236)
> at
> org.omnifaces.security.jaspic.core.HttpMsgContext.notifyContainerAboutLogin(HttpMsgContext.java:281)
> at javax.security.SecurityContext.login(SecurityContext.java:46)
>
> Why I tried this example?
> Well, probably developers want to do those kind of things once we have the
> spec and implementation finished.
>
Programmatic login from any place is an important requirement, but as
mentioned above you should not call HttpMsgContext directly from outside
the SAM. Some more detailed explanations are in the issue about the
security context:
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-12
See specifically
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-12?focusedCommentId=385631&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-385631
One thing that I personally found very enlightening is looking at how
HttpServletRequest#authenticate is implemented for a given server.
Kind regards,
Arjan Tijms
> So it is a kind of usage scenario which should be possible (if we go the
> JASPIC way as a few times was mentioned in the mailing list)
>
> Best regards
> Rudy
>
> [1] = https://github.com/AdamBien/secspike
> [2] = https://github.com/rdebusscher/secSpikeWeb
>