wood burning stoves
The moose likes EJB and other Java EE Technologies and the fly likes Authenticating with EJB tier/JAAS - 2 different ways ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Authenticating with EJB tier/JAAS - 2 different ways ?" Watch "Authenticating with EJB tier/JAAS - 2 different ways ?" New topic

Authenticating with EJB tier/JAAS - 2 different ways ?

Jacob Lyang

Joined: Apr 07, 2005
Posts: 2
there seem to be 2 different ways of authenticating with JAAS and
making secure calls to EJBs:

Way A:
1a) authenticate via JAAS logincontext.login()
2a) obtain a subject
3a) make calls to ejbs with the Subject.doAs(subject, action) construct

Way B:
1a) authenticate via JAAS logincontext.login()
2a) obtain a subject
3a) just make calls to the ejb without using the construct. Example:

Way A is described on many sites.
Way B is published in the new Ed Roman book (3rd Edition)

Are both correct ?
I would be more confident knowing an example directly provided by Sun,
or having sources from Sun Microsystems for this.
Although I think Ed Roman knows what he is doing, it seems too easy
for me and I ask myself if something changed in EJB/JAAS between the
2nd and 3rd Edition of the book ?


Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Jacob,
In my opinion this is an excellent question.
In order for the jaas authorization to work, three things must happen:
  • The user must be authenticated, using jaas authentication.
  • Security policies must be defined (usually through policy files).
  • The Subject that is the result of authentication must be associated with the current thread's access permissions, using either Subject.doAs(), or Subject.doAsPrivileged()

  • In a pure java/jaas environment EdRoman�s example will definitely fail. However in a J2EE environment things are slightly different, mainly because containers use a different security framework where security policy are specified through deployment descriptors, global roles, component specific policies, etc. Although it is jaas compatible it is much more complex than the standard java security. Another point worth mentioning is that the containers treat rmi clients and web clients differently: if a request is coming from a web client it doesn�t require step 3; the client is authenticated if s/he has sufficient privileges (specified via roles). To conclude my guess is that after authentication the container will associate the Subject with the current thread anyway. This in my opinion eliminates the need of 3.
    I agree this is not obvious stuff, but you have to believe me that I tested both scenarios: jaas authorization using weblogic and jaas authorization using jsdk.
    Although bea comes with a jaas example that uses Subject.doAs (actually bea has a special class weblogic.security.Security and clients call Security.doAS()), I could verify that the same example will work, no matter if the Security.doAs() is used or not. However running a very simple jaas tutorial that reads a protected file, it has to have the Subject.doAs() wrapper, in order to work.
    Again all conclusions above are personal, since bea don�t clearly explain this subject.

    I think, therefore I exist -- Rene Descartes
    I agree. Here's the link: http://aspose.com/file-tools
    subject: Authenticating with EJB tier/JAAS - 2 different ways ?
    It's not a secret anymore!