[jboss-jira] [JBoss JIRA] (SECURITY-768) EJBContext Principal is null except on the first access where HTTP request principal is Ok

cif roes (JIRA) jira-events at lists.jboss.org
Mon Nov 11 14:00:07 EST 2013


cif roes created SECURITY-768:
---------------------------------

             Summary: 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
      Security Level: Public (Everyone can see)
          Components: Negotiation
    Affects Versions: Negotiation_2.1.1
         Environment: JBoss 4.2.3.GA
Jboss Security Negotiation 2.1.1.GA
J2EE 5
            Reporter: cif roes
            Assignee: Darran Lofthouse


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jboss-jira mailing list