[tcherel]

I just tried with JBoss 4.0.2 and it is definitley working much better.

Without any changes to the configuration of the default server of JBoss 4.0.2, I managed to do the following:

1) Create a custom login module that is creating a custom principal

2) Deploy EJB + servlet configured with the same security domain that is using my custom login module (actually it uses UsersRolesLoginModule then my custom login module that is changing the CallerPrincipal).

3) Servlet is using FORM based authentication.

4) If I call my EJBs from a remote client, EJB container performs the JAAS authentication and everything works as expected.

5) If I call the servlet from a web browser, web container performs the JAAS authentication and identity gets propagated to the EJBs that it calls.

6) The custom principal created by my login module is the one returned in EJBContext.getCallerPrincipal and HTTPServlerRequest.getUserPrincipal.

Very cool, very nice :-)

I still have the impression that there is something that I am not able to do in the case of the servlet compared to what I can do with a custom login module used on the remote EJB client side.

In the case of the a remote EJB client, if I use a custom login module on the client side to create a custom principal, this custom principal is the one used as the key in the security domain cache. My custom login module can then generate a unique number as part of the custom principal, so two calls to "login" with the same user name and password are seen as two different users, two different authentications (one is not reusing the cached principal of the other if not yet expired).

With the servlet, it does seem that I can do something like that.
Somehow, I'd like to be able to customize the principal that is created before my security domain login modules are called.
May be this can be achieved by customizing the FORM login (defining my own FORM login action and all). I should probably look into that.
But such solution start to be FORM authentication specific. I would like it to work for BASIC authentication as well or any other ones for that matter.

Am I correct in my analysis or am I still missing something?

Thomas

[starksm64]

Custom principal support did not work in 3.2.3, so you definitely need the latter versions.

There certainly is a fundament difference between web tier and ejb tier authentication. How likely is it that IE6.x is going to be able to provide custom credentials for an authentication mechanism?

Even FORM auth is limited to a username and password. It has no notion of a principal as there is no definition of how to use JAAS at the servlet spec level.
You would have to provide a custom implementation of the form authenticator and change the tomcat Realm interface to support a Principal as the authentication id. Its a limitation of tomcat org.apache.catalina.Realm security provider interface. A feature request to tomcat is needed to add better support for Principal identities.

[tcherel]

Scott,

Thanks for the answer.
I agree that it is not likely that the web browser will be able to provide custom credentials.
But I also do not think that I have to go that far as the unique id that I want to add to the principal to make it "unique" could be generated right at the tomcat/JBoss junction, on the server side, I think.
For example, tomcat is going to generate an HTTP session ID that will definitely uniquely identify the web browser session.
On the server side, at the time the principal used in the security domain cache is created, if I could "just" create my own principla right here and add the HTTP session id to it (one that I generate would work as well), I think it would work.

Does that make sense or is it also something that is not possible without a tomcat feature request?

Thomas

[starksm64]

That particular usage could probably be encapsulated into this feature request:

http://jira.jboss.com/jira/browse/JBAS-1802

A principal factory could be added so that the tomcat caching principal is using the custom principal as the security domain principal.