Spring Security Essentials

Custom security realms facilitate you to use an existing data store such as a directory server or database when authenticating and authorizing users to enterprise applications, which are deployed in a standard application server, such as WebSphere, JBoss, and so on. We will have to provide the attribute details to the server to create the user realms such as the name, realm class name, configuration data, and password. We can create a custom realm by providing a custom JAAS login module class and custom realm class. However, when we use the client-side JAAS login modules, this may not be suitable for use with the enterprise server.

There can be two different realms that cater to two different URL patterns. We can use the same authentication logic for both the realms. The standard Spring Security mechanism will invoke j_spring_security_check automatically when a login form is getting called, and we can define our own URLs that are to be intercepted. This approach is called browser-based client security realm. If the user has not been provided with a username and password and if the principal is not created to access this URL, then the user will be redirected to the login page by the Spring Security checker.

There are many types of security constraints. This consists of web resource collections such as URL patterns, HTTP methods, and authorization constraints by providing role names. User data constraints such as web requests are passed over an authenticated transport. A security constraint is used to define the access privileges for a collection of resources using their URL mapping. The security token will be given from an HTTPS request when it gets validated and will be given back to the enterprise application server. There may be possibilities that the security token does not return any valid roles for authorization.

In these scenarios, we will have to set the security authorization constraints in a secured way in the web.xml file. The web resources can have unchecked access, checked access, and no access. We can omit the authorization constraints so that any web resource can access the resource. We can specify the role name for the authorization constraint so that only these roles can access the web resource. We can also exclude a set of web resources from accessing any request by specifying no roles for these resources. We can also exclude particular URLs to access the specific secured web resources.

Method security is a bit more complicated than a simple allow or deny rule. Custom methods can be provided with specific security settings. In Spring, we can achieve this by providing the proper annotations for the methods to be secured. There are four annotations that support expression attributes to allow preinvocation and post-invocation authorization checks and also support the filtering of the submitted collection arguments or return values. They are @PreAuthorize, @PreFilter, @PostAuthorize, and @PostFilter. If you want to create a custom secured method called customCheckUser(), then you can annotate the method with the @PreAuthorize tag for a presecurity check before execution.

While the other security methods focus on servlets and controllers, security method-based authorization deals with the service layer components particularly. We can control various services to be accessed by specific principals. For example, an administrative principal can access only the database credential layer or the logging layer can be accessed by all the principals. The global method security tag or the @EnableGlobalMethodSecurity annotation will help developers in setting up the method level security.

At the class level, we can check whether the intended principal is authorized to invoke the particular instance or not when we create an instance for a particular request. This can be achieved by providing annotations before instantiating the object in order to check the authenticity. This instance-based security is important in handling non-application server-related code or any other code related to the business logic that needs to be closely monitored to prevent non-privileged access.

The approach here is to define the information clearly so that the domain object-based security restrictions can be applied accurately. The Actor who is performing the use case action, the domain acted created internally to perform the action, and the intended action are the three pieces of information that we need to define clearly in order to achieve instance-based authorization. Here comes the usage of ACLs and access control entries (ACEs), which will be elaborated on in further chapters. The advantage of using Spring ACL and ACE here is that Spring has an internal mechanism to manage the ACE volume by implementing the ACE inheritance mechanism so that when a number of domain objects increases, the ACEs also will become manageable.

Spring Web Services (Spring-WS) packages focus mainly on the creation of document-driven web services, where the data communication between web services is done through XML envelopes and web services can be accessed from any other technology application server. The features supported by Spring-WS are powerful XML mappings, support for various XML APIs, flexible XML marshalling, support for WS-Security, and others. WS-Security comprises of three areas—authentication, digital signatures, and encryption/decryption.

The security flow in Spring Web Services will be as follows. The system will generate a security token for a valid principal using a separate web service method. If the user wants to access other web services, he or she should pass this token along with the payload as a security key and these web services will validate this token for authenticity and then allow the users to access the resources. If the token has expired or is invalid, the user should go through the authentication web service once again. This entire mechanism is called message signing.

To achieve Representational State Transfer (REST) services calls with basic security authentication, we will have to depend on the libraries provided by the Spring framework, such as the core, configuration, and web. We also need to make some entries in the Spring application context files.

In real-time scenarios, we will have to get the credentials from Lightweight Directory Access Protocol (LDAP), Database, and others.

Coming to the JSF and Spring Security integration, the Spring web flow provides you with a JSF integration that simplifies the handshake between JSF and Spring. A dedicated Spring Security tag library is available for JSF Security integration. To achieve this, springsecurity.taglib.xml needs to be updated with facelet entries. These modifications must be reflected in web.xml as well. We can include nested contents based on security conditions using the authorize tags. During JSF rendering, many expression language-based functions can be used.

Apache Wicket is designed based on a component-oriented structure and less HTML file handling. Wicket-related security settings must be handled first by modifying the web.xml file for the corresponding filter mapping. As a Wicket programmer, you will need to have a clear understanding about the pull and push concepts and form processing life cycle of the Apache Wicket framework. There are two unique issues to be handled from Wicket. Wicket does not manage the life cycle of its components, and the components and models of Wicket are often serialized, which may be an issue for Spring's dependency injection mechanism. The work around this will be some entries in the Web and ApplicationContext XML files, but this approach will have its own pros and cons, which we will discuss later.

The Spring framework has a JAAS authentication provider, which must be configured in an applicationcontext.xml file. We need to create an array of entries for the URLs that need to be secured. We have to define the security policies for different URLs of the website. JAAS will expect a callback from the user—the username and password. Spring will have this information collected and populated on an authentication object, which will be passed to JAAS as an input.

Security Assertion Markup Language (SAML) is a popular open standard, which simplifies federated user logins. A user can provide credentials to a centralized enterprise registry, and using this principal, the user can access other independent applications that are mapped with the centralized registry.

This is called single sign-on implementation using the Spring and SAML integration. We can also create a common setup to make an enterprise an single sign-on (SSO)-enabled one with the following certain standards. This is based on how we set up Spring and SAML to pass the SAML tokens to the other applications that are using the SSO. We can create a shared cookie that will contain the authorized SAML token. Additionally, we can develop an internal SAML token verifier, which may frequently assess the validity of the token. The securityContext XML file needs to be updated with the IDP metadata. IDP is nothing but the centralized Identity provider.

You must be aware of the LDAP basics, and you can refer to a popular open source LDAP implementation called OpenLDAP if you want to further explore. Spring has an LDAP package that is helpful in accessing many LDAP implementations without bothering much about their internals. This is developed based on the JdbcTemplate package design. Basic operations such as looking up, context initiation and closing, iterating through the results, and encoding/decoding the values are taken care of by this package. On top of this, Spring LDAP comes with various enhanced features such as LDAP template, LDAP context, LDAP filters, LDAP transaction management, and others.

We have seen the various flavors of the Spring Security implementations available in the Spring Framework 4.0.3 along with the Spring 3.2.3 module. We will explore each of these options in detail with practical examples in the coming chapters. We recommend that you have a good understanding of the application development environment for various technologies that we will address, such as LDAP, SAML, Wicket, and so on. In the next chapters, we will explain the security implementations that include the basics of the IDE setup, understanding a sample source code, building mechanisms, and so on.