wood burning stoves*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Doubt with EJB Programmatic Security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Doubt with EJB Programmatic Security" Watch "Doubt with EJB Programmatic Security" New topic

Doubt with EJB Programmatic Security

Prasad Shindikar
Ranch Hand

Joined: Feb 18, 2007
Posts: 114
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

Joined: Aug 16, 2004
Posts: 20
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
Ranch Hand

Joined: Feb 18, 2007
Posts: 114
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

Joined: Aug 16, 2004
Posts: 20
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.
I agree. Here's the link: http://aspose.com/file-tools
subject: Doubt with EJB Programmatic Security
Similar Threads
Implementing security in WAS 4.0.4
Bean Allowed Operations
getCallerPrincipal from JNDI call
Timer Service