[wildfly-dev] Regression after WFLY-5298; request#authenticate does nothing now
arjan tijms
arjan.tijms at gmail.com
Tue Oct 20 18:02:56 EDT 2015
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/c36b840f/attachment-0001.html
More information about the wildfly-dev
mailing list