ejb-jar.xml roles and Principals - PLEASE HELP!

[alzamabar]

1) I studied that ejb-jar.xml roles map to Principal objects. It that true? Are we talking about the java.security.Principal interface? Or are we talking about java.security.auth.Subject ?
2) Is that true that when a Principal is assigned to an EJB client, it is propagated to all Remote Interface executions this client performs? In this case how to bind a client with a Principal so that it is recognized by the J2EE container?
If you are going to reply, please try to avoid to mention JAAS; the reasons for those questions are that I want to excape from JAAS!!
Thanks,
Marco

[Lasse Koskela]

1) I studied that ejb-jar.xml roles map to Principal objects. It that true? Are we talking about the java.security.Principal interface? Or are we talking about java.security.auth.Subject ?

It's actually the vendor-specific equivalent of ejb-jar.xml that does the mapping from roles to actual principals (e.g. weblogic-ejb-jar.xml if you're using WebLogic, and so on). The mapping isn't really related to any particular Java interface but as it happens, you get the user's identity from the context as an instance of java.security.Principal.

2) Is that true that when a Principal is assigned to an EJB client, it is propagated to all Remote Interface executions this client performs? In this case how to bind a client with a Principal so that it is recognized by the J2EE container?

I didn't quite get what you're after with this?

[alzamabar]

It's actually the vendor-specific equivalent of ejb-jar.xml that does the mapping from roles to actual principals (e.g. weblogic-ejb-jar.xml if you're using WebLogic, and so on). The mapping isn't really related to any particular Java interface but as it happens, you get the user's identity from the context as an instance of java.security.Principal.]

Are you telling me that there is no a standard way to map a client request for a Remote Interface method execution to a Principal? That would be terrible, because we are going to build our own solution.

I didn't quite get what you're after with this?

On one side we have an ejb-jar.xml with Principals defined in it, right? Now, if we know that we can bind somehow a Principal (or an array of Principals) to the client request, and that those Principals are mapped against the ejb-jar.xml file, well, to build our own solution is quite easy, isn't it? I'm looking for those two replies:
1) How a standard EJB container maps Client Principals to ejb-jar.xml Principals?
2) How to bind a Client request to a Principal
Once we'll have the reply to those questions, we'll be able to:
1) Map a set of Principals to a client which has succesfully logged in implementing our own solution
2) Be sure that the mapping between our client and the EJB container will be performed by the container
Marco

[Lasse Koskela]

Ah, I think I see what you're after. When you fetch a home interface reference from the JNDI tree, you are being authenticated against the server if the bean has restricted access -- you'll need to provide a username and password. The application server authenticates the username/password against the configured security realm, be it a user database, LDAP or something else. If this authentication is successful, the container creates a Principal object matching the user you authenticated as and makes that object available for you through the EJBContext. Was this closer to what you're looking for?

[alzamabar]

Originally posted by Lasse Koskela:
Ah, I think I see what you're after. When you fetch a home interface reference from the JNDI tree, you are being authenticated against the server if the bean has restricted access -- you'll need to provide a username and password. The application server authenticates the username/password against the configured security realm, be it a user database, LDAP or something else. If this authentication is successful, the container creates a Principal object matching the user you authenticated as and makes that object available for you through the EJBContext. Was this closer to what you're looking for?

This is nearly what I was looking for. The authentication takes place on the web-tier, where user enter username and password. Then, a Struts Action executes some authentication methods on a Session Bean (which queries a database) and if the info match, then user is authenticated.
It's from now, that I would like to know how to tell the EJB server that the user has authenticated succesfully and a set of Principals have been assigned to him, hoping that the container will do the rest (i.e. matching the Principals with the roles defined in the deployment descriptor)
Thanks,
Marco

[Lasse Koskela]

I think we're getting into vendor specifics here. I believe you can do a "local login" with WLS 8.1 by using weblogic.security.services.Authentication#login(CallbackHandler) where you have to provide a suitable implementation of the CallbackHandler interface but I'm not sure if this will help your situation at all (you'll still need to give a username and password for performing the "local login").

[alzamabar]

Originally posted by Lasse Koskela:
I think we're getting into vendor specifics here. I believe you can do a "local login" with WLS 8.1 by using weblogic.security.services.Authentication#login(CallbackHandler) where you have to provide a suitable implementation of the CallbackHandler interface but I'm not sure if this will help your situation at all (you'll still need to give a username and password for performing the "local login").

Thank you but I cannot get an answer to this problem. I mean, if the ejb-jar.xml security is a standard, why the mapping between Principal bound to a client and those bound to the deployment descriptor shouldn't?