Lock down access to web pages and commands
Identify user prior to EJB interaction
HTTP Basic Authentication
supported by HTTP protocol
username/password-based
browser collects information from client
authenticates user in a realm
not secure; passwords sent simple base64 encoding
short-comings overcome by layering over SSL (HTTPS)
Form-based Authentication
permits JSP/HTML forms to gather user info
HTTPS
encrypts communication channel
based on public/private key
hides all client/server exchange, including username/password info
Figure 114.1. Example Security Constraints
<security-constraint>
<web-resource-collection>
<web-resource-name>admin-only</web-resource-name>
<url-pattern>/model/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Anything accessed via specified url-pattern must have admin role-name
Communication must be encrypted (i.e., switch to HTTPS)
Figure 114.2. Example FORM-based Login
<login-config>
<!--
<auth-method>BASIC</auth-method>
-->
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/WEB-INF/content/Login.jsp</form-login-page>
<form-error-page>/WEB-INF/content/Login.jsp</form-error-page>
</form-login-config>
</login-config>
Obtain missing user credentials using FORM when navigating to protected urls
Figure 114.3. Example Protected Servlet Mapping
<servlet>
<servlet-name>Handler</servlet-name>
<servlet-class>info.ejava.examples.secureping.web.SecurePingHandlerServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Handler</servlet-name>
<url-pattern>/model/admin/handler</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Handler</servlet-name>
<url-pattern>/model/user/handler</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Handler</servlet-name>
<url-pattern>/model/known/handler</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Handler</servlet-name>
<url-pattern>/model/handler</url-pattern>
</servlet-mapping>
Servlet accessible via multiple URLs
Example Creates Security Hole on Purpose
The example creates a security hole on purpose to be able to demonstrate EJB security backs the WEB security. The servlet mapped above is accessible through multiple URLs -- each restricted differently but attempting to provide the same functionality. If you access the servlet through the anonymous URL you will encounter many access failures communicating with the EJB. If you access the servlet using the admin URL you will be able to access all functionality.
Figure 114.4. WEB-INF/jboss-web.xml: security-domain
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC
"-//JBoss//DTD Web Application 2.4//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">
<jboss-web>
<security-domain>other</security-domain>
</jboss-web>
Assigning web-tier to same security-domain as EJB tier
Figure 114.5.
<html>
<body>
<h1>Login Required</h1>
<form action="j_security_check" method="POST">
User Name:
<input type="text" size="20" name="j_username">
Password:
<input type="password" size="10" name="j_password">
<input type="submit" value="Login">
</table>
</form>
</body>
</html>
form action
j_security_checkis a standard container action for login formsj_usernameinput field name standard for usernamej_passwordinput field name standard for password
uri-path constrained to use only HTTPS
EJB returning formatted string with caller role information
Caller authenticated at web-tier and passed to EJB
EJB and WAR using same security-domain
BASIC authentication requested for any missing credentials
URL selected also not enforcing confidential (i.e., HTTPS)
Authenticate user passed to EJB
EJB rejects unauthorized caller