Server Side JAAS Question

[Yi Chen]

Hi everyone,

I am new to JAAS. I am confused by following question:

In EJB, we could declare one role has the permission to execute one method like following:

EJB configuration file:

<method-permission>
  <role-name>Users</role-name>
  <method>
    <ejb-name>myBean</ejb-name>
    <method-name>myMethodInMyBean</method-name>
  </method>
</method-permission>

In EJB:

@RolesAllowed("Users")
public class myBean
{
    @RolesAllowed("Users")
    public void myMethodInMyBean()
    {
    ...
    }
}

My question is WHO maps the role "Users" to a particular user, for example "john smith"? HOW?

Can we pass the role in for the caller by following code?

Hashtable env = new Hashtable(); 
env.put(Context.SECURITY_PRINCIPAL, "Users"); 
//env.put(Context.SECURITY_CREDENTIALS, "welcome"); 
env.put("java.naming.factory.initial",
        "oracle.j2ee.server.ApplicationClientInitialContextFactory"); 
env.put("java.naming.provider.url",
        "opmn:ormi://opmnhost:6004:oc4j_inst1/ejbsamples"); 
Context ic = new InitialContext (env); 
MyBeanHome = (MyBeanHome ) ic.lookup ("java:comp/env/myBean");

Thanks in advance!

Yi Chen

[Ulf Dittmer]

There's no standard way to define that, just like there isn't for servlet containers - each app server has its own mechanism. This article about some of the issues around JAAS may be of interest: http://today.java.net/article/2006/09/13/using-jaas-java-ee-and-soa-environments

[Rahul Mishra]

Hi Yi,

This is the tricky part of J2EE ..which defines roles who perform responsibilites..

The configuration you showed is typically done by the Application Assember(in the deployment descriptor) or the Component Developer(if specified in the annotation), these people have the view of the security requirements of the application and they provide the view to the deployer via the deployment descriptor(now this is not mandatory, and you could do it via an email)..

The last line might have confused you a bit..but you missed it in your snippet too

There is actually a tag called <security-role> using which the assembler/developer tells the deployer the role requirements of the application.

The deployer then uses this information to map the role to actual users in the security realm..so..users would be mapped to John Smith and many others..by the application deployer...this mapping varies depending on the application server and there is no standardization here...

hope that clarifies..

P.S > your last code snippet is not correct..this security principal usage is not the same

[Yi Chen]

Thanks for your reply, Rahul.

The deployer then uses this information to map the role to actual users in the security realm..so..users would be mapped to John Smith and many others..by the application deployer...this mapping varies depending on the application server and there is no standardization here...

Can the actual users be dynamically added/removed? What I mean is that whether those actual users have to be configured in an EJB file?

Also, could you please let me know what the standard way of using JAAS in JEE5/EJB3 application?

One possible way is doing JAAS authentication and authorization in Web side. If passed, looking up the EJB and executing the its methods. If failed, do not execute the EJB methods and redirect to the error page. It is a pure Web side JAAS solution. I wonder whether we could propagate the authentication/authorization result done in Web side to Server side. This is why I wrote the following code in my first post:

Hashtable env = new Hashtable();    
env.put(Context.SECURITY_PRINCIPAL, "Users");    
//env.put(Context.SECURITY_CREDENTIALS, "welcome");    
env.put("java.naming.factory.initial",   
        "oracle.j2ee.server.ApplicationClientInitialContextFactory");    
env.put("java.naming.provider.url",   
        "opmn:ormi://opmnhost:6004:oc4j_inst1/ejbsamples");    
Context ic = new InitialContext (env);    
MyBeanHome = (MyBeanHome ) ic.lookup ("java:comp/env/myBean");  

I hope that we could do the login in Web side and retrieve the principal, and give that principal to EJB via Context properties. By googling, I found that we could either do login in Web side and retireve the principal or pass the principal to EJB via Context properties. But I didn't find how to combine them together. Do you have any suggestions here?

Thanks in advance!

Yi Chen

[Rahul Mishra]

Can the actual users be dynamically added/removed? What I mean is that whether those actual users have to be configured in an EJB file?

Depends, if the users are stored in a database then making real time changes without starting the server would work but if it is stored in the server memory or a server specific file (i think weblogic stores it that way..not sure though)..then the change would not take effect...But again..why are you worried about this..JEE is about Specification...and this is not in the specification..anything you discuss would be specific to an application server.

The standard way of using JAAS..is to configure login modules on the server, use a callback handler to collect the credentials, code custom permissions and ask the security manager if those permissions are valid..a lot happens in JAAS behind the scenes..i recommend you read some good article on JAAS(i remember reading JAAS in action..about 3 years ago)..


I believe that the application server should be responsible to pass your principal and/or role from the web container to the ejb container...i havent done this sort of thing..but passing it via context properties...does not seem correct...one more aspect to this is..that web container authentication/authorization is enough..IF
a) you do not plan to run the EJB in a separate box (and the EJB has all local interfaces)
b) You do not plan to expose your EJB as web services

I think you should do nothing(i may be wrong)..while looking up the EJB..just do a Dependency injection of the EJB into your web component...and invoke an EJB method from the web component..with a role which should not be allowed to run the EJB method?..if it does not work..let me know..i will do my googling..but that has to wait till Monday..(you know why)..