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

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