<div dir="ltr"><div><div><a href="https://github.com/wildfly/wildfly/pull/8316">https://github.com/wildfly/wildfly/pull/8316</a><br><br></div>Should fix the issue.<br><br></div>Stuart<br><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 21 Oct 2015 at 22:51 arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Unfortunately I would not know how it should work with an async servlet. This is certainly a good thing to have specified and/or clarified.<div><br></div><div>I have a test for async in the suite, but it only tests if the presence of a SAM (that does nothing for that test) doesn't disturb an async dispatch from happening.</div><div><br></div><div>What now seems to happen in most servers is the same thing as what happens with a Servlet Filter. The SAM's secureResponse method is invoked after the last Filter has returned, but at that point the request is not necessarily done and another thread that has the AsyncContext can still write to the response.</div><div><br></div><div>E.g.</div><div><br></div><div>1. Request starts</div><div>2. SAM validateRequest invoked</div><div>2. Filter doFilter() invoked, before/in chain.doFilter()</div><div>3. Servlet invoked, starts async, returns</div><div>4. Filter after chain.doFilter(), returns</div><div>5. SAM secureResponse invoked</div><div>6. Other thread writes to response, calls AsyncContext#complete()</div><div>7. Request ends</div><div><br></div><div>Just like an existing non-async aware GZIP filter would not just work with an async servlet, a SAM that collects the response via a response wrapper would not work either.</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><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 11:46 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>One thing I am still not clear on is how this should work with async servlet, do you have any ideas?<br><br></div><div>Normally when a request has returned to the container it means it is done, however with async requests this is not the case.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div>Stuart<br></font></span></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, 21 Oct 2015 at 19:51 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">On Wed, Oct 21, 2015 at 10:04 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></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ah, I just re-read the spec and we are invoking this in the wrong place, it should be invoked on call stack return like you say, and not on response commit. The spec explicitly states that this may be called after the response has already been commited, but recommends a SAM buffer the full response using a HttpServletResponseWrapper if this is a problem (section B.9 ).</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Okay, great to hear it's more clear now ;)</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div><br></div>Stuart</font></span><div><div><br><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, 21 Oct 2015 at 18:24 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 21, 2015 at 2:19 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I had a quick look into this, and I think your test is invalid. <br><br></div>Basically secureResponse() is called when the message is about to be sent, in the case of your example this happens when the call stack returns and the writer is closed. The means that secureResponse can't use the writer, as it has already been closed.<br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>To be 100% sure, I'll verify this with the sped lead, Ron Monzillo. Indeed, I noticed earlier that Undertow was unable to write to the response at that point. You're right that the test isn't fully clear on this, and I already wanted to split it up in a "secureResponse called" (tested via some other method) and "able to write to the response from secureResponse".</div><div><br></div><div>My feeling says Undertow should not have closed the writer at this point and writing to the response should be possible. It's what the RI allows and what each and every other server including JBoss EAP 6 allows.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Even if the writer was not closed and the message was being commited due to the buffer being full this would still be wrong, as the writer would basically be writing to some random point in the middle of the stream. <br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I'm not sure this is correct. secureResponse is not called whenever the buffer is full, but only after the (Servlet) resource has been invoked (meaning, after the target Servlet has executed and control returns from the last Filter).</div><div><br></div><div>One usecase for this is capturing the response fully via a wrapped response, and then in secureResponse, well, securing this in some way (perhaps encrypting it). As such it's quite like how a GZIP filter functions. Clearly the SAM has to be able to write to the response at that point.</div><div><br></div><div>As said, to be 100% sure I'll verify this with Ron.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><span><font color="#888888"><div><br></div>Stuart<br></font></span></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, 21 Oct 2015 at 10:04 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div dir="ltr"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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" target="_blank">https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389</a></div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><font color="#888888"><br><br></font></span></div><span><font color="#888888">Stuart<br></font></span></div><div><div><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></div></div></blockquote></div>
</div></div></blockquote></div></div></div></blockquote></div></div></div></div></div></div>
</blockquote></div></div></div></blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div>