EJBContext Principal is null except on the first access where HTTP request principal is Ok ------------------------------------------------------------------------------------------ Key: SECURITY-768 URL: https://issues.jboss.org/browse/SECURITY-768 Project: PicketBox Issue Type: Bug Components: Negotiation Affects Versions: Negotiation_2.1.1 Environment: JBoss 4.2.3.GA Jboss Security Negotiation 2.1.1.GA J2EE 5 Reporter: Paulo Silva Attachments: login-config-fragment.txt I have a standard J2EE application (EAR) with a WAR and EJB. I'm using JSP and servlets to communicate with my EJB3. The EJB are protected using standard annotations like @RolesAllowed(value = "user") with the EJB having a "@SecurityDomain("blankTest")". SPNEGO LoginModule is configured as attached (standard configuration). When I call my JSP and it prints "request.getUserPrincipal();" the Principal is always returned as expected. When I call my EJB and print "sessionContext.getCallerPrincipal().toString()" the Principal is OK in the first access (when SPNEGO authentication occurs) but subsequent calls always return the principal as 'guest' (my unauthenticatedIdentity). When using a standard form LoginModule everything works OK. It seems some kind of "cache" is being lost. I tested many jboss-negotiation versions for compatibility for jboss 4.2.3 and the latest one that works is 2.1.1.GA and that version shows this problem. Version 2.0.4.GA works OK. I tracked down the offending code to "NegotiationAuthenticator.java" and the code that was introduced on SECURITY-129. If I remove the "setNext" method at the end of the class and the DelegationCredentialManager class, it also solves the problem, proving that code is the culprit of the bug. revision 113259 of the file works OK where 113267 starts showing the bug. It seems that code is still present on most recent versions of Jboss-negotiation but maybe that only causes problems in jboss 4.2.3? I only tested this in that jboss-as version. I can provide more details as I can understand the problem very well. I just can't understand what that piece of code does and why it causes this bug :) This is really a major bug as everything related to EJB security doesn't work as the principal isn't correct there...