#475 Patch for [ 558362 ] sfsb loses security on passivate



I created a patch for Bug 558362 (sfsb loses security
on passivate). This patch resolves the follwing issues
for Stateful Session Beans:

1. The security identity was lost when accessing
another EJB from ejbPassivate() (Bug 558362).

2. A java.lang.IllegalStateException was thrown when
calling SessionContext.getCallerPrincipal() in

3. RunAs Security identity did not work when calling
another EJB from ejbActivate(), ejbPassivate(),
afterBegin() or beforeCompletion().

According to the EJB 2.0 Specification, Table 2 (Page
80), it's legal to access another EJB from
ejbActivate(), ejbPassivate(), afterBegin() or
beforeCompletion(). Therefore, IMHO, the security
identity should be propagated correctly to the called
bean. The spec allows also to call getCallerPrincipal()
on the SessionContext object in ejbActivate().

This is my first contribution to JBoss and I'm
everything else than an expert for the architecture of
JBoss. Therefore, this patch might not be the perfect
solution. I hope that it will at least help anyone else
to find the perfect solution.

To achive the correct behaviour for the ejbPassivate()
method, i saw no other possibility than to safe the
client credential on the stateful session bean's
context. The client credential is required for the
method permission checks on EJB calls and the
ejbPassivate() method is not called as a result of a
client call. Therefore, the credential must be safed
between method calls.

Here is a short description of the changes a made:

- credential attribute added

- runAs role set for passivation and activation
- correct principal and credentail set before passivating
- principal and credential safed to the context on

- runAs role set for afterBegin() and beforeCompletion()
- credential safed to the context on invocation (in
addition to the principal)

As this is my first contribution to JBoss, please tell
me if i made any mistakes.



  • Matthias Germann

    Patch for [ 558362 ]

  • Matthias Germann

    Logged In: YES

    This patch replaces the first patch. It solves an issue
    introduced with the first patch.

    A IllegalStateException was thrown when the container tried
    to passivate a statfull session bean without security context.

  • Matthias Germann

    replacement for 558362.txt

  • Adrian Brock

    Adrian Brock - 2004-04-11

    Logged In: YES

    I don't think storing the credential in the passivated state
    is a good idea.

    The spec makes mention about using the unauthenticated identity
    for container callbacks. This may have already been fixed in


  • Matthias Germann

    Logged In: YES

    This is not fixed in jboss-head.

    I could not find anything about an unauthenticated identity
    for container callbacks in the spec. Where did you find it?

    The spec says that it's allowed to call another bean's
    method within ejbPassivate() and ejbActivate() of a stateful
    session bean. IMHO, this means that the container must
    execute the callbacks in a proper security context to ensure
    that the invocation of another bean's methdo is called in a
    proper security context. There must not be any difference if
    another bean's method is called from a business method or
    from ejbPassivate() / ejbActivate().

    As far as i have seen, the principal and the credential are
    the security context of JBoss. The security interceptor of
    JBoss checks the credential on every method invocation.
    Therefore, it's necessary to have the credential available
    for the invocation of a bean's method.

    Or is there a way to invoke the callback without setting the
    credential (just with the Principal)?

    ebjPassivate() and ejbActivate() are called asynchronously
    by the container (not as the result of a client call).
    Therefore, it's necessary to restore the security context
    before invoking the callbacks. I decided to store the
    credential in the statefull session context to ensure that
    it is availbale for restoring the security context.



Log in to post a comment.