Realms- Securing the J2EE Applications using Container Services
In the world of web applications, security is paramount, more so when the platform is J2EE. A J2EE application consists of different components such as Web Component, Business Logic components and so on. Each of these components execute in their own containers. So, in essence, each component can be provided security by the container in two ways:
Declarative Security
Declarative security is based on Realms, Roles, Users and Groups (more on that later).
Programmatic Security
In Programmatic security, the security is provided through the code embedded in the application itself. Java Authentication and Authorization Services or JAAS belongs to this category.
Securing a web application (for that matter any application) has always two broad phases- Authentication and Authorization. In authentication one validates the credentials of the user. Login procedure is a part of authentication. The next step is setting up and controlling the access rights of the successfully authenticated user. This complete phase comes under Authorization. In authorization a user’s right to access the resources provided by the application is controlled.
In a J2EE application, both of these are managed using Declarative Security. The security service uses the verified credentials supplied at the authentication to control the access to the resources within the application. Hence when authorization comes into picture authentication must also be addressed. Hence here both the phases and the role of Realms in these phases will be discussed here.
Realms, Roles and Users:
Realms, roles and users- these words crop up every time security is discussed in the context of J2EE security. So what are these? Let’s have a detailed view of the trinity of security.
Realms:
A realm defines the boundary of an application. Whatever comes within this boundary is secure. Technically, a realm is a policy that defines how a user is authenticated in a secured domain. This policy contains the list of users and the mechanism to authenticate them. This is similar to Access Control List and authentication mechanism deployed by Windows NT based systems and/or UNIX based systems.
User/Principal:
A Principal is user within the security policy domain. The principal is also known as user within the realm. The username of the user that he/she uses to login and that user’s principal name need not be similar. That’s what the J2EE specification tells but almost all the J2EE implementations utilize the username itself as the principal name.
Roles:
Roles are the references to the actual roles described within the application. The developer uses this reference to map the user to a role. Each user has a role reference mapped into his/her principal name. The reference in turn is mapped onto the actual role within the application. Common role references are Administrator, role1 etc.
Common Implementations of Realms:
As mentioned J2EE application starts using the container’s security services from the time of user’s authentication. Hence the chief implementations of realms also are based on how or where the principals and the related realms are stored. Whenever the container needs to lookup the names and the roles, it uses these ‘storages’. The users and their roles can be stored in three major ways which are xml files, relational databases and directory of LDAP based directory server. So the implementations are:
Memory Realm
JDBC Realm
JNDI Realm
Memory Realm:
Memory realm is based on xml files. All the user names, passwords and their respective roles are stored in a xml file. Whenever the container starts up, it parses this xml file and loads the information into the memory. So until the server is stopped, the complete information is stored within the memory space of the container. Whenever authentication and successive authorization has to be done the supplied credentials (from here I will be using the term credentials for the information supplied by the user) are checked against the in-memory information. The upside of this implementation is that it is easier to setup and use. The downside is that newer information added to the xml file won’t be reflected till the container is restarted. So it is not a good choice for production purposes.
JDBC Realm:
In JDBC realm, the credentials of a user are stored in a relational database table. The container uses JDBC driver to access the information. The major difference between memory realm and JDBC realm is the way in which the credentials are stored. The JDBC realm, as already said, uses tables. The default (also the commonly used) names of these tables are Users and Roles. Whenever a new user is registered, the application or the web administrator has to enter the credentials into the Users table and the corresponding role has to be entered into the Roles table. The container, whenever required uses the information available in the tables to authenticate as well authorize a particular user. The advantage of this implementation is that new information can be entered and used without restarting the server. Also data becomes more secure as the data is not stored in plain text files. Hence for most of the production purposes it is recommended as well as used.
JNDI Realms:
JNDI Realm uses LDAP services provided by a JNDI provider. This is the most complex and the most extensive container based security implementation that any vendor provides. An LDAP directory server contains credentials of the user. The credentials are kept as directory entries in the server. These entries are accessed via the JNDI services within the container. By default, the authentication is done by Bind mode. In this mode, the realm binds the user to the DN entry of the LDAP server using the username and password provided by the user. A user is said to be authenticated if this simple bind succeeds. The passwords of the registered users are not saved in plain text. Instead digest of these passwords are store. Digesting is a form of encryption. So security fears can be dispelled. Again, as in the case of JDBC realms, the entry of registered users is left to the application or web administrator. Though JDBC and JNDI are almost similar, yet the extensive choices provided by the JNDI realm gives it an upper hand.
Implementation of Realm -An example:
So much for the theory, lets see a real world example. As I have already mentioned, in the Declarative security, the constraints are declared in the deployment descriptor i.e. web.xml. So the only part one has to deal with as a web developer is deployment descriptor.
The example that I am citing here deals with a java based Content Management System (CMS). The CMS (lets call it JCMS) has certain resources such as video files, documents etc that can be accessed only by authorized users only. To be more precise we have secure the folders containing the resources. Let’s see how to do it.
Once all the mappings concerning the web application are done, the security declarations and mappings come into picture. The mapping for securing the application resources comes between the following:
<web-app>
:
:
<security-constraint>
:
:
:
</security-constraint>
:
:
</web-app>
In other words to the security mapping <security-constraint> acts as parent node. Then the resources that have to be secured must be declared. Like servlet mappings it can be done for each resource separately or all the resources can be brought under the same declaration.
<web-app>
:
:
<security-constraint>
<web-resource-collection>
:
:
</web-resource-collection>
</security-constraint>
:
:
</web-app>
The <web-resource-collection> encapsulates the various resources that has to be secured. The next step is to give the name to the resource realm and then provide the url that would be used to access the resources.
<web-app>
:
:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected -->
<url-pattern>/secured/resources/*</url-pattern>
:
:
</web-resource-collection>
</security-constraint>
:
:
</web-app>
Then, tell the container, what are the HTTP methods, that would be used to access the resources. If the methods are listed, then only those methods would be protected.
<web-app>
:
:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected -->
<url-pattern>/secured/resources/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
:
:
</security-constraint>
:
:
</web-app>
Here we are telling the container that we want to authenticate all DELETE, GET,POST,PUT methods. So whenever any one of these methods are used in request, then container fires up the authentication process. But there are five types of authentication ( Form based and Basic are two of the most commonly used. How to tell the container which one to use? But before that the container needs to be told the authentic users for this resource. This is done a follows:
<web-app>
:
:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected -->
<url-pattern>/secured/resources/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<!-- Anyone with one of the listed roles may access this area -->
<role-name>raj</role-name>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
:
:
</web-app>
Once the user list is given, then the part comes where the type of authentication has to be provided.
<web-app>
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected -->
<url-pattern>/secured/resources/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<!-- Anyone with one of the listed roles may access this area -->
<role-name>raj</role-name>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Example Basic Authentication Area</realm-name>
</login-config>
:
:
</web-app>
The <login-config> is the place where the type of authentication and the realm to be authenticated. Here we are using BASIC authentication that means whenever anyone tries to access the secured resources the container pops up the standard window dialog demanding the user name and password.
So we have secured our application without even writing a line of java code. Easy… isn’t it?
Where should one go from here? The next logical step is making the application more secure by using JAAS. How to do it … it’s for another time.
No comments:
Post a Comment