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> 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