One thing I am still not clear on is how this should work with async
servlet, do you have any ideas?
Normally when a request has returned to the container it means it is done,
however with async requests this is not the case.
Stuart
On Wed, 21 Oct 2015 at 19:51 arjan tijms <arjan.tijms at gmail.com> wrote:
> On Wed, Oct 21, 2015 at 10:04 AM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> Ah, I just re-read the spec and we are invoking this in the wrong place,
>> it should be invoked on call stack return like you say, and not on response
>> commit. The spec explicitly states that this may be called after the
>> response has already been commited, but recommends a SAM buffer the full
>> response using a HttpServletResponseWrapper if this is a problem (section
>> B.9 ).
>>
>
> Okay, great to hear it's more clear now ;)
>
>
>
>
>>
>> Stuart
>>
>>
>> On Wed, 21 Oct 2015 at 18:24 arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>>> 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/947f53cd/attachment-0001.html