[wildfly-dev] Regression after WFLY-5298; request#authenticate does nothing now
Stuart Douglas
stuart.w.douglas at gmail.com
Tue Oct 20 18:26:45 EDT 2015
Is this with proactive auth disabled?
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/20151020/83926109/attachment-0001.html
More information about the wildfly-dev
mailing list