<div dir="ltr">On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <span dir="ltr"><<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Is this with proactive auth disabled?</div></div></blockquote><div><br></div><div>It's with as much of the defaults as is possible.</div><div><br></div><div>Just unzipped a clean download of CR3, added the dummy activation code to standalone.xml, which is:</div><div><br></div><div><div><security-domain name="jaspitest" cache-type="default"></div><div> <authentication-jaspi></div><div> <login-module-stack name="dummy"></div><div> <login-module code="Dummy" flag="optional"/></div><div> </login-module-stack></div><div> <auth-module code="Dummy"/></div><div> </authentication-jaspi></div><div></security-domain></div></div><div><br></div><div>Started WildFly via JBoss tools, then in Java EE 7 samples project removed all modules in pom.xml except the JASPIC and support ones:</div><div><br></div><div><div> <modules></div><div> <module>test-utils</module></div><div> <module>jaspic</module></div><div> <module>util</module></div><div> </modules></div></div><div><br></div><div>Then in the root of the Java EE 7 project executed the following command:</div><div><br></div><div>mvn --fail-at-end test<br></div><div><br></div><div>So this is with all defaults, which I guess is true (enabled) then for what you call "proactive" according to this commit: </div><div><br></div><div><a href="https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389">https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389</a></div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span class=""><font color="#888888"><br><br></font></span></div><span class=""><font color="#888888">Stuart<br></font></span></div><div class=""><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, 21 Oct 2015 at 09:02 arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest): SAM method secureResponse not called, but should have been.<br></div><div><br></div><div><br></div><div>The JSF includes still fail too, but those were failing in WildFly 9 as well:</div><div><br></div><div><div>testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest): Response did not contain output from JSF view that SAM included.</div><div><br></div><div>testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest): Response did not contain output from JSF view that SAM included.</div></div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <span dir="ltr"><<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
Sorry to ask again, but any news on this topic yet?<br>
<br>
If there's anything I can do to help just let me know.<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<div><div><br>
<br>
<br>
<br>
<br>
<br>
On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> Just wondering, any updates here? Did you tried to run the JASPIC<br>
> tests against the latest nightly?<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
> On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas<br>
>> <<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>> wrote:<br>
>>> Can you verify that this PR: <a href="https://github.com/wildfly/wildfly/pull/8204" rel="noreferrer" target="_blank">https://github.com/wildfly/wildfly/pull/8204</a><br>
>>> fixes your issues?<br>
>><br>
>> I did a quick test run, but now really everything breaks.<br>
>><br>
>> In UndertowDeploymentInfoService the following line occurs:<br>
>><br>
>> deploymentInfo.setJaspiAuthenticationMechanism(new<br>
>> JASPIAuthenticationMechanism(authMethod, securityDomain));<br>
>><br>
>> But the constructor arguments are reversed.<br>
>><br>
>> The arguments are defined as:<br>
>><br>
>> public JASPIAuthenticationMechanism(final String securityDomain,<br>
>> final String configuredAuthMethod) {<br>
>><br>
>> When I reverse the arguments to their correct order, the same tests as<br>
>> before fail unfortunately.<br>
>><br>
>> This individual case can be rather easily debugged manually by cloning<br>
>> the project using Eclipse/JBoss tools from<br>
>> <a href="https://github.com/javaee-samples/javaee7-samples" rel="noreferrer" target="_blank">https://github.com/javaee-samples/javaee7-samples</a> Then importing just<br>
>> the jaspic and test-utils directories as Maven projects, and then<br>
>> deploying "jaspic-basic-authentication" using Add and Remove on the<br>
>> server.<br>
>><br>
>> If you then request:<br>
>><br>
>> <a href="http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin" rel="noreferrer" target="_blank">http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin</a><br>
>><br>
>> You should see the same output as:<br>
>><br>
>> <a href="http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin" rel="noreferrer" target="_blank">http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin</a><br>
>><br>
>> Hope this helps<br>
>><br>
>> Kind regards,<br>
>> Arjan Tijms<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>>><br>
>>> Basically it reverts the recent changes, and instead installs a handler<br>
>>> after authenticate to handle requests that do not require authentication.<br>
>>><br>
>>> Stuart<br>
>>><br>
>>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> The MIT license also grants the ability to relicense.<br>
>>>><br>
>>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>><br>
>>>> wrote:<br>
>>>><br>
>>>> This was deliberately disabled to match the behavior of EAP6. It can be<br>
>>>> controlled by the proactive-authentication attribute on the servlet<br>
>>>> container. These JAPIC changes have been driven by this change, in order to<br>
>>>> get the TCK to pass without proactive auth. I will look into it today.<br>
>>>><br>
>>>> If you can contribute your tests it would be greatly appreciated, we do<br>
>>>> not have much coverage (and apparently neither does the TCK, as it does not<br>
>>>> pick up these issues). As I understand it if you are the sole author you<br>
>>>> retain copyright and can re-license them under whatever license you like.<br>
>>>><br>
>>>> Stuart<br>
>>>><br>
>>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> Hi,<br>
>>>>><br>
>>>>> I discovered some more issues originating from 5298:<br>
>>>>><br>
>>>>> pre-emptive authentication on a public page doesn't work anymore<br>
>>>>> either. It still worked fine in WildFly 9.0.1.<br>
>>>>><br>
>>>>> This can be easily seen when running the JASPIC tests from<br>
>>>>> <a href="https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic" rel="noreferrer" target="_blank">https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic</a><br>
>>>>><br>
>>>>> For the basic authentication tests, the following now fail:<br>
>>>>><br>
>>>>> Failed tests:<br>
>>>>><br>
>>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)<br>
>>>>><br>
>>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)<br>
>>>>><br>
>>>>> These tests don't rely on request#authenticate, but depend on<br>
>>>>> automatic calling of a SAM at the beginning of a request. After manual<br>
>>>>> inspection it's clear that the SAM is called, but its outcome is not<br>
>>>>> being applied.<br>
>>>>><br>
>>>>> Kind regards,<br>
>>>>> Arjan<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>> > Hi,<br>
>>>>> ><br>
>>>>> > I checked again on the just released WildFly 10.0 CR2, but<br>
>>>>> > unfortunately the code is still severely broken now.<br>
>>>>> ><br>
>>>>> > There are two main issues, and they're both in this fragment in<br>
>>>>> > JASPIAuthenticationMechanism:<br>
>>>>> ><br>
>>>>> > if(isValid == null) {<br>
>>>>> > isValid = createJASPIAuthenticationManager().isValid(messageInfo,<br>
>>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,<br>
>>>>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());<br>
>>>>> > }<br>
>>>>> ><br>
>>>>> > The first problem is the "isValid == null" check. After the first call<br>
>>>>> > to request#authenticate in a given request this will always be<br>
>>>>> > non-null. The result is that a request for programmatic authentication<br>
>>>>> > will effectively be ignored the first time.<br>
>>>>> ><br>
>>>>> > The second problem is that this passes in the JBossCallbackHandler,<br>
>>>>> > but this doesn't know how to handle JASPIC callbacks and this will<br>
>>>>> > result in an exception like the following:<br>
>>>>> ><br>
>>>>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:<br>
>>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle<br>
>>>>> > a callback of type<br>
>>>>> > javax.security.auth.message.callback.CallerPrincipalCallback<br>
>>>>> > at<br>
>>>>> > org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)<br>
>>>>> > at<br>
>>>>> > org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)<br>
>>>>> ><br>
>>>>> > The code should pass in a JASPICallbackHandler here.<br>
>>>>> ><br>
>>>>> > Hope this can be fixed. Perhaps it's just a matter of removing the<br>
>>>>> > "isValid == null" check and passing in the right callback handler.<br>
>>>>> ><br>
>>>>> > Kind regards,<br>
>>>>> > Arjan Tijms<br>
>>>>> ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><br>
>>>>> > wrote:<br>
>>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous<br>
>>>>> >> version, but leaving in the new JASPICInitialHandler, then everything<br>
>>>>> >> seems to work again. This is a bit of hacky workaround perhaps, but in<br>
>>>>> >> some quick testing it does do the trick.<br>
>>>>> >><br>
>>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><br>
>>>>> >> wrote:<br>
>>>>> >>> Hi,<br>
>>>>> >>><br>
>>>>> >>> It looks like that after WFLY-5298 (this commit specifically<br>
>>>>> >>><br>
>>>>> >>> <a href="https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6" rel="noreferrer" target="_blank">https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6</a>)<br>
>>>>> >>> HttpServletRequest#authenticate does not longer do anything.<br>
>>>>> >>><br>
>>>>> >>> HttpServletRequest#authenticate calls though to<br>
>>>>> >>> JASPIAuthenticationMechanism#authenticate.<br>
>>>>> >>><br>
>>>>> >>> There it now obtains the attachment that was set by the new<br>
>>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the<br>
>>>>> >>> request. And then uses the stored "isValid" outcome directly, without<br>
>>>>> >>> calling the SAM again.<br>
>>>>> >>><br>
>>>>> >>> See the code below:<br>
>>>>> >>><br>
>>>>> >>> public AuthenticationMechanismOutcome authenticate(final<br>
>>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {<br>
>>>>> >>> JASPICAttachment attachment =<br>
>>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);<br>
>>>>> >>><br>
>>>>> >>> AuthenticationMechanismOutcome outcome;<br>
>>>>> >>> Account authenticatedAccount = null;<br>
>>>>> >>><br>
>>>>> >>> boolean isValid = attachment.isValid();<br>
>>>>> >>> final ServletRequestContext requestContext =<br>
>>>>> >>> attachment.getRequestContext();<br>
>>>>> >>> final JASPIServerAuthenticationManager sam =<br>
>>>>> >>> attachment.getSam();<br>
>>>>> >>> final JASPICallbackHandler cbh = attachment.getCbh();<br>
>>>>> >>><br>
>>>>> >>> GenericMessageInfo messageInfo = attachment.getMessageInfo();<br>
>>>>> >>> if (isValid) {<br>
>>>>> >>> // The CBH filled in the JBOSS SecurityContext, we need<br>
>>>>> >>> to<br>
>>>>> >>> create an Undertow account based on that<br>
>>>>> >>> org.jboss.security.SecurityContext jbossSct =<br>
>>>>> >>> SecurityActions.getSecurityContext();<br>
>>>>> >>> authenticatedAccount =<br>
>>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);<br>
>>>>> >>> }<br>
>>>>> >>><br>
>>>>> >>> This is not correct I think. The code should call the SAM once again<br>
>>>>> >>> and use the outcome from that call.<br>
>>>>> >>><br>
>>>>> >>> Am I missing something, or was the new call to the SAM simply<br>
>>>>> >>> forgotten at this point?<br>
>>>>> >>><br>
>>>>> >>> Kind regards,<br>
>>>>> >>> Arjan Tijms<br>
>>>>> _______________________________________________<br>
>>>>> wildfly-dev mailing list<br>
>>>>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> wildfly-dev mailing list<br>
>>>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div></div>