EJB3 & How JAAS subject/principal is propagated to EJB Tier from servlet container?

Question

I'm trying to understand how the JAAS principal propagates to the Business/EJB tier from web tier.

I've read that the if the roles/realm is configured in login-config & security-context of web.xml then the servlet container will also transparently pass the authenticated principal to the EJB Tier.

Two questions
1.) First & more importantly is that true ? Without any intervention from the developer !
2.) And secondly any idea how that works under the hood.

Argil

Answer 1

1. yes it's true. that's generally the point of ejb, to take the "hard" stuff out of the hands of the developer (e.g. security, transactions, robustness, multithreading, etc.)
2. it's implementation dependent. i know that in jboss (at least 4.x and before), remote method calls used a custom serialization protocol which had an additional Map of arbitrary information which could be sent along with the request. in this was the auth info as well as other stuff to support clustering. for local method calls i believe they use stuff like ThreadLocals.

Borehole

Thanks ! Always good to get a confirmation ! And this is true even if the webcontainer is in a separate JVM than the EJB container ? – Argil

yes, i specifically mentioned remote communication in my example. – Borehole

sorry missed it. Thanks again. – Argil

Answer 2

There are various "context" pieces of information that get propagated in EJB calls, once you get inside the EJB layer and start doing EJB-EJB calls then Transactions would be an example. Some containers allow you to create your own such context objects too.

Thread-local storage can be used within a process, but generally just assume that the container is in charge and can do the right thing - the actual technique is implementation specific.

Panlogism

I see your point. Also in EJB3 I see that you can just get the SessionContext and call a isCallerInRole() method on it. That's cool. Or the more declarative way(simpler). I didn't get the thread-local storage part though, as to how that is EJB-JAAS specific. – Argil

Each container is free to use any technique it wishes to propagate the context information, the application never sees how it is done. So the propagation is implementation specific - as it happens I think most containers will use Thread-local storage to do it in local cases, it's the obvious implementation technique. – Panlogism

Answer 3

Regarding your first question - yes.
Regarding your second question - are you familiar for example with EJB3 interceptors?
The container create proxied objects with "interception code" for the beans,
and in addition the container can track other annotations on the methods and the bean class,
for example, to detect the @PostConstruct annotation.
Using the role definition, it can check the configuration
(either login-config.xml at older versions of jboss, or standalone.xml in JBoss AS 7 at standalone configuration) and understand what is the definition per each role.
JAAS is used in order to provide you abstraction layer over authentication and authorization.
One of the concepts behind JAAS is login module - it provides you "protocol specific" code that takes care of the actual authorization and authentication.
For example, I'm using in this way Krb5LoginModule to use kerberos.

Erebus

Answer 4

The Principal propagates to the EJB tier from web tier is configured through the login-config in the web.xml as you had surmised for the most part.

How it is implemented is implementation dependent. The user/group data is also implementation dependent and is configured as part of the application server.

However, one of they ways this is done is through an implementation of the JASPIC provider which is a standard way of obtaining the Principal. Using this allows you to have a different authentication path compared to the standard form login, basic authentication or certificate authentication provided by WEB-INF/web.xml but it is a little bit more work.

JASPIC authentication paths allow more complex scenarios such as header based authentication or two-factor or OpenID. The user database "usually" does not need to be tied to the one in the application server. I say "usually" because WebSphere Application Server ties the authentication to a user configured on the server.

Erigena