8:18 a.m.
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> 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> 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