Head first Servlets and Jsp Chapter 12 Short Notes

Web app Security

Coverage:

1. Security issues: Authentication, Authorization, data integrity and confidentiality
2. Security configurations in DD
3. Describe authentication mechanisms (BASIC, DIGEST, FORM and CLIENT-CERT)

1. Importance
	Authentication - Medium
	Authorization - High
	Confidentiality - Low
	Data Integrity - Low

2. Authentication & Authorization example

Problem with tomcat-users.xml is every time you change, we need to restart the server to reload the table

Authentication Step1:

tomcat-users.xml
	<tomcat-users>
		<role rolename="guest"/>
		<role rolename="member"/>
		<user username="vicky" password="vicky123" roles="guest,member" />
		.......
	</tomcat-users>

Authentication Step2:

Enabling the authentication
in DD,

<login-config>
	<auth-method>BASIC</auth-method>
</login-config>

Authorization Step 1:

Map the vendor specific roles in DD

<security-role><role-name>guest</role-name></security-role>
<security-role><role-name>member</role-name></security-role>

Now container can map roles with the users & hence with the resources

<web-app>
	<security-constraint>
		<web-resource-collection>
			<web-resource-name>MandatoryNameUsedByTools</web-resource-name>

			<url-pattern>/Beer/Dish/*</url-pattern>
			/Beer/recipe/*

			<http-method>GET</http-method>
			<http-method>POST</http-method>
		</web-resource-collection>

		<auth-constraint>
			<role-name>guest</role-name>
			<role-name>member</role-name>
		</auth-constraint>
	</security-constraint>

</web-app>

* Can have more than one <web-resource-collection> for a <security-constraint>
* And <auth-constraint> is common/applies for all security constraints
* <http-method>ANY<http-method> says all methods are allowed for the role if specified
* Here constraints are not at RESOURCE lever but they are at REQUEST level

Ex: If url pattern is specified with HTTP method and mapped roles, then these roles are contained by url based on the HTTP method
* Like wise if you specify one <http-method>, then all the other methods are unconstrained!
Good practice;
1. Do not specify ANY in <http-method>
2. Specify particular http method to apply the constraint

<role-name> rules:

* Within <auth-constraint> this element is optional
* If role is specified, only that role is allowed for authentication
* If <role-name> is NO, then no user is allowed
* If <role-name> is * then all users are allowed
* Role names are case-sensitive

<auth-constraint> rules:

* It's an optional stuff
* If exists, container must perform authentication
* If not present, container must present unauthenticated access to the URLs
* <auth-constraint/> -> then no roles are allowed access !
* <auth-constraint>NO</auth-constraint> - All are allowed

* NOTE:- Here the access or non-access is applicable only for users / clients who tried to enter directly.
* And rules does not apply for a request dispatch internally happening !

Programmatic Security:

In HttpServletRequest, there are 3 methods which could be used to achieve programmatic security

* getUserPrinciple() and getRemoteUser() are 2 methods not discussed for the exam

* isUserInRole() 

	1. If the user is not authenticated, then this method returns false
	2. If authenticated, the container checks if the user is mapped to the role
	3. If the user is mapped under the role (passed as argument), then returns true

Declarative side of Programmatic Security:

<web-app>
....
	<servlet>
		<security-role-ref>
			<role-name>manager</role-name>
			<role-link>admin</role-link>
		</security-role-ref>
	</servlet>

	<security-role>
		Admin
	</security-role>

</web-app>

<security-role-ref> element maps programmatic role (hard-coded) names to the declarative role names (actual)

* In the above example, the developer has hard-coded "manager" as the role name in code but the company uses "admin" as <security-role>.
	So in this case we can link the actual role with the used role (programmatic) in code
* Container will use <security-role-ref> even if the role matches with the actual <security-role>. Hence it always takes precedence.

Authentication types

* BASIC
	<login-config>
		<auth-method>BASIC</auth-method>
	</login-config>

	Basic form sends the data in encoded (non-encrypted) form which is not strong. It uses base64 scheme of encoding
* DIGEST
	<login-config>
		<auth-method>DIGEST</auth-method>
	</login-config>

	Not supported much because of its weakness
* CLIENT-CERT
	<login-config>
		<auth-method>DIGEST</auth-method>
	</login-config>
	It uses the public key encryption and is v.rarely used because client has to keep the certification which does not happen in most of the cases
* FORM
	It allows the developer to create his own custom form (html) with input controls
	This is the weakest of all methods and has no encryption
In dd
	<login-config>
		<auth-method>DIGEST</auth-method>
		<form-login-config>
			<form-login-page>/loginPage.html</form-login-page>
			<form-error-page>/loginError.html</form-error-page>
		</form-login-config>
	</login-config>

In loginPage.html

	<form method="post" action="j_security_check">
		<input type="text" name="j_username"/>
		<input type="password" name="j_password"/>
		<input type="submit" value="Login/Enter"/>
	</form>

In loginError.html
	<b>Sorry entered invalid login info</b>

Data Integrity and Confidentiality:
	These can be maintained by using the HTTPS with ssl (remember verisign for ssl certificates !). This comes handy in the custom FORM based authentication.

This can be achieved with the help of <user-data-constraint> element which needs to be placed under <security-constraint>

<webapp>
	<security-constraint>
		...........

		<user-data-constraint>
			<transport-guarantee>CONFIDENTIAL</transport-guarantee>
		</user-data-constraint>
	</security-constraint>
</webapp>

NONE - default and means no data protection
INTEGRAL - data must not be changed along the way
CONFIDENTIAL - Data must not be seen by anybody along the way

here both INTEGRAL and CONFIDENTIAL means the same in most of the container implementations

Advertisement