[wildfly-dev] Regression after WFLY-5298; request#authenticate does nothing now
arjan tijms
arjan.tijms at gmail.com
Wed Oct 21 03:24:39 EDT 2015
Hi,
On Wed, Oct 21, 2015 at 2:19 AM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:
> I had a quick look into this, and I think your test is invalid.
>
> Basically secureResponse() is called when the message is about to be sent,
> in the case of your example this happens when the call stack returns and
> the writer is closed. The means that secureResponse can't use the writer,
> as it has already been closed.
>
To be 100% sure, I'll verify this with the sped lead, Ron Monzillo. Indeed,
I noticed earlier that Undertow was unable to write to the response at that
point. You're right that the test isn't fully clear on this, and I already
wanted to split it up in a "secureResponse called" (tested via some other
method) and "able to write to the response from secureResponse".
My feeling says Undertow should not have closed the writer at this point
and writing to the response should be possible. It's what the RI allows and
what each and every other server including JBoss EAP 6 allows.
> Even if the writer was not closed and the message was being commited due
> to the buffer being full this would still be wrong, as the writer would
> basically be writing to some random point in the middle of the stream.
>
I'm not sure this is correct. secureResponse is not called whenever the
buffer is full, but only after the (Servlet) resource has been invoked
(meaning, after the target Servlet has executed and control returns from
the last Filter).
One usecase for this is capturing the response fully via a wrapped
response, and then in secureResponse, well, securing this in some way
(perhaps encrypting it). As such it's quite like how a GZIP filter
functions. Clearly the SAM has to be able to write to the response at that
point.
As said, to be 100% sure I'll verify this with Ron.
Kind regards,
Arjan Tijms
>
> Stuart
>
> On Wed, 21 Oct 2015 at 10:04 arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> 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/7cc7a7d2/attachment-0001.html
More information about the wildfly-dev
mailing list