Perhaps the simplest type of security for beginners to think of is URL-based security. Spring Security allows the securing individual pages using role-based authentication. You can define the roles and the pages to secure, the url to go to when login is successful, or fails, or link your application to an authentication source. Spring Security provides configuration for LDAP, OpenID, CAS and JAAS based authentications.

In order to add url based security, we create a new xml called WEB-INF/applicationContext-security.xml which is mentioned in the web.xml under context-param.

This file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="https://www.springframework.org/schema/security"
	xmlns:beans="https://www.springframework.org/schema/beans" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="https://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                        https://www.springframework.org/schema/security https://www.springframework.org/schema/security/spring-security-3.1.xsd">

<http pattern="/login.jsp" security="none"/>

	<http auto-config="true">
		<intercept-url pattern="/viewAccount.htm"
			access="ROLE_ACCHOLDER,ROLE_MANAGER,ROLE_SUPERVISOR,ROLE_TELLER" />
		<intercept-url pattern="/viewAccountAdmin.htm"
			access="ROLE_MANAGER,ROLE_SUPERVISOR,ROLE_TELLER" />
		<intercept-url pattern="/viewEmployees.htm" access="ROLE_MANAGER" />
		<form-login login-page="/login.jsp" default-target-url="/viewAccount.htm"
			always-use-default-target="false" authentication-failure-url="/login.htm?authfailed=true" />
		<logout invalidate-session="true" logout-url="/logout.jsp"
			logout-success-url="/login.htm?loggedout=true" />
	</http>

	<authentication-manager>
		<authentication-provider>
			<!-- <password-encoder hash="plaintext" /> -->
			<user-service>
				<user name="user1" password="test" authorities="ROLE_MANAGER" />
				<user name="user2" password="test" authorities="ROLE_SUPERVISOR" />
				<user name="user3" password="test" authorities="ROLE_TELLER" />
			</user-service>
		</authentication-provider>
	</authentication-manager>

</beans:beans>

In the above example, the login.jsp has no security applied to it, because we want unauthenticated users to be able to get to the login page. The http element is where you list the pages that you want to secure and which roles have access. The auto-config attribute automatically configures  form login, logout and basic authentication features. The intercept-url uses the pattern property to match the pages against the url request. Since the url’s are matched in order, the more specific patterns should be listed first.

In our example above, we have listed the usernames and passwords in plain text. In a production application, the authentication provider would refer to another bean that provided the user authentication details via a datasource.

It is a common requirement that a particular role in an application should automatically “include” other roles. For example, in an application which has the concept of an “admin” and a “user” role, you may want an admin to be able to do everything a normal user can. To achieve this, you can either make sure that all admin users are also assigned the “user” role. Alternatively, you can modify every access constraint which requires the “user” role to also include the “admin” role. This can get quite complicated if you have a lot of different roles in your application.

The following entries are used to configure a hierarchical based role system:

<bean id="roleVoter" class="org.springframework.security.access.vote.RoleHierarchyVoter">
<constructor-arg ref="roleHierarchy" /></class>
<bean id="roleHierarchy" class="org.springframework.security.access.hierarchicalroles.RoleHierarchyImpl">
			<property name="hierarchy">
				ROLE_ADMIN > ROLE_STAFF
				ROLE_STAFF > ROLE_USER
				ROLE_USER > ROLE_GUEST
			</property></bean>

Role hierarchies offer a convenient means of simplifying the access-control configuration data for your application and/or reducing the number of authorities which you need to assign to a user. For more complex requirements you may wish to define a logical mapping between the specific access-rights your application requires and the roles that are assigned to users, translating between the two when loading the user information.