Container Managed Security in tomcat 7
Resources within web application can be secured with declarative syntax in the web.xml.
This is the easiest way to implement security layer for your web application.
Three steps to add security to your web application
Ø prepare deployment descriptor with security elements
Ø define roles and user credentials in the conf/tomcat-users.xml (in memory)
Ø add realm value in the conf/services.xml
Prepare deployment descriptor with security elements
There are three direct child elements for <web-app> root element which does this functionality inside the web.xml
1. <security-constraint>
2. <login-config>
3. <security-role>
1. security-constraint: A security constraint is used to define the access privileges to a collection of resources using their URL mapping. The following elements can be part of a security constraint:
i. Web-resource-collection: here we need to specify URL pattern for which we need to secure and http method we have to allow for those operations.
<web-resource-collection>
<web-resource-name>REST_WS</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
ii. Auth-constraint: need to define role for which we allowing the access. This role should have an entry in the tomcat-users.xml file under conf folder.
<auth-constraint>
<role-name>WS_SECURITY</role-name>
</auth-constraint>
iii. User-data-constraint: (optional for this tutorial) this is only requires when have enabled https protocol. Allowed values are
· CONFIDENTIAL: trying to access secure resources through Https . redirects to https after authentication
· INTEGRAL: trying to access all the resources through Https. redirects to https before authentication
· NONE: access the resources with both the protocols (HTTP, https)
- Specify CONFIDENTIAL when the application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission.
- Specify INTEGRAL when the application requires that the data be sent between client and server in such a way that it cannot be changed in transit.
- Specify NONE to indicate that the container must accept the constrained requests on any connection, including an unprotected one.
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
2. login-cofig: this is used to specify authentication mechanism. Following values are allowed for this element. For BASIC and DIGEST below prompt will displayed to enter
credentials. Realm name what you supplied in the web.xml will be display in
this popup. Here it is BASIC AUTHENTICATION
Ø BASIC: this is simple way of authentication, but it is not much secured. Username, password is send through base-64 encoding and one can easily intercept and decode the data.
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>file</realm-name>
</login-config>
Ø FORM: this is useful when we want design our own customized login form. But the credentials are passed to server as plain text.
<login-config>
<auth-method>FORM</auth-method>
<realm-name>file</realm-name>
<form-login-config>
<form-login-page>/logon.jsp</form-login-page>
<form-error-page>/logonError.jsp</form-error-page>
</form-login-config>
</login-config>
Addition steps for this form based authentication is need to design login form with below details in the form-login-page.
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
</form>
Ø DIGEST: Like HTTP Basic Authentication, HTTP Digest Authentication authenticates a user based on a username and a password. However, unlike HTTP Basic Authentication, HTTP Digest Authentication does not send user passwords over the network. In HTTP Digest authentication, the client sends a one-way cryptographic hash of the password (and additional data). Although passwords are not sent on the wire, HTTP Digest authentication requires that clear text password equivalents be available to the authenticating container so that it can validate received authenticators by calculating the expected digest.
<login-config>
<auth-method>DIGEST</auth-method>
</login-config>
Ø CLIENT-CERT: this requires additional public key generation can be read at
3. security-role: define the security role same as mentioned in the auth-constraint.
<security-role>
<role-name>WS_SECURITY</role-name>
</security-role>
Resultant file looks like as shown below
<security-constraint>
<web-resource-collection>
<web-resource-name>REST_WS</web-resource-name>
<description/>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>WS_SECURITY</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>BASIC AUTHENTICATION</realm-name>
</login-config>
<security-role>
<role-name>WS_SECURITY</role-name>
</security-role>
Define roles and user credentials in the tomcat-users.xml
1. Open the the tomcat-users.xml file under conf folder of your tomcat
2. Define your own username, password and roles in this file
<user username="jaxrs" password="jaxrs" roles="WS_SECURITY"/>
3. Make sure the same role you have mentioned in the web.xml
Define realm in the services.xml under conf folder
Add below realm element under <Engine> element of services.xml
<Realm className="org.apache.catalina.realm.MemoryRealm" />
NOTE: Read more about realms, if you want to take these credentials from database instead of tomcat-users.xml
Comments
Post a Comment