There are several sample web applications that are available with the project. To avoid an overly large download, only the "tutorial" and "contacts" samples are included in the distribution zip file. You can either build the others yourself, or you can obtain the war files individually from the central Maven repository. We'd recommend the former. You can get the source as described in the introduction and it's easy to build the project using Maven. There is more information on the project web site at http://www.springframework.org/spring-security/ if you need it. All paths referred to in this chapter are relative to the source directory, once you have checked it out from subversion.
The tutorial sample is a nice basic example to get you started. It uses
simple namespace configuration throughout. The compiled application is included in the
distribution zip file, ready to be deployed into your web container
(spring-security-samples-tutorial-2.0.x.war
).
The form-based
authentication mechanism is used in combination with the commonly-used
remember-me
authentication provider to automatically remember the login using
cookies.
We recommend you start with the tutorial sample, as the XML is
minimal and easy to follow. Most importantly, you can easily add
this one XML file (and its corresponding web.xml
entries) to your existing
application. Only when this basic integration is achieved do we
suggest you attempt adding in method authorization or domain object
security.
The Contacts Sample is quite an advanced example in that it illustrates the more powerful features of domain object access control lists in addition to basic application security.
To deploy, simply copy the WAR file from Spring
Security distribution into your container’s webapps
directory. The war should be called spring-security-samples-contacts-2.0.0.war
(the appended version number will vary depending on what release you are using).
After starting your container, check the application can load.
Visit
http://localhost:8080/contacts
(or whichever URL is appropriate for your web container and the WAR
you deployed).
Next, click "Debug". You will be prompted to authenticate, and a series of usernames and passwords are suggested on that page. Simply authenticate with any of these and view the resulting page. It should contain a success message similar to the following:
Authentication object is of type: org.springframework.security.providers.UsernamePasswordAuthenticationToken
Authentication object as a String:
org.springframework.security.providers.UsernamePasswordAuthenticationToken@1f127853:
Principal: org.springframework.security.userdetails.User@b07ed00:
Username: rod; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true;
credentialsNonExpired: true; AccountNonLocked: true;
Granted Authorities: ROLE_SUPERVISOR, ROLE_USER; Password: [PROTECTED]; Authenticated: true;
Details: org.springframework.security.ui.WebAuthenticationDetails@0:
RemoteIpAddress: 127.0.0.1; SessionId: k5qypsawgpwb;
Granted Authorities: ROLE_SUPERVISOR, ROLE_USER
Authentication object holds the following granted authorities:
ROLE_SUPERVISOR (getAuthority(): ROLE_SUPERVISOR)
ROLE_USER (getAuthority(): ROLE_USER)
SUCCESS! Your web filters appear to be properly configured!
Once you successfully receive the above message, return to the
sample application's home page and click "Manage". You can then try
out the application. Notice that only the contacts available to the
currently logged on user are displayed, and only users with
ROLE_SUPERVISOR
are granted access to delete their
contacts. Behind the scenes, the
MethodSecurityInterceptor
is securing the business
objects.
The application allows you to modify the access control lists associated with different contacts. Be sure to give this a try and understand how it works by reviewing the application context XML files.
The LDAP sample application provides a basic configuration and sets up both a namespace configuration and an equivalent configuration using traditional beans, both in the same application context file. This means there are actually two identical authentication providers configured in this application.
The CAS sample requires that you run both a CAS server and CAS client. It isn't included in the distribution so you should check out
the project code as described in the introduction. You'll find the relevant files under the
sample/cas
directory. There's also a Readme.txt
file in there which explains how to run
both the server and the client directly from the source tree, complete with SSL support. You have to download the CAS Server web application
(a war file) from the CAS site and drop it into the samples/cas/server
directory.
This sample application demonstrates how to wire up beans from the pre-authentication framework to make use of login information from a J2EE container. The user name and roles are those setup by the container.
The code is in samples/preauth
.