[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ] David Hanisch commented on SECURITY-921: ---------------------------------------- I observed the same issue. The first mech in mechList is not the only accepted "Kerberos V5". I agree the proposed patch is not correct since the proviced mechToken is related to the first mech in list (defined this way by RFC). There should be a new challenge to the browser with "Kerbors V5" as mech. I had a detailed look on it and found there is not. The next challenge is again a "Negotiate" without any token. Seems to me the reason is here in NegotiationMechanism.java (line 122): } finally { negContext.clear(); } This clears the perfectly prepared negTokenTarg from SPNEGOLoginModule.java. When I change this to } finally { {color:#f79232} if (!negContext.isContinuationRequired()) {{color} negContext.clear(); {color:#f79232} }{color} } then the the 401 contains this token and there is another GET from the browser mit mech "Kerberos V5" and the authentication succeeds. One more thing: I would like to comment on something in SPNEGOLoginModule.java what I think is not quite correct: if( ({color:#f79232}(NegTokenTarg){color}negotiationContext.getResponseMessage()).getNegResult() != NegTokenTarg.REJECTED ) { The response message is not necessarily a NegTokenTarg, may also be a Kerberos message. I changed the if-then-elst to just: return super.loginOk; and added setContinuationRequired() in AcceptSecContext.run() where needed: negotiationContext.setResponseMessage(negTokenTarg); {color:#f79232}negotiationContext.setContinuationRequired(kerberosSupported);{color} return Boolean.FALSE; ... if (gssContext.isEstablished() == false) { {color:#f79232}negotiationContext.setContinuationRequired(true);{color} return Boolean.FALSE; ... catch (Exception e) { {color:#f79232}negotiationContext.setContinuationRequired(false);{color} return e; -- This message was sent by Atlassian JIRA (v6.4.11#64026)