<div dir="ltr"><div><div><div>I think if would make sense to port / include at least some of this tests to <br></div>wildfly testsuite, so we would make sure we don&#39;t break anything unintentionally.<br><br></div>This way it would be tested for every pull request and in every job we run on multiple platforms.<br><br>--<br></div>tomaz<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 25, 2015 at 5:14 PM, arjan tijms <span dir="ltr">&lt;<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I discovered some more issues originating from 5298:<br>
<br>
pre-emptive authentication on a public page doesn&#39;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>
  testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)<br>
  testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)<br>
<br>
These tests don&#39;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&#39;s clear that the SAM is called, but its outcome is not<br>
being applied.<br>
<br>
Kind regards,<br>
Arjan<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I checked again on the just released WildFly 10.0 CR2, but<br>
&gt; unfortunately the code is still severely broken now.<br>
&gt;<br>
&gt; There are two main issues, and they&#39;re both in this fragment in<br>
&gt; JASPIAuthenticationMechanism:<br>
&gt;<br>
&gt; if(isValid == null) {<br>
&gt;     isValid = createJASPIAuthenticationManager().isValid(messageInfo,<br>
&gt; new Subject(), JASPI_HTTP_SERVLET_LAYER,<br>
&gt; attachment.getApplicationIdentifier(), new JBossCallbackHandler());<br>
&gt; }<br>
&gt;<br>
&gt; The first problem is the &quot;isValid == null&quot; check. After the first call<br>
&gt; to request#authenticate in a given request this will always be<br>
&gt; non-null. The result is that a request for programmatic authentication<br>
&gt; will effectively be ignored the first time.<br>
&gt;<br>
&gt; The second problem is that this passes in the JBossCallbackHandler,<br>
&gt; but this doesn&#39;t know how to handle JASPIC callbacks and this will<br>
&gt; result in an exception like the following:<br>
&gt;<br>
&gt; javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:<br>
&gt; org.jboss.security.auth.callback.JBossCallbackHandler does not handle<br>
&gt; a callback of type<br>
&gt; javax.security.auth.message.callback.CallerPrincipalCallback<br>
&gt;     at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)<br>
&gt;     at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)<br>
&gt;<br>
&gt; The code should pass in a JASPICallbackHandler here.<br>
&gt;<br>
&gt; Hope this can be fixed. Perhaps it&#39;s just a matter of removing the<br>
&gt; &quot;isValid == null&quot; check and passing in the right callback handler.<br>
&gt;<br>
&gt; Kind regards,<br>
&gt; Arjan Tijms<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt; wrote:<br>
&gt;&gt; p.s. if I just revert JASPIAuthenticationMechanism to the previous<br>
&gt;&gt; version, but leaving in the new JASPICInitialHandler, then everything<br>
&gt;&gt; seems to work again. This is a bit of hacky workaround perhaps, but in<br>
&gt;&gt; some quick testing it does do the trick.<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It looks like that after WFLY-5298 (this commit specifically<br>
&gt;&gt;&gt; <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>
&gt;&gt;&gt; HttpServletRequest#authenticate does not longer do anything.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; HttpServletRequest#authenticate calls though to<br>
&gt;&gt;&gt; JASPIAuthenticationMechanism#authenticate.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; There it now obtains the attachment that was set by the new<br>
&gt;&gt;&gt; JASPICInitialHandler, which calls the SAM at the beginning of the<br>
&gt;&gt;&gt; request. And then uses the stored &quot;isValid&quot; outcome directly, without<br>
&gt;&gt;&gt; calling the SAM again.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; See the code below:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;   public AuthenticationMechanismOutcome authenticate(final<br>
&gt;&gt;&gt; HttpServerExchange exchange, final SecurityContext sc) {<br>
&gt;&gt;&gt;         JASPICAttachment attachment =<br>
&gt;&gt;&gt; exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;         AuthenticationMechanismOutcome outcome;<br>
&gt;&gt;&gt;         Account authenticatedAccount = null;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;         boolean isValid = attachment.isValid();<br>
&gt;&gt;&gt;         final ServletRequestContext requestContext =<br>
&gt;&gt;&gt; attachment.getRequestContext();<br>
&gt;&gt;&gt;         final JASPIServerAuthenticationManager sam = attachment.getSam();<br>
&gt;&gt;&gt;         final JASPICallbackHandler cbh = attachment.getCbh();<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;         GenericMessageInfo messageInfo = attachment.getMessageInfo();<br>
&gt;&gt;&gt;         if (isValid) {<br>
&gt;&gt;&gt;             // The CBH filled in the JBOSS SecurityContext, we need to<br>
&gt;&gt;&gt; create an Undertow account based on that<br>
&gt;&gt;&gt;             org.jboss.security.SecurityContext jbossSct =<br>
&gt;&gt;&gt; SecurityActions.getSecurityContext();<br>
&gt;&gt;&gt;             authenticatedAccount =<br>
&gt;&gt;&gt; createAccount(attachment.getCachedAccount(), jbossSct);<br>
&gt;&gt;&gt;         }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This is not correct I think. The code should call the SAM once again<br>
&gt;&gt;&gt; and use the outcome from that call.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Am I missing something, or was the new call to the SAM simply<br>
&gt;&gt;&gt; forgotten at this point?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Kind regards,<br>
&gt;&gt;&gt; Arjan Tijms<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">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>