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

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(a)gmail.com&gt; 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(a)gmail.com&gt; wrote: >> Hi, >> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas >> <stuart.w.douglas(a)gmail.com&gt; 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(a)redhat.com&gt; >>> wrote: >>>> >>>> The MIT license also grants the ability to relicense. >>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas < stuart.w.douglas(a)gmail.com&gt; >>>> 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(a)gmail.com&gt; 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(a)gmail.com&gt; >>>>> 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(a)gmail.com&gt; >>>>> > 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(a)gmail.com&gt; >>>>> >> wrote: >>>>> >>> Hi, >>>>> >>> >>>>> >>> It looks like that after WFLY-5298 (this commit specifically >>>>> >>> >>>>> >>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099d... ) >>>>> >>> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev