Securing an EJB Application in BES 5.2

While it is possible to take an existing application and secure it with little or no changes to code, it is imperative that security mechanisms and techniques be a part of the design and development process rather than be implemented as an afterthought or during the last stages of development.

The model is:

                                      RMI/IIOP
         Java Standalone App <------------------> EJB Container
        

The design philosophy is to employ a security mechanism whereby clients are required to first authenticate themselves to the server (say via a username/password combination). Once authenticated, clients then receive an identity - and invocation of business methods on the server should be allowed iff that client is authorized to call that method.

Let's take the simple case of a stateless session bean (SLSB) invoked by a client. The SLSB is a Calculator; with (business) methods to add/subtract integers. Let's assume that the Calculator SLSB has two business methods:

A simple Java standalone client can then be developed to invoke these methods. In a unsecured scenario; assuming that the SLSB has remote interfaces, any client can invoke these methods.

The idea is to secure the application by simple means (at least in the context of this example and paper) so that clients are required to log on first. From then on, depending on method permissions, clients may or maynot be authorized to invoke particular methods. Let's take the case where clients in the role of a 'accountant' are allowed to invoke both add() and subtract() methods while clients in the role of a 'clerk' are only allowed to invoke the 'add' method.

We need a backend capable of maintaining a list of usernames, passwords and associated role(s). These would then be consulted when the client logs on and/or invokes methods to ensure that access is indeed authorized. We'll use a database for this purpose; the interface to which is provided by the BasicLoginModule. (See BES Developer's Guide for information on other LoginModules and how/when they could be used).

So, our model now is:

          Java Standalone App <------> EJB Container <------> DB (for storing user and role info)
        

As a first step, we'll create/configure our database to store users and roles. Borland provides the 'userdbadmin' tool (run from the command line) to auto-create required tables, create groups and associate users with groups.

We'll use JDataStore for this example; though any backend - like Oracle, DB2, Sybase, MS SQL Server, etc. can be used. A sample command is shown below. For JDataStore, the command is to be run from the command prompt when the current working directory is:

          $BES/var/servers/<server_name>
          
          userdbadmin
          -create
          -db jdbc:borland:dslocal:adm/security/mydb.jds
          -driver com.borland.datastore.jdbc.DataStoreDriver
          -user admin
          -password admin
          -interactive
          
          >addgroups accountant
          >addgroups clerk
          >adduser krish krishpwd accountant
          >adduser john johnpwd accountant
          >adduser bill billpwd clerk
          >adduser scott scottpwd clerk
          >quit
        

The above commands typed at the ">" prompt creates two groups 'accountant' and 'clerk' in the database. Two users with usernames krish and john are in an accountant role; while bill and scott are in the role of clerks. (Type 'help' at the ">" prompt for a list on available commands).

Well, that's about it. You could create fancy CallbackHandlers to prompt users to enter information say from within a dialog/frame. Or you could use different LoginModules to authenticate/authorize against a different backend (such as a NT/Unix domain, LDAP, etc,).

Once the Borland Enterprise Server has been set up to authenticate against a backend (as described in Part I), we will now secure the Web Container. The first step is to edit the Web Container's server.xml file and change the realm that Tomcat uses (by default, the MemoryRealm) to use Borland Security Service Realm (BSSRealm).

For this, from the BES Console, right-click the Web Container, choose 'Configure' and run down to the 'Realms' tab. For the HTTP Service, enter the following class name for the BSSRealm:

org.apache.catalina.realm.BSSRealm

The secure realm we set up in Part I was 'MyRealm', and so enter this for the 'Login Domain'. These entries will reflect in Tomcat's server.xml file under the HTTP Service tag:

            <Realm name="MyRealm" className="org.apache.catalina.realm.BSSRealm" />
          

Our objective is to authenticate web clients who request a protected URL (defined through deployment descriptors as we shall see) against the backend setup for authentication and authorization in Borland Enterprise Server.

This can be done by opening up the deployment descriptor editor (DDE) for that Web Application's WAR file. Go to the toplevel structural information for that archive, and then in the textfield for the 'Authorization domain', enter 'MySecureDomain' (without the quotes).

Open up the 'Security Roles' element in the DDE and add two roles called:

            accountant_role
            clerk_role
          

These should correspond to entries in the MySecureDomain.rolemap file we created earlier (that is, the MySecureDomain authorization domain) in Part I of this document series.

Next, open up the 'Security Constraints' element in the DDE and add a security constraint called (say) 'MyWebAppConstraints'. As the authorized roles for this domain, check both 'accountant_role' and 'clerk_role'.

We now need to define which URLs are protected. To 'MyWebAppConstraints' in the DDE, right-click and add a new Web Resource Collection and give it a name such as 'MySecureColl'. For this Collection, add a URL pattern:

            /*
          

For the above URL pattern, associate it with both the HTTP GET and POST methods.

We now need to tell the web application the name of the realm used for authentication. In the DDE, when the toplevel structural information for that archive is selected, open up the 'Login' tab on the right. Select the 'Basic' mechanism and in Realm name enter 'MyRealm'. Again, the name of the realm corresponds to that used in Part I of the document series when setting up security for Borland Enterprise Server.

Deploy the web application to Borland Enterprise Server's partition. Once this is done, point your web browser to the web application and try accessing one of the protected URLs (http://hostname:8080/MyWebApp/MyFile.html).

The browser will prompt you to enter a user name and password via a dialog prompt. Entering a valid combination (krish/krishpwd, scott/scottpwd) will result in access to the requested web resource. That concludes basic authentication mechanisms. Other mechanisms to authenticate web clients can be employed - such as a login page which is form based or using certificates etc,.

We will now show how security identities can propagate from the Web Container to the EJB Container seamlessly. In Part I of the document series, we showed how standalone Java clients accessed a secure EJB Container. Access in that case was based on roles that clients were assigned and how method permissions on EJBs were defined in a declarative manner. The same principles apply to web-based clients as well. Once a successful authentication has occurred, the Web application (servlets, JSPs etc,) can invoke methods on a secure EJB Container. Depending on the role that the web client is in, the EJB Container will allow or deny access.

Create a servlet/jsp as a part of the web application that invokes methods on the CalculatorSession EJB (Part I of this document series). When the client accesses the servlet/jsp via the web browser, the client is first authenticated against Borland Enterprise Server's security realm. This authentication takes place when the user enters his username and password for that realm from the browser.

When the servlet/jsp invokes methods on the EJB, the identity is propagated to the EJB Container where authorization occurs depending on the role(s) of the web client and EJB method permissions defined.

If the Web and EJB containers are not colocated in the same partition, then the call will fail. In fact this is true for any (secure) call that crosses partitions - for example (a) when an Servlet/JSP in one partition invokes a method on an EJB in another partition or (b) when an EJB in one partition invokes a method on an EJB in another partition.

In fact, in the above scenario, the caller identity is always propagated irrespective of whether the J2EE/CORBA application is colocated or not. The reason the calls fails with a security exception in the non-colocated scenario is because the called partition does not trust the caller partition.

So, the basic mechanism to solve the issue is for the called partition to authenticate the caller partition and not authenticate the credentials of the user again - since the user has already been authenticated by the first tier (caller partition). In effect, only the first tier that the end user accesses needs the (user) authentication entries - the Realm and LoginModule configuration. End tiers do not authenticate the user, but only the caller partition and apply authorization checks on the user 's identity based on roles defined in the authorization domain's rolemap file.

To configure the end tiers to trust a caller partition, the end tiers need the following configuration information: In the application's Authorization Domain rolemap of the end tier partition, enter a role:

            Trusted_Partition {
              *(CN=admin, REALM=ServerRealm)
            }
          

And in the vbroker.properties file of the end tier partition, enter the following property

            vbroker.security.assertions.trust.1=Trusted_Partition@MyDomain
            vbroker.security.assertions.trust.2=Another_Partition@AnotherDomain
            vbroker.security.assertions.trust.3=<.....>
            vbroker.security.assertions.trust.4=<.....> and so on
          

Now, if the application is not colocated, the end tier will receive the user identity (which has been authenticated by the first tier) and the called partition only performs the authorization checks on whether the resource is callable by the role(s) that user is in.

That's about it.

Some interesting links are: