J2EE Authorization





J2EE Authorization

Authorization is the process of controlling access to resources. The basic process of authorization involves an idea called an access control list, which is a way of specifying a mapping between users and resources, and showing which users have access to which resources.

J2EE bases its authorization model on the notion of a role. You can think of a role as a job that a user might perform; for example, clerk, manager, or supervisor. Each user may participate in more than one role.

Each J2EE component (a servlet, or an EJB, for instance) is associated with a set of abstract, developer-defined roles that are granted access to run the methods of a particular EJB, or to use a particular servlet or JSP. At deployment time, these abstract roles are mapped to actual users that are stored in the user registry. To facilitate this, WebSphere keeps a mapping of groups and users in the user registry to J2EE roles, so you must configure this as part of the deployment process of your application.

Here's how it works. Roles may have different access rights to the same resource. Let's say we were working in a bank where we have two roles: tellers and loan officers. If you're a loan officer you need to be able to view a person's bank account balance to determine if she is a good credit risk. So, if we had an account EJB, LoanOfficers should be allowed to call getAccountBalance()on that EJB. On the other hand, Tellers can call not only getAccountBalance()in order to tell a depositor how much money she in that account, but also the deposit()and withdraw()methods to update the account balance.

Likewise, if we had a servlet called AdminServlet that allowed someone to perform administration functions in your application, you would want to restrict access to that servlet to users who were in the admin role. It is important to understand the roles are specific to each application. Thus, the admin role we are describing is unrelated to the administrator role used in the administration of WAS.

Security in the WebSphere Administrative Console

Remember from our earlier discussions that the WebSphere administration console is really just another WebSphere application that runs

on an application server (in the core product) or on a deployment manager server (in the ND product). Just as with your own applications, the WebSphere administrative subsystem is protected through WebSphere's J2EE role-based security mechanism. WebSphere defines a number of administrative roles to provide levels of authority needed to perform WebSphere administrative functions from the Web-based admin console. The authorization policy is only enforced when global security is enabled. Administrative roles provide authorization for groups and users:

  • Monitor— Least privileged, allows a principal to view the WebSphere configuration and current state

  • Configurator— Monitor privileges plus the ability to configure WebSphere

  • Operator— Monitor privileges plus the ability to change the WebSphere runtime state

  • Administrator— Operator privileges plus configurator authority.

You can add or remove principals such as users and groups to the administrative roles from the WebSphere admin console at anytime. A best practice is to map groups rather than individual users to admin roles because it is easier to administer. By mapping a group to an admin role, adding or removing users occurs outside of WebSphere and doesn't require a server restart for the change to take effect.


1 Specifying Authorization in the Web Container

As you can imagine from the way in which authentication was specified in the Web deployment descriptor, authorization is similarly specified there as well. The basic mechanism in specifying Web container authorization is to create a set of tuples of role, resource, and action through the security constraint tag in the web.xml.

This XML element will usually contain two subelements, Web-resource-collection and auth-constraint. (A third possible subelement, user-data-constraint, can be used to ensure that a particular collection should be accessed through either HTTP or HTTPS, but it will not enter into this discussion.) The Web-resource-collection element is used to specify a named collection of URL patterns and HTTP methods that can be used to access those elements.

So, if we wanted to limit deposits and withdrawals in our imaginary bank to only Tellers, we would first create a Web-resource collection containing the URLs to the servlets and JSPs that implement those functions.

The second part of the security-constraint element is the auth-constraint subelement. This XML element is used to define a collection of J2EE role names. These role names are references to role names declared elsewhere in the web.xml file in a security-role tag. So, putting it all together, the security portions of the web.xml in our bank example might look like Listing 29.2.

A security portion of a web.xml file

<security-constraint>

      <web-resource-collection>

           <web-resource-name>Protected Area</web-resource-name>

        <!-- Define the context-relative URL(s) to be protected -->

            <url-pattern>/finance/account/*.jsp</url-pattern>

            <url-pattern>/finance/account/MakeDepositServlet</url-pattern>

            <url-pattern>/finance/account/MakeWithdrawalServlet</url-pattern>

          <!-- If you list http methods, only those methods are protected -->

            <http-method>GET</http-method>

            </web-resource-collection>

         <auth-constraint>

            <!-- Anyone with one of the listed roles may access this area -->

            <role-name>Teller</role-name>

       </auth-constraint>

 </security-constraint>

<security-role>

<role-name>Teller</role-name>

</security-role>

One of the interesting things about the way that Web-resource collections are specified is that what you are specifying here are particular URLs and not individual servlets and JSPs declared elsewhere in the Web deployment descriptor. This makes it possible, for instance, to easily declare different security constraints on different parts of a struts application. Since in the struts deployment descriptor you declare the full URL of each action, you can simply add that complete URL to a Web-resource-collection in a security-constraint element.

2 Specifying Authorization in the EJB Container

While there are some parallels between the way security elements are specified in the EJB deployment descriptor and the Web deployment descriptor, there's not a one-to-one correspondence. However, the basic idea is the same: You want to specify a set of tuples of role, EJB, and method on that EJB just as you earlier specified tuples of role, URL, and HTTP method to be used to access that URL.

Unlike in the Web deployment descriptor, there's no top level security element per se. This often confuses people when they're learning how to read an EJB deployment descriptor. Instead, security elements are contained inside the assembly-descriptor element along with other items general to either all the EJBs in the EJB JAR file or a subset of those EJBs. This is, by the way, the same place where elements like container-managed transactions are declared, as described in Chapter 28.

The first subelement we'll need to deal with is the security-role element. This element has the same meaning as it has in the Web deployment-descriptor; it allows you to declare a particular security role to be used elsewhere. The second subelement we will examine is more interesting. The method-permission element is roughly analogous to the security-constraint element we saw earlier. In a method-permission element, you specify a set of roles, and then a set of method elements. Each method element corresponds to one or more methods on a particular EJB. This can include methods defined on the local or remote interface, or even in the home or local home interfaces. Wildcards (*) are also allowed if you want to specify all methods for an EJB.

So, our bank example, which would allow Tellers to access the account balance, deposit, and withdraw from an account, while LoanOfficers can only check an account balance, would have the elements shown in Listing 29.3 in its deployment descriptor.

Specifying the web.xml assembly descriptor

<assembly-descriptor>

       <security-role>

              <role-name>Tellers</role-name>

       </security-role>

       <security-role>

              <role-name>LoanOfficers</role-name>

       </security-role>

       <method-permission>

              <role-name>Tellers</role-name>

              <method>

                     <ejb-name>Account</ejb-name>

                     <method-name>deposit</method-name>

              </method>

              <method>

                     <ejb-name>Account</ejb-name>

                     <method-name>withdraw</method-name>

              </method>

              <method>

                     <ejb-name>Account</ejb-name>

                     <method-name>getAccountBalance</method-name>

              </method>

       </method-permission>

       <method-permission>

              <role-name>LoanOfficers</role-name>

              <method>

                     <ejb-name>Account</ejb-name>

              <method>

                     <ejb-name>Account</ejb-name>

                     <method-name>getAccountBalance</method-name>

              </method>

       </method-permission>

</assembly-descriptor>

There is another option for the role-name in method permissions. Within the method-permissions element, the role-name element can contain one or more roles or the special element Unchecked. Unchecked means that method permissions will not be checked for the methods specified within this permissions element. This can be potentially useful, for instance, in reducing the security overhead of local interfaces by turning off all authorization checking for local interface methods.

There is another section of the method-permissions element that we haven't examined, called the excludes list. Methods added to the exclude-list element cannot be called at all. While this sounds like insanity of the first order (why have a method that can't be called) you can imagine situations where test methods can be allowed to be called in development, but restricted in production. There are many other options for specifying the details of security in the deployment descriptor. For more information on those options beyond this basic survey, see [EJB20] or [Monson-Haefel].


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows