Section 9.3. Restricting Access with web.xml

9.3. Restricting Access with web.xml

We restrict access to the administrative page URLs in web.xml as in Example 9-1.

Example 9-1. web.xml
   ...   <security-constraint>     <web-resource-collection>       <web-resource-name>         JAW Application protected Admin pages.       </web-resource-name>       <description>Require users to authenticate.</description>       <url-pattern>/admin/*</url-pattern>     </web-resource-collection>     <auth-constraint>       <description>         Allow Manager role to access Admin pages.       </description>       <role-name>Manager</role-name>     </auth-constraint>   </security-constraint>   <security-role>     <description>JAW Managers</description>     <role-name>Manager</role-name>   </security-role>   ... 

The <security-constraint> element protects the administrative pages by specifying:

  • A protected URL pattern for the admin pages, /admin/* the protected JSPs reside in the web application's /admin directory.

  • That only users who are in the Manager role can access the administrative page. This role must be specified in a separate <security-role> element.

To be complete, we've also modified the Controller Servlet in Example 9-2 to prefix all administrative pages with the admin/ URL.

Example 9-2.
 public class ControllerServlet extends HttpServlet {     ...     protected void processRequest(HttpServletRequest request,       HttpServletResponse response) throws ServletException, IOException {         ...         // perform action         ...         else if(MODIFY_CAR_LIST_ACTION.equals(actionName))         {             ...             destinationPage = "/admin/carList.jsp";         }         ...     } } 

What About Web-Based Programmatic Security?

The Servlet API enables you to go farther with security and add more fine-grained control to resources by using the following methods on HttpServletRequest:

  • geTRemoteUser( )

  • isUserInRole( )

  • getUserPrincipal( )

These methods determine the user's identity, or whether they play a particular role in the system. You also could write Servlet Filters that protect access to resources and determine if a user has logged in. Many developers write a LoginAction that checks the user's ID and password from a custom form.

Programmatic security is declining in popularity because it clutters your application with security-related calls. Declarative security handles the above scenarios on your behalf so you don't have to write so much code. Before using these API calls, see if J2EE Declarative Security can meet all or most of your needs.

But declarative security isn't a silver bullet that solves all your problems. What if you have a loan application in which loan officer X can approve loans up to only a certain amount? In this case, you'll have to add some code to enforce this business policy. Even if you really do need to use some form of programmatic security, starting with declarative security will reduce the complexity and the amount of code you write. But in practice, we've seen that declarative security usually satisfies our security needs.

We've protected the administrative pages' URLs so that only authenticated users can access these pages. We now have to choose an authentication method.

9.3.1. Web-Based Authentication

Authentication establishes the user's identity in the system. There are four methods of authentication:

HTTP Basic Authentication

With HTTP Basic Authentication, the container asks for the user's name and password from a pop-up dialog box. The user information sent back to the server is not encrypted.

HTTP Digest Authentication

HTTP Digest Authentication also uses a pop-up dialog, but the username and password are encrypted when sent to the HTTP server. Digest Authentication isn't widely used, and the Servlet 2.4 Specification doesn't require Servlet containers to implement it.

HTTPS Client (or Client-Cert) Authentication

Client-Cert Authentication uses Secure Sockets Layer (SSL) Certificates, and the server determines whether the certificate from the client is valid.

Form-based Authentication

When the user clicks on a protected page, she is redirected to an application-specific login page. If the user enters a valid user ID and password, she's allowed to access the protected resource(s). Otherwise, the user is redirected to a custom login error page.

What About Configuring SSL on JBoss?

Since JBoss uses Tomcat as its Servlet container, you are going to do the same type of setup that you have always done before. Go into the Tomcat SAR subdirectory of your server configuration's deployment directory$JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar. Edit the server.xml file and uncomment the <Connector> element for SSL that listens on port 8443. Then, use the Java keytool program to generate a certificate and copy it to your server configuration's conf directory$JBOSS_HOME/server/default/conf.

9.3.2. Form-Based Authentication

We're using Form-based authentication because it is the most commonly used authentication technique and we want to use our own login page. Example 9-3 shows how we configure Form-based authentication in web.xml.

Example 9-3. web.xml
   ...   <login-config>     <auth-method>FORM</auth-method>     <realm-name>JawJaasDbRealm</realm-name>     <form-login-config>       <form-login-page>/login.jsp</form-login-page>       <form-error-page>/loginError.jsp</form-error-page>     </form-login-config>   </login-config>   ... 

The <realm-name> element specifies the name of our security realm, and its textual value, JawJaasDbRealm, must match the name of the security realm specified in the JBoss JAAS login configuration file. We'll see the login.jsp and loginerror.jsp pages in action in the "Testing Secure JSPs" section. For now, let's take a closer look at the login page.

9.3.3. The Login Form

Example 9-4 is an excerpt from the form in the login.jsp page.

Example 9-4. login.jsp
 <form method="POST" action="j_security_check">   <input type="text" name="j_username">   <input type="password" name="j_password"> </form> 

Form-based Authentication requires the following naming conventions on the login form :

  • The user ID and password fields must be named j_username and j_password, respectively.

  • The form must post the user login information to j_security_check.

  • Everything else (the appearance and location of the login and error page) is under our control.

9.3.4. Automating Declarative Authentication and Authorization in web.xml

In web.xml, we had to add the <security-constraint>, <security-role>, and <login-config> elements to set up Form-based authentication, but XDoclet doesn't provide a way to generate these elements. We could've hardcoded these elements, but this wouldn't fit with our Ant-based build process. So we created an XDoclet merge file called web-security.xml that XDoclet merged in as it generated web.xml. You can find web-security.xml in the xdoclet/merge directory in the ch09-a project's webapp sub-project that comes with the JAW Motors code distribution.

9.3.5. Creating a Security Realm

We're now going to create a security realm using database tables that associates a user with the roles he plays in the system. Table 9-1 shows the Users from the USER table.

Table 9-1. JAW Motors USER table










Table 9-2 shows the JAW Motors application's Roles in the ROLE table.

Table 9-2. JAW Motors ROLE table





Now we need to specify the roles for each user in the system. Table 9-3 shows the USER_ROLE table that shows which roles a user has by joining the USER and ROLE tables.

Table 9-3. JAW Motors USER_ROLE table







When joined with the USER and ROLE tables, the data in the USER_ROLE table indicates that both users have the Manager role. You can find these new security-related tables in the ch09-a project's sql/build.xml file.

Now that we've set up declarative security and created a security realm, we need to deploy the security realm on JBoss. Before we can discuss web-based security any further, we need to cover core JAAS concepts because the JBoss security manager, JBoss Security Extension (JBossSX), is based on JAAS. After discussing the core JAAS API, we'll then get to the heart of JAAS-based securitythe LoginModule.

JBoss at Work. A Practical Guide
JBoss at Work: A Practical Guide
ISBN: 0596007345
EAN: 2147483647
Year: 2004
Pages: 197

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: