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