Doubt with EJB Programmatic Security

[Prasad Shindikar]

In Zaikin's guide,

The Bean Provider can invoke the getCallerPrincipal and isCallerInRole methods ONLY in the
enterprise bean's business methods. If they are otherwise invoked when no security context
exists, they should throw the java.lang.IllegalStateException runtime exception.

at another place in the same chapter,

If the security identity has not been established, getCallerPrincipal returns the container's
representation of the UNAUTHENTICATED identity.

Suppose I call getCallerPrincipal() without a security context, what happens ? I get a runtime exception or I get an UNAUTHENTICATED Principal object ?

Is there any difference between security context and security identity ?

[Tomas Klubal]

First: The firts quote from Zaikins quide is not correct as you can call these methods also from SFSB (CMTD) Callbacks, synchronization methods (afterBegin, beforeCompletition,afterCompletition); SLSB and MDB Timeouts and @AroundInvoke.

Second: You always need security context otherwise you get java.lang.IllegalStateException however having security context does not mean you have security identity (i.e. client was not authenticated because he called EJB anonymously or these methods were called in Timeout method)

[Prasad Shindikar]

okay. so when a user is successfully authenticated, we (container) will get a security identity. till then if getCallerPrincipal is called, it will return UNAUTHENTICATED identity. Is this correct ?

Also, when and how does a container get the security context ? Did not understand this part correctly.

[Tomas Klubal]

Where to start?

Security context is term referring to security-related data (i.e. Principals, roles) that are used for invocation of EJBs (and other technologies are using same term as well). How it is implemented, what it contains and whether you actually have some SecurityContext class is container specific.

As per EJB spec.

Accessing resource managers and enterprise beans is disallowed in the session bean methods
for which the container does not have a meaningful transaction context and/or client security.

(similar applies to MDB)

Therefore in methods where it is meaningful to have a security context, security identity is either propagated from caller (even from other technologies) or if there is no identity to propagate some default one is used.
So if user does not authenticate default "security context" is used and when you ask for caller identity vendor specific representation of the UNAUTHENTICATED identity is returned (guest, anonymous or something similar).

Further you can use @RunAs annotation (or run-as in DD) to specify identity that will be passed to other components.