Section 9.7. Protecting the Administrative Actions


9.7. Protecting the Administrative Actions

We can continue to use J2EE Declarative Security, as shown earlier, to protect the administrative actions like modifyCarList, addCar. To lock down the administrative actions, we'll take steps similar to those we used to protect the JSPs:

  • Associate the administrative actions with an URL pattern.

  • Protect the new administrative action URL pattern.

To associate the admin actions with an URL pattern, we prefix them with admin/ in the JSPs and in the Controller Servlet. For example, index.jsp (the main page) now invokes the modifyCarList action through the Controller Servlet, as in Example 9-9.

Example 9-9. index.jsp
 <html>   <head>     ...   </head>   <body>     <h1>JAW Motors</h1>     <a href="controller/admin/modifyCarList">Modify Inventory</a><br/>     <a href="controller/viewCarList">View Inventory</a><br/>     <a href="controller/viewCreditCheckForm">Run Credit Check</a>   </body> </html> 

The viewCarList action takes you to a read-only page, so it doesn't need any extra security. To fully protect the administrative action URLs, we add a new <url-pattern> to web.xml so that it now looks like Example 9-10.

Example 9-10. web.xml
     <security-constraint>     <web-resource-collection>       <web-resource-name>         JAW Application protected Admin pages and actions.       </web-resource-name>       <description>Require users to authenticate.</description>       <url-pattern>/admin/*</url-pattern>       <url-pattern>/controller/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 new /controller/admin/* <url-pattern> (a sub-element of <web-resource-collection>) finally gives us what we wantit forces the user to log in before accessing secure actions. As before, we add this new <url-pattern> element to the webapp/xdoclet/merge/web-security.xml file, and XDoclet adds the new security to web.xml on our behalf.

9.7.1. Are We Done with Web Security Yet?

At this point, we've secured the web tier and could start testing. But as you'll see in the next section, we need to associate security roles with both secure and non-secure action URL patterns to propagate security credentials from the web tier to the EJB tier. We could have added these modifications later, but we wanted to finish configuring web security before dealing with EJBs.

9.7.2. Propagating Security Credentials from the Web Tier

Specifying an identity for an URL pattern ensures that the Servlet container automatically propagates the correct role to the EJB container when accessing EJB methods. The EJB Security section covers security roles and EJB methods in greater detail. The J2EE specification does not state what happens if the web tier does not establish a user's credentials before calling an EJB, so the JBoss LoginModules enable you to provide a default user identity so calls to unsecured EJB methods succeed if the user hasn't logged in. Recall from the login-config.xml section that we've set up the JBoss LoginModules with an unauthenticated identity called "guest". Example 9-11 shows the changes we made to web.xml.

Example 9-11. web.xml
     <servlet>       <servlet-name>SecureController</servlet-name>       <servlet-class>com.jbossatwork.ControllerServlet</servlet-class>     </servlet>     <servlet>       <servlet-name>NonsecureController</servlet-name>       <servlet-class>com.jbossatwork.ControllerServlet</servlet-class>       <run-as>         <role-name>guest</role-name>       </run-as>     </servlet>     <servlet-mapping>       <servlet-name>NonsecureController</servlet-name>       <url-pattern>/controller/*</url-pattern>     </servlet-mapping>     <servlet-mapping>       <servlet-name>SecureController</servlet-name>         <url-pattern>/controller/admin/*</url-pattern>     </servlet-mapping>     ... 

The new <servlet-mapping> elements for the Controller Servlet ensure that:

  • Any secure page or action (under the /controller/admin/* URL pattern) runs as an authorized user roleManager.

  • Any non-secure page or action (under the /controller/* URL pattern) runs as the unauthenticated guest user identity.

9.7.3. Automating Security Credential Propagation in web.xml

In web.xml , we had to modify the <servlet> and <servlet-mapping> elements to propagate the correct credentials from the Controller Servlet. Thus we modified the XDoclet tags in the Controller Servlet (Example 9-12) to generate the mapping for the SecureController and /controller/admin/* <url-pattern>.

Example 9-12. ControllerServlet.java
 /**  * @web.servlet  *  name="SecureController"  *  * @web.servlet-mapping  *  url-pattern="/controller/admin/*"  *  * ...  */ public class ControllerServlet extends HttpServlet {     ... } 

We also added a new <servlet-mapping> element to web.xml for non-secure URL action patterns (NonSecureServlet). However, XDoclet doesn't provide a way to generate more than one set of these elements for a Servlet. We could have hardcoded these elements in web.xml, but this wouldn't fit with our Ant-based build process. So we created XDoclet merge files called servlets.xml and servlet-mappings.xml files that contain the extra settings, and XDoclet merges them in as it generates web.xml. You can find these files in the xdoclet/merge directory in the ch09-b project's webapp sub-project.

9.7.4. Testing Web Security

Now that we've locked down the administrative portions of the web site, let's test our application to ensure that everything still works properly. Here are the steps to build and deploy the application:

  • Type ant in the root directory of ch09-b to build the project.

  • Shut down JBoss so the Ant script can clean up the JBoss deployment area.

    • Type ant colddeploy to deploy the EAR file (jaw.ear) to the $JBOSS_HOME/server/default/deploy directory.

  • Start JBoss back up.

  • Visit http://localhost:8080/jaw in a web browser.

As advertised, clinking on the "View Inventory" link on the JAW Motors home page takes you to a read-only version of the JAW Motors Inventory page that doesn't require you to log in first. Clicking on the "Modify Inventory" link now takes you to the login page, and you have to enter a valid user ID and password to gain access. After you log in successfully, the Servlet container takes you to the Modify Inventory page. JBoss remembers your security credentials, so once you've logged in, you don't have to re-login each time you try to access a secure action or page. Go ahead and try to add, edit, or delete a car, and you'll see that everything works properly. The big difference is that now you can access these pages and actions only after you've logged into the system.



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

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net