Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Authenticating with EJB tier/JAAS - 2 different ways ?

 
Jacob Lyang
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
myEJB.methodA();

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 ?

Regards,

Jay
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
    Regards.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic