Spring Security. Instructor s Guide. Version 3.2. Copyright Capstone Courseware, LLC. All rights reserved.

Transcription

1 Spring Security Version 3.2 Instructor s Guide Copyright Capstone Courseware, LLC. All rights reserved.

2 Overview This course breaks down into three main parts, each of a certain style, and the degree of difficulty climbs after the first one. Spring Security does such a good job of encapsulating the most common web security requirements that, for a day at least, we can almost forget about Java, and just see this as a black-box tool that requires only a little XML configuration. And so we work almost entirely in applicationcontext.xml. in the first three chapters: overview, authentication, and authorization. A little bit of the underlying API creeps in as we look at password encoders, salt sources, and programmatic authorization. The next three chapters are more Java-oriented, as we look at ways to customize Spring Security and at more AOP and annotation-driven solutions. The two under the hood chapters confront the actual Java API behind all that XML, and we start doing things that really require Java coding, such as custom user realms and authorization constraints. Method-level authorization as covered in Chapter 6 also draws us across the line into Spring applications, where up through Chapter 5 we could apply the security techniques we re learning to any Java web application, Spring or no. The remaining chapters explore extensions for SAML SSO and OAuth, and it gets pretty dense. SAML especially can be a wilderness of XML datatypes, protocols, bindings, etc., and then OpenSAML might impose a big learning curve of its own. We have included a separate, four-chapter module just on SAML and OpenSAML, and you might take as much as a day covering these in detail, but the idea is more to provide an orientation and so these chapters can be covered fairly lightly. See the timeline and chapter notes for more ideas on this. Chapter 7 on the Spring Security SAML Extension gets right to it, though, and while this is a complex tool to use we have isolated most of the boilerplate stuff and try to focus attention on the pieces that are likely to vary from one application to another and that are visible to the developer in configuration and code. Chapter 8 on OAuth takes a similarly practical approach. 2

3 Timeline Day 1 2 hours Module 1, Chapter 1 4 hours Module 1, Chapter 2 Day 2 2 hours Module 1, Chapter 3 2 hours Module 1, Chapter 4 2½ hours Module 1, Chapter 5 Day 3 2½ hours Module 1, Chapter 6 1 hour Module 2, Chapter 1 1 hour Module 2, Chapter 2 ½ hour Module 2, Chapter 3 1 hour Module 2, Chapter 4 Day 4 3 hours Module 1, Chapter 7 3 hours Module 1, Chapter 8 Please see teaching notes on Module 2 later in this guide, for discussion of the appropriate timeline for covering those chapters. 3

4 Tools Deployed with the Lab Software This course s software requires a separate setup of JDK 7, and optionally the Crimson text editor and/or Eclipse. The labs bundle all other required tools and libraries, including the Tomcat server and Spring itself. These will all be found in directories under c:/capstone/tools as described in the Tools page(s) early in the coursebook. An unusual component for this course is the inclusion of the OpenAM identity manager. This serves as the SAML IdP for our SSO exercises. It s a bit of a beast but we ve packaged it in such a way that it should work cleanly without a lot of hassle. In Capstone/SpringSecurity/Tools/OpenAM11.0 is actually a dedicated Tomcat 7 server image, with the OpenAM WAR pre-deployed and ready to be installed on first startup of the server. The server is pre-configured to port 9080, to stay out of the way of all the other web applications you ll use during the course, and endorsed JARs, memory allocations, and timeout limits have been pre-configured. Ant Build Process Though most students will either use Eclipse exclusively or will be happy to let the ant command take care of things, some will want to understand the inner workings here a little better. Each web project in the course has its own build.xml and build.properties files; these rely on centralized targets and properties files to define a routine for building the application and for deploying/undeploying as necessary from the server. There are also targets for supporting processes such as creating databases, configuring the server with data sources, message queues, user records, etc. These are all identified as necessary in the coursebook. For a better look under the hood, see that build.xml imports a series of properties and targets files in a central directory Ant. Some of these targets files import each other as well, forming a loose chain. All the logic for building and deploying can be found here. 4

5 Teaching Notes I hope that the coursebook is sufficiently clear and detailed, and so the following notes just capture a few ideas about how to approach a given topic, additional concepts to add to your lectures and discussions, and any surprises you might encounter. Module 1, Chapter 2 Note that Health application versions starting with the answer code to Lab 2B will only work with hashed passwords; and over Lab 2C we change the hashing algorithm, salt source, and other details. So if you have any need to jump forward or back to illustrate something with this application, remember to run PrimeWithData for the step you re testing, or you re likely to see authentication failures. It s built to run with or without hashing by a default that s appropriate per step, but you can also pass a hash or hash command-line argument to override the default. Module 1, Chapter 4 A good extra exercise after this chapter is to have students draw up a CRC analysis class, responsibility, and collaborator for the major actors in the authentication system. This often helps to sharpen understanding of who exactly does what. It could be done individually or in small groups, and then everyone could compare notes and pull together a consensus diagram on the whiteboard. Classes to include would probably be: AuthenticationManager AuthenticationProvider UserDetailsService SecurityContextHolder SecurityContext Authentication 5

6 Module 1, Chapter 5 The question of how to implement appointment-reminder protection prior to the lab exercises might produce an interesting discussion, and it s a good one to let students mull for a few minutes before proceeding to the two answers given in the book. An interesting point to discuss after the lab: how do we feel about the fact that our new technique exposes the patient s health-plan ID as part of the reminder URL? And if that s not a great idea, what could we do instead? A few possible fixes: (1) keep a map from reminder ID to patient in the database, with obvious performance disadvantages, (2) parse the reminder (or dig it out of the database, which is more likely in the real world) to see whose data it is, and again this will be expensive, or (3) hash the plan ID before putting it in the URL. I like (3) best, but there are other schools of thought, and this should be a good discussion. The end of this chapter is another good spot for a CRC exercise, this time focused on authorization actors: FilterSecurityInterceptor ObjectDefinitionSource AccessDecisionManager AccessDecisionVoter ConfigAttribute ConfigAttributeDefinition Module 1, Chapter 6 After a couple of more challenging chapters, we finish up with something pretty easy, which is method authorization plus domain-object authorization, which is trickier but also mostly out of scope and kept to a quick introduction. Method authorization requires no Java coding, though it does cross a different line, in that applications must be using Spring to manage their secure objects in order to apply this feature. (The same of course is true of domain-object security.) But, with this condition met, method authorization is pretty clean, and it s mostly a matter of deciding between the four (!) different ways that you can configure it. The big divide here is between annotations and external XML configuration, and there are the usual tradeoffs though we don t go into a big discussion of this in the coursebook. 6

7 Module 2 As you can see in the Timeline section, we recommend passing through the four chapters on SAML itself at a faster pace than the rest. We make these available in the course in full detail, with a few hands-on exercises, to support cases in which you find greater interest in the mechanics of SAML, and perhaps in using the OpenSAML API directly. But in most cases it s better to move lightly through these chapters, and identify key SAML concepts such as subjects and name IDs. I recommend firing up a few of the applications: the Attributes application near the beginning is very quick and yet gives a feel for how SAML works, and it will be a good compliment to the very authentication-heavy material to come. Also some focus on the redirect binding by way of the SAMLRedirectBindingUtil can be interesting, amid what is really some pretty dry stuff in these four chapters. 7

8 Revision History Version 3.2 updates the course for Spring Security 3.2, and expands coverage to include SAML SSO and OAuth. Major changes include: Removal of what was Chapter 0 on the Spring framework, and now simply list Spring experience as a prerequisite for the course. A new section near the end of Chapter 2 that delves into best practices with password hashing, and a new lab specifically on customizing PasswordEncoder and SaltSource. A new section in Chapter 6 annotations and the use of Spring EL for dynamic authorization. A new Chapter 7 on the Spring Security SAML Extension. A new Chapter 8 on OAuth for Spring Security. New Module 2 with four chapters giving some background on SAML. Version 2.0 is the initial release of the course. 8

9 Troubleshooting If you run into any trouble with code exercises, the first and best thing to do is to doublecheck that the classroom machines have been set up precisely according to the course setup guide. Especially, the wrong version of a tool can cause significant problems; don t wander off-book in this way unless absolutely sure you can support the software that you prefer and that we haven t tested. Check environment variable settings carefully, too; these are the cause of a great many classroom glitches. Below are some specific pitfalls that have come up in previous offerings of the course: Remember that the default constraint under <http> is no constraint at all! So a URL pattern that is too narrow or just misses because of a mistype will result in a wave- em-on-in: no authentication required. Most other typos and low-level errors in the configuration will be caught and announced in the server console, either by the Spring container (referring to a nonexistent data-source bean, e.g.) or by Spring Security (not specifying a user details service, using a config attribute without providing a voter that understands it). It s a good idea to keep the server console, or at least the tail of it, visible while building and deploying, so that these sorts of errors will draw your eye easily when they occur. 9

10 Errata The following issues have arisen in the classroom since the latest release, and will be fixed on our next release: No known issues at this time. Feedback We very much appreciate whatever feedback we can get on our courseware especially from the instructor s perspective. Naturally, the more specific, the better, and we strongly encourage you to make notes on issues you may encounter in the classroom, whether they re typos, missing files, or suggestions for clearer language to explain a concept. We can t guarantee that we ll act on every suggestion, but we re aggressive about stamping out problems and try to be highly responsive. Hopefully this means that when you give us good feedback, you get a better course the next time you need to teach it. Please direct all courseware feedback to Will Provost Capstone Courseware mailto:provost@capcourse.com For anyone who s interested, we have a very informal defect-tracking system, based in Excel spreadsheets with columns to capture defect location, nature, status, and author feedback. Ultimately, feedback goes into these sheets, so if you want a template, we ll be happy to provide one, to facilitate the reporting process. 10