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

On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas < stuart.w.douglas(a)gmail.com&gt; 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/8a41c10eb56a827332355b921834c85... Kind regards, Arjan Tijms > > > Stuart > > On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms(a)gmail.com&gt; 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(a)gmail.com&gt; >> 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(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 >>> >> >>