[wildfly-dev] Regression after WFLY-5298; request#authenticate does nothing now

arjan tijms arjan.tijms at gmail.com
Mon Sep 28 05:09:36 EDT 2015


Hi,

On Mon, Sep 28, 2015 at 1:49 AM, Stuart Douglas
<stuart.w.douglas at gmail.com> wrote:
> This was deliberately disabled to match the behavior of EAP6. It can be
> controlled by the proactive-authentication attribute on the servlet
> container. These JAPIC changes have been driven by this change, in order to
> get the TCK to pass without proactive auth. I will look into it today.

I understand, the JBoss proprietary authentication (as implemented by
the JBoss Web/Tomcat valves) had a different behaviour. Quite a number
of proprietary mechanisms in containers only call authentication
modules for protected resources.

For JASPIC however this is different and a SAM's validateRequest and
secureResponse always have to be called for every request (protected
or not), in addition to responding to explicit calls to
request#authenticate.

If I'm not mistaken, the "automatic" call to secureResponse was one of
the tests failing in WildFly 9, which 5298 seemed to address.


> If you can contribute your tests it would be greatly appreciated, we do not
> have much coverage (and apparently neither does the TCK, as it does not pick
> up these issues).

Indeed, the TCK for EE 6 and EE 7 (JASPIC 1.0 and JASPIC 1.1
respectively) don't test much. In fact, if you didn't actually
implement JASPIC but just provided stubs for all types with no
implementation code, you could pass the TCK as well (one
implementation got certified that way). I've been in contact with the
TCK engineer and for EE 8 the situation will be improved (at least a
little, hopefully a lot).

> As I understand it if you are the sole author you retain
> copyright and can re-license them under whatever license you like.

Okay, I'm personally okay with whatever license for these tests. In
order to keep the tests consistent and only do updates at one place it
would be best if you "just' executed the existing tests. If this is
hard though I can look into porting them to the WildFly test harness.

Note that there are still a couple of tests that need to be added. The
ability to call request#authenticate multiple times (including after a
failure) and the ability to write to the response from secureResponse
aren't tested now. I believe at least WildFly 8 wasn't able to write
to the response from secureResponse (no error or exception, but no
output either). If you're looking at handling secureResponse now this
may be something to look at as well.

Kind regards,
Arjan Tijms




>
> Stuart
>
> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>> Hi,
>>
>> I discovered some more issues originating from 5298:
>>
>> pre-emptive authentication on a public page doesn't work anymore
>> either. It still worked fine in WildFly 9.0.1.
>>
>> This can be easily seen when running the JASPIC tests from
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>
>> For the basic authentication tests, the following now fail:
>>
>> Failed tests:
>>
>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>
>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>
>> These tests don't rely on request#authenticate, but depend on
>> automatic calling of a SAM at the beginning of a request. After manual
>> inspection it's clear that the SAM is called, but its outcome is not
>> being applied.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I checked again on the just released WildFly 10.0 CR2, but
>> > unfortunately the code is still severely broken now.
>> >
>> > There are two main issues, and they're both in this fragment in
>> > JASPIAuthenticationMechanism:
>> >
>> > if(isValid == null) {
>> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
>> > }
>> >
>> > The first problem is the "isValid == null" check. After the first call
>> > to request#authenticate in a given request this will always be
>> > non-null. The result is that a request for programmatic authentication
>> > will effectively be ignored the first time.
>> >
>> > The second problem is that this passes in the JBossCallbackHandler,
>> > but this doesn't know how to handle JASPIC callbacks and this will
>> > result in an exception like the following:
>> >
>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
>> > a callback of type
>> > javax.security.auth.message.callback.CallerPrincipalCallback
>> >     at
>> > org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>> >     at
>> > org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>> >
>> > The code should pass in a JASPICallbackHandler here.
>> >
>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>> > "isValid == null" check and passing in the right callback handler.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
>> > wrote:
>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>> >> version, but leaving in the new JASPICInitialHandler, then everything
>> >> seems to work again. This is a bit of hacky workaround perhaps, but in
>> >> some quick testing it does do the trick.
>> >>
>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> It looks like that after WFLY-5298 (this commit specifically
>> >>>
>> >>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>> >>> HttpServletRequest#authenticate does not longer do anything.
>> >>>
>> >>> HttpServletRequest#authenticate calls though to
>> >>> JASPIAuthenticationMechanism#authenticate.
>> >>>
>> >>> There it now obtains the attachment that was set by the new
>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
>> >>> request. And then uses the stored "isValid" outcome directly, without
>> >>> calling the SAM again.
>> >>>
>> >>> See the code below:
>> >>>
>> >>>   public AuthenticationMechanismOutcome authenticate(final
>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>> >>>         JASPICAttachment attachment =
>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>> >>>
>> >>>         AuthenticationMechanismOutcome outcome;
>> >>>         Account authenticatedAccount = null;
>> >>>
>> >>>         boolean isValid = attachment.isValid();
>> >>>         final ServletRequestContext requestContext =
>> >>> attachment.getRequestContext();
>> >>>         final JASPIServerAuthenticationManager sam =
>> >>> attachment.getSam();
>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>> >>>
>> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>> >>>         if (isValid) {
>> >>>             // The CBH filled in the JBOSS SecurityContext, we need to
>> >>> create an Undertow account based on that
>> >>>             org.jboss.security.SecurityContext jbossSct =
>> >>> SecurityActions.getSecurityContext();
>> >>>             authenticatedAccount =
>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>> >>>         }
>> >>>
>> >>> This is not correct I think. The code should call the SAM once again
>> >>> and use the outcome from that call.
>> >>>
>> >>> Am I missing something, or was the new call to the SAM simply
>> >>> forgotten at this point?
>> >>>
>> >>> Kind regards,
>> >>> Arjan Tijms
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


More information about the wildfly-dev mailing list