In this spring security tutorial we will discuss about some of the security tips about the Spring Framework. Spring Security is a powerful and highly customization authentication and access-control framework to secure Spring-based Java web application.
Spring Security Introduction-
Spring Security is a customizable authentication and access service framework for server side Java-based enterprise software applications. The Spring security OAuth provides a method for making authenticated HTTP requests using a token – an identifier used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. Instead of sharing their credentials with the client, resource owners grant access by authenticating directly with the authorization server which in turn issues a token to the client. The client uses the token (and optional secret) to authenticate with the resource server and gain access.
As you probably know two major areas of application security are “authentication” and “authorization” (or “access-control”). These are the two main areas that Spring Security targets.
1. “Authentication” is the process of establishing a principal is who they claim to be (a “principal” generally means a user, device or some other system which can perform an action in your application).
2. “Authorization” refers to the process of deciding whether a principal is allowed to perform an action within your application. To arrive at the point where an authorization decision is needed, the identity of the principal has already been established by the authentication process. These concepts are common, and not at all specific to Spring Security.
“Authentication” is the assurance that the user is actually the user he is claiming to be, for example, when the user logs into any application and gives his credentials, he authenticates himself. At the authentication level, spring supports various authentication models such as Http Basic authentication, Form Based authentication.
“Authorization” is the assurance that the user is allowed to access only those resources that he is authorized to use. For example, in a corporate application, there are some parts of an application where only admin have access and to some parts all the employees have access. These access rules are determined by the access rights given to each user of the system. At the authorization level, spring targets three main areas: authorizing web request, authorizing whether methods can be invoked and authorizing access to individual domain object instances.
Sometimes the mere process of authentication isn’t enough. Sometimes you need to also differentiate security based on the way a principal is interacting with your application. For example, you might want to ensure requests only arrive over HTTPS, in order to protect passwords from eavesdropping or end users from man-in-the-middle attacks. This is especially helpful to protect password recovery processes from brute force attacks, or simply to make it harder for people to duplicate your application’s key content. To help you achieve these goals, Spring Security fully supports automatic “channel security”, together with JCaptcha integration for human user detection.
Irrespective of how authentication was undertaken, Spring Security provides a deep set of authorization capabilities. There are three main areas of interest in respect of authorization, these being authorizing web requests, authorizing whether methods can be invoked, and authorizing access to individual domain object instances. To help you understand the differences, consider the authorization capabilities found in the Servlet Specification web pattern security, EJB Container Managed Security and file system security respectively. Spring Security provides deep capabilities in all of these important areas, which we’ll explore later in this reference guide.
Following are the some of the important facilities that Spring Security Framework provides to it’s users:
- User authentication and authorization.
- Role based authorization control.
- Easy to configure with database based authentication and authorization.
- Encrypted password.
- Form authentication.
- File bases user authentication and authorization.
- The project was started in late 2003 as ‘Acegi Security‘by Ben Alex
- Subsequently, Acegi was incorporated into the Spring portfolio as Spring Security, an official Spring sub-project.
- The first public release under the new name was Spring Security 2.0.0 in April 2008, with commercial support and training available from SpringSource
Acegi is the most used web project security tools in respect of Java web development. Acegi is a security framework for authentication, authorization and role based authorization of the users. Spring Security is an implementation of Acegi referral API. Spring Security Framework provides a lot of facilities to take care of the java web enterprise security management. Its really great security framework that work with Spring IoC or DI to inject the dependencies and securing the java web application.
Security Namespace Configuration-
A namespace element can be used simply to allow a more concise way of configuring an individual bean or, more powerfully, to define an alternative configuration syntax which more closely matches the problem domain and hides the underlying complexity from the user.
To start using the security namespace in your application context, you first need to make sure that the spring-security-config jar is on your classpath. Then all you need to do is add the schema declaration to your application context file:
<beans xmlns:security="http://www.springframework.org/schema/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/beans" xsi:schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.3.xsd"> ... </beans>
Getting Started with Security Namespace Configuration-
In this section, we’ll look at how you can build up a namespace configuration to use some of the main features of the framework. Let’s assume you initially want to get up and running as quickly as possible and add authentication support and access control to an existing web application, with a few test logins. Then we’ll look at how to change over to authenticating against a database or other security repository. In later sections we’ll introduce more advanced namespace configuration options.
1 web.xml Configuration-
<filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
This provides a hook into the Spring Security web infrastructure. DelegatingFilterProxy is a Spring Framework class which delegates to a filter implementation which is defined as a Spring bean in your application context. In this case, the bean is named “springSecurityFilterChain“, which is an internal infrastructure bean created by the namespace to handle web security. Note that you should not use this bean name yourself. Once you’ve added this to your web.xml, you’re ready to start editing your application context file. Web security services are configured using the <http> element.
2. A Minimal <http> Configuration-
<http auto-config="true"><intercept-url pattern="/**" access="ROLE_USER" /></http>
Which says that we want all URLs within our application to be secured, requiring the role ROLE_USER to access them. The <http> element is the parent for all web-related namespace functionality. The <intercept-url> element defines a pattern which is matched against the URLs of incoming requests using an ant path style syntax. The access attribute defines the access requirements for requests matching the given pattern. With the default configuration, this is typically a comma-separated list of roles, one of which a user must have to be allowed to make the request. The prefix “ROLE_” is a marker which indicates that a simple comparison with the user’s authorities should be made. In other words, a normal role-based check should be used. Access-control in Spring Security is not limited to the use of simple roles (hence the use of the prefix to differentiate between different types of security attributes). We’ll see later how the interpretation can vary.
The above configuration declares that all the urls in the application will be intercepted for the security checks and the urls can only be accessed by the user with role ROLE-USER. The attribute “auto-config=true“ defines three elements <form-login/>, <http-basic/> and <logout>.The default configuration always chooses http-basic authentication model. If the model needs to be changed to the form-login model, then the following configuration is needed.
Element : httpContainer element for HTTP security configuration. Multiple elements can now be defined, each with a specific pattern to which the enclosed security configuration applies. A pattern can also be configured to bypass Spring Security’s filters completely by setting the “secured” attribute to “false”.
Content Model : (intercept-url | access-denied-handler | form-login | openid-login | x509 | jee | http-basic | logout | session-management | remember-me | anonymous | port-mappings | custom-filter | request-cache | expression-handler)*
Automatically registers a login form, BASIC authentication, anonymous authentication, logout services, remember-me and servlet-api-integration. If set to “true”, all of these capabilities are added (although you can still customize the configuration of each by providing the respective element). If unspecified, defaults to “false”.
You can use multiple <intercept-url> elements to define different access requirements for different sets of URLs, but they will be evaluated in the order listed and the first match will be used. So you must put the most specific matches at the top. You can also add a method attribute to limit the match to a particular HTTP method (GET, POST, PUT etc.). If a request matches multiple patterns, the method-specific match will take precedence regardless of ordering.
<authentication-manager> <authentication-provider> <user-service> <user authorities="ROLE_USER, ROLE_ADMIN" name="dinesh" password="dineshpassword"> <user authorities="ROLE_USER" name="sweety" password="sweetypassword"> </user></user></user-service> </authentication-provider> </authentication-manager>
The configuration above defines two users, their passwords and their roles within the application (which will be used for access control). It is also possible to load user information from a standard properties file using the properties attribute on user-service. See the section on in-memory authentication for more details on the file format. Using the <authentication-provider> element means that the user information will be used by the authentication manager to process authentication requests. You can have multiple <authentication-provider> elements to define different authentication sources and each will be consulted in turn.