Thanks Arjan for some useful comments. I will have a look later on to my
code to update it and test again.
Some comments inline.
On 7 May 2015 at 14:26, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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.
>
>
That was also what I found in my tests.
>
>
>>
>> - 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.
>
>
When a resource was called which was protected through a security
constraint element in the web.xml, the property __
"javax.javax.security.auth.message.MessagePolicy.isMandatory" isn't set.
So the SAM isn't aware that is is a protected resource.
>
>>
>> - 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.
>
>
OK, My idea was that SAM was available during the complete request-response
lifecycle. Wrong interpretation from my side thus.
> 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.
>
> HttpServletRequest#authenticate who triggers the SAM is something that I
wel need to check.
My idea was that the SecurityContext looked up the IdentityStore and
interacts directly with it.
> 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.
>
>
not-ideal -> Would call it an issue.
>
>
>>
>> - 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
>>
>
>