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

arjan tijms arjan.tijms at gmail.com
Tue Oct 20 19:04:22 EDT 2015


On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> wrote:

> Is this with proactive auth disabled?
>

It's with as much of the defaults as is possible.

Just unzipped a clean download of CR3, added the dummy activation code to
standalone.xml, which is:

<security-domain name="jaspitest" cache-type="default">
    <authentication-jaspi>
        <login-module-stack name="dummy">
            <login-module code="Dummy" flag="optional"/>
        </login-module-stack>
        <auth-module code="Dummy"/>
    </authentication-jaspi>
</security-domain>

Started WildFly via JBoss tools, then in Java EE 7 samples project removed
all modules in pom.xml except the JASPIC and support ones:

    <modules>
      <module>test-utils</module>
      <module>jaspic</module>
      <module>util</module>
    </modules>

Then in the root of the Java EE 7 project executed the following command:

mvn --fail-at-end test

So this is with all defaults, which I guess is true (enabled) then for what
you call "proactive" according to this commit:

https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389

Kind regards,
Arjan Tijms













>
>
> Stuart
>
> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> Hi,
>>
>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone well,
>> since the behaviour is back to that of WildFly 9.
>>
>> Meaning, most tests from the EE 7 samples now pass again, but calling of
>> secureResponse (which 5298 was supposed to fix I think) now fails again:
>>
>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>> SAM method secureResponse not called, but should have been.
>>
>>
>> The JSF includes still fail too, but those were failing in WildFly 9 as
>> well:
>>
>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>> Response did not contain output from JSF view that SAM included.
>>
>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>> Response did not contain output from JSF view that SAM included.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Sorry to ask again, but any news on this topic yet?
>>>
>>> If there's anything I can do to help just let me know.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > Just wondering, any updates here? Did you tried to run the JASPIC
>>> > tests against the latest nightly?
>>> >
>>> > Kind regards,
>>> > Arjan Tijms
>>> >
>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>> >> Hi,
>>> >>
>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>> >> <stuart.w.douglas at gmail.com> wrote:
>>> >>> Can you verify that this PR:
>>> https://github.com/wildfly/wildfly/pull/8204
>>> >>> fixes your issues?
>>> >>
>>> >> I did a quick test run, but now really everything breaks.
>>> >>
>>> >> In UndertowDeploymentInfoService the following line occurs:
>>> >>
>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>> >>
>>> >> But the constructor arguments are reversed.
>>> >>
>>> >> The arguments are defined as:
>>> >>
>>> >>  public JASPIAuthenticationMechanism(final String securityDomain,
>>> >> final String configuredAuthMethod) {
>>> >>
>>> >> When I reverse the arguments to their correct order, the same tests as
>>> >> before fail unfortunately.
>>> >>
>>> >> This individual case can be rather easily debugged manually by cloning
>>> >> the project using Eclipse/JBoss tools from
>>> >> https://github.com/javaee-samples/javaee7-samples Then importing just
>>> >> the jaspic and test-utils directories as Maven projects, and then
>>> >> deploying "jaspic-basic-authentication" using Add and Remove on the
>>> >> server.
>>> >>
>>> >> If you then request:
>>> >>
>>> >>
>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>> >>
>>> >> You should see the same output as:
>>> >>
>>> >>
>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>> >>
>>> >> Hope this helps
>>> >>
>>> >> Kind regards,
>>> >> Arjan Tijms
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>> Basically it reverts the recent changes, and instead installs a
>>> handler
>>> >>> after authenticate to handle requests that do not require
>>> authentication.
>>> >>>
>>> >>> Stuart
>>> >>>
>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>> jason.greene at redhat.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> The MIT license also grants the ability to relicense.
>>> >>>>
>>> >>>> On Sep 27, 2015, at 6:50 PM, 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.
>>> >>>>
>>> >>>> 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). As I understand it if you are the sole
>>> author you
>>> >>>> retain copyright and can re-license them under whatever license you
>>> like.
>>> >>>>
>>> >>>> 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
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> wildfly-dev mailing list
>>> >>>> wildfly-dev at lists.jboss.org
>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/f142f010/attachment-0001.html 


More information about the wildfly-dev mailing list