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

[Matthias Germann]

Hi,

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
ejbActivate().

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:

org.jboss.ejb.StatefulSessionEnterpriseContext:
- credential attribute added

org.jboss.ejb.plugins.StatefulSessionInstanceCache:
- runAs role set for passivation and activation
- correct principal and credentail set before passivating
- principal and credential safed to the context on
activation

org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor
- 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.

Regards,
Matthias

[Matthias Germann]

Patch for [ 558362 ]

[Matthias Germann]

Logged In: YES
user_id=740263

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]

Logged In: YES
user_id=9459

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
jboss-4
Thomas?

Regards,
Adrian

[Matthias Germann]

Logged In: YES
user_id=740263

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.

Regards,
Matthias