JAAS, Securing EJB - Authenticating the user within the EJB
(Page 4 of 4 )
This approach consists of implementing a part of the implementation within the EJB and a part of it within the deployment descriptor. I will explain it step-by-step. As I have already mentioned there are various steps involved in this, which include testing the user membership and configuring the deployment descriptor.
Testing the user membership
The membership of a user is based upon a role. In this context, "role" is known as Security Roles. A role defines the access privileges of a user. In J2EE, whatever way the security roles are implemented (be it programmatic or declarative), they are defined in deployment descriptors. The roles can be accessed inside the EJB. Hence the EJB developer can check for the membership of the user from within the Bean.
The EJB API provides the isCallerInRole() method to verify the role of the user. Let's take a look at how to use it.
First create a Session Bean by implementing the SessionBean class.
public class SecuredEJB implements SessionBean
{
…..
}
Here the session façade pattern is being used. So SecuredEJB intercepts all the requests to other EJBs.
Next declare a private instance of SessionContext.
public class SecuredEJB implements SessionBean
{
SessionContext context=null;
……..
}
Then set the value of the SessionContext variable to that of being passed on by the container. The container passes this value as an argument of setSessionContext.
public void setSessionContext(SessionContext sc)
{
context = sc;
}
Now the context variable can be used to access the user’s role. The isCallerInRole() is a method of SessionContext. Since the SessionContext variable now contains the user related information, its methods can be used to verify a user’s role. For my purpose, I have done it in the following way:
public class SecuredEJB implements SessionBean
{
SessionContext context=null;
…
public void setSessionContext(SessionContext sc)
{
context = sc;
}
public boolean verifyRole()
{
boolean verified=false;
//set the verified to true only if the role of the caller //is “Admin”
if(context.isCallerInRole(“Admin”))
{
verified=true;
}
return verified;
}
<pre style='margin-left:.5in; text-indent:>
}
This is one of the many ways to use the information contained in SessionContext. In my applications, after getting an instance of SecuredEJB (or whatever name I have used), I make a call to the verifyRole to ensure the role of the user accessing the bean. If the method returns false, I redirect the request to an access denied page.
That completes the steps to test or verify the membership of user.
Configuring the deployment descriptor
This is the second (and lengthier) step involved in securing EJB. Though the user’s role is passed to the component by the container, the container needs to know the roles defined for the component and the related security constraints. And this has to be done by describing the security roles and constraints in the deployment descriptor. In the case of EJB that would be ejb-jar.xml. So here is how it is done.
The root element of ejb-jar.xml is ejb-jar. That means all other declarations are contained within it. Hence let's start with the root element:
<ejb-jar>
:
:
:
</ejb-jar>
The main part of securing the component starts with the <security-role-ref> child element of the <session> element.
<ejb-jar>
<enterprise-beans>
<session>
:
:
<security-role-ref>
:
</security-role-ref>
</session>
</enterprise-beans>
</ejb-jar>
The security-role-ref element defines the name of the role and its link as its child elements. Since the EJB is to be accessed only by a user having an admin role, the role-name is Admin and the role-link is also Admin, as shown.
<ejb-jar>
<enterprise-beans>
<session>
:
:
<security-role-ref>
<role-name>Admin</role-name>
<role-link>Admin</role-link>
</security-role-ref>
</session>
</enterprise-beans>
</ejb-jar>
That ends the description of security-role-ref. The next step is defining security-identity. This is done by providing values to the child elements of the security-identity -- the<run-as> element that contains the role-name element. Here the role-name is Admin.
<ejb-jar>
<enterprise-beans>
<session>
:
:
<security-role-ref>
<role-name>Admin</role-name>
<role-link>Admin</role-link>
</security-role-ref>
<security-identity>
<run-as>
<role-name>Admin</role-name>
</run-as>
</security-identity>
</session>
</enterprise-beans>
:
:
</ejb-jar>
The next step involves providing the role enumerations in the assembly descriptions. Here, all the role names are given.
<ejb-jar>
<enterprise-beans>
<session>
:
:
<security-role-ref>
<role-name>Admin</role-name>
<role-link>Admin</role-link>
</security-role-ref>
<security-identity>
<run-as>
<role-name>Admin</role-name>
</run-as>
</security-identity>
</session>
</enterprise-beans>
<assembly-descriptor>
<security-role>
<role-name>external</role-name>
</security-role>
<security-role>
<role-name>Internal</role-name>
</security-role>
<security-role>
<role-name>Admin</role-name>
</security-role>
</assembly-descriptor>
:
:
</ejb-jar>
In enumerating the roles, all the roles can be specified. But which role has access to which methods of the EJB is yet to be specified. This is done by providing the method permissions. The <method-permission> has <role-name> and <method> as child elements. The <method> element has <ejb-name> and <method-name>. The <ejb-name> specifies the name of the EJB, and the <method-name> specifies the corresponding methods to which the role has access. The methods include create and remove, among others. Let's see how to specify whether the role of admin has access to all of the methods of SecuredEjb EJB:
<ejb-jar>
<enterprise-beans>
<session>
:
:
<security-role-ref>
<role-name>Admin</role-name>
<role-link>Admin</role-link>
</security-role-ref>
<security-identity>
<run-as>
<role-name>Admin</role-name>
</run-as>
</security-identity>
</session>
</enterprise-beans>
<assembly-descriptor>
<security-role>
<role-name>external</role-name>
</security-role>
:
:
<security-role>
<role-name>Admin</role-name>
</security-role>
<method-permission>
<role-name>Admin</role-name>
<method>
<ejb-name>SecuredEJB</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
</ejb-jar>
The * wild card used with <method-name> specifies that the role Admin has access to all of the methods of SecuredEJB. It not absolutely necessary to define the <method-permissions> if the requirement is only to verify the user from calling the business methods. But if the requirement prohibits all roles except the specified one (Admin in this case) to access other methods such as create and remove, then <method-permission> is quite handy.
This brings us to the end this discussion on securing EJB using JAAS. As you would have already observed in the case of EJB, the developer doesn’t have to code much to use the JAAS framework. So go ahead and explore more of JAAS. Until next time.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
