Re: [jBoss-User] CallerPrincipal propagation

[Keith L. Musser]

Oleg,   I'm still finding problems with principal propagation.  Since you responded to this earlier, I'm sending this email to you directly.  See bottom for a description of the problem, and here for a workaround.   (By the way, after writing the attached problem description, I discovered that the same problem occurs if I use JNDI to get the home interface.  To see the problem, the client or clients must be accessing the same beans from different principals, as in a web application.)   I found a workaround for this problem, but this is not a "good" solution.  I was unable to follow the intended logic for principal propagation -- it appears it may be a bit different for in-VM compared with RMI calls.  Anyway, I don't have a suggestion on what a good solution is.  But the workaround should at least illustrate what's happening.   My workaround is to modify EnterpriseContext.java as follows:   ORIGINAL:   public void setPrincipal( Principal principal ){    this.principal = principal;    this.beanPrincipal = null; }   WORKAROUND:   public void setPrincipal( Principal principal ){    this.principal = principal;    this.beanPrincipal = null;    SecurityAssociation.setPrincipal(principal); }   It seems (but I'm not sure) that the thread-local SecurityAssociation is set for some RMI calls but not for all of them.  However, the principal seems to always be set correctly for non-nested calls.  However, when a bean calls another bean, the RMI-based propagation is not used (since RMI is not used).  Instead, GenericProxy uses the SecurityAssociation to get the principal.  But sometimes it has not been set.   The workaround makes sure that the SecurityAssociation gets set, so if needed later by a nested (non-RMI) invocation, the principal is valid.   Also, please note that I don't know if my workaround works in all cases.  I only know that it solved the specific instance of the problem that I am having.   As you can see, this isn't elegant.  (I presume all this stuff should be set in the SecurityInterceptor?)  But hopefully it illustrates what the problem is so you can find a good solution.   - Keith -----Original Message----- From: Keith L. Musser <[EMAIL PROTECTED]> To: jBOSS-User <[EMAIL PROTECTED]> Date: Wednesday, November 22, 2000 5:57 PM Subject: [jBoss-User] CallerPrincipal propagation I'm using ctx.getCallerPrincipal() extensively for fine-grained security which I control.  I depend only on JBoss to ensure that the caller principal is set correctly on every invocation. This works most of the time (with a fix I've discussed on this group earlier).  However, I'm having one problem, and I don't know if it's a bug or if I'm violating the EJB spec. In my "User" entity bean I want to get a reference to a different instance of "User".  I do this: public void myMethod( ) throws RemoteException {     ....     UserHome h = ctx.getEJBHome();     User otherUser = h.findByPrimaryKey( key );     ... } The problem is that the caller principal when I invoke methods on otherUser is NOT the caller principal from the calling thread.  Rather, it is the caller principal which was used when my client retrieved the UserHome at an earlier point. If it is legal to call "getEJBHome" inside of a bean, then there appears to be a bug in the way caller principal is propagated to the home. (I recognize that an alternative is to lookup the home as an EJB reference using JNDI, and I assume the caller is propagated that way.  However, it seems to me "getEJBHome" should work also.) Keith L. Musser Integrated Dynamics, Inc. 812-371-7777 email:  [EMAIL PROTECTED]