diff --git a/src/docbkx/technical-overview.xml b/src/docbkx/technical-overview.xml index c872a7de80..fdcd57ead4 100644 --- a/src/docbkx/technical-overview.xml +++ b/src/docbkx/technical-overview.xml @@ -1,8 +1,12 @@ - Technical Overview + + Technical Overview +
- Runtime Environment + + Runtime Environment + Spring Security is written to execute within a standard Java 1.4 Runtime Environment. It also supports Java 5.0, although the Java @@ -18,13 +22,15 @@ Container there is no need to put any special configuration files anywhere, nor include Spring Security in a server classloader. - This above design offers maximum deployment time flexibility, as + This design offers maximum deployment time flexibility, as you can simply copy your target artifact (be it a JAR, WAR or EAR) from one system to another and it will immediately work.
- Shared Components + + Shared Components + Let's explore some of the most important shared components in Spring Security. Components are considered "shared" if they are @@ -35,7 +41,9 @@
- SecurityContextHolder, SecurityContext and Authentication Objects + + SecurityContextHolder, SecurityContext and Authentication Objects + The most fundamental object is SecurityContextHolder. This is where we store details of the present security context of the application, which @@ -74,7 +82,7 @@ an Authentication object yourself, it is fairly common for users to query the Authentication object. You can use the following code block - from anywhere in your - application - to do this: + application - to obtain the name of the authenticated user, for example: Object obj = SecurityContextHolder.getContext().getAuthentication().getPrincipal(); @@ -360,7 +368,8 @@ if (obj instanceof UserDetails) { AuthenticationProvider.
-
AuthenticationProvider +
+ AuthenticationProvider The last player in the Spring Security authentication process is an AuthenticationProvider. Quite simply, it is responsible for taking an Authentication request @@ -422,15 +431,21 @@ if (obj instanceof UserDetails) {
Secure Objects + Spring Security uses the term "secure object" to refer to any + object that can have security (such as an authorization decision) applied to it. + The most common examples are method invocations and web requests. + +
+ Security and AOP Advice If you're familiar with AOP, you'd be aware there are different types of advice available: before, after, throws and around. An around advice is very useful, because an advisor can elect whether or not to proceed with a method invocation, whether or not to modify the response, and whether or not to throw an exception. Spring Security provides an around advice for method invocations as well as web - requests. We achieve an around advice for method invocations using AOP - Alliance, and we achieve an around advice for web requests using a + requests. We achieve an around advice for method invocations using Spring's + standard AOP support and we achieve an around advice for web requests using a standard Filter. For those not familiar with AOP, the key point to understand is @@ -441,43 +456,62 @@ if (obj instanceof UserDetails) { applications (for clarification, the author disapproves of this design and instead advocates properly encapsulated domain objects together with the DTO, assembly, facade and transparent persistence patterns, - but as anemic domain objects is the present mainstream approach, we'll + but as use of anemic domain objects is the present mainstream approach, we'll talk about it here). If you just need to secure method invocations to - the services layer, using the Spring's standard AOP platform - (otherwise known as AOP Alliance) will be adequate. If you need to - secure domain objects directly, you will likely find that AspectJ is - worth considering. + the services layer, Spring's standard AOP (otherwise known as AOP Alliance) + will be adequate. If you need to secure domain objects directly, you + will likely find that AspectJ is worth considering. You can elect to perform method authorization using AspectJ or - AOP Alliance, or you can elect to perform web request authorization + Spring AOP, or you can elect to perform web request authorization using filters. You can use zero, one, two or three of these approaches together. The mainstream usage is to perform some web request - authorization, coupled with some AOP Alliance method invocation + authorization, coupled with some Spring AOP method invocation authorization on the services layer. +
- Spring Security uses the term "secure object" to refer to any - object that can have security applied to it. Each secure object - supported by Spring Security has its own class, which is a subclass of - AbstractSecurityInterceptor. Importantly, by the - time the AbstractSecurityInterceptor is run, the +
+ AbstractSecurityInterceptor + + Each secure object type supported by Spring Security has its own class, + which is a subclass of AbstractSecurityInterceptor. + Importantly, by the time the AbstractSecurityInterceptor is called, the SecurityContextHolder will contain a valid Authentication if the principal has been authenticated. - The AbstractSecurityInterceptor provides a - consistent workflow for handling secure object requests. This workflow - includes looking up the "configuration attributes" associated with the - present request. A "configuration attribute" can be thought of as a - String that has special meaning to the classes used by - AbstractSecurityInterceptor. They're normally - configured against your AbstractSecurityInterceptor - using XML. Anyway, the AbstractSecurityInterceptor - will ask an AccessDecisionManager "here's the - configuration attributes, here's the current - Authentication object, and here's details of the - current request - is this particular principal allowed to perform this - particular operation?". - + AbstractSecurityInterceptor provides a + consistent workflow for handling secure object requests, typically: + + + Look up the "configuration attributes" associated with the + present request + Submitting the secure object, current Authentication + and configuration attributes to the AccessDecisionManager for + an authorization decision + Optionally change the Authentication under which the invocation + takes place + Allow the secure object to proceed (assuming access was granted) + Call the AfterInvocationManager if configured, once the invocation + has returned. + + + +
+ What are Configuration Attributes? + + A "configuration attribute" can be thought of as a String that has special meaning to the classes used by + AbstractSecurityInterceptor. They may be simple role names or have more complex meaning, depending on the + how sophisticated the AccessDecisionManager implementation is. + The AbstractSecurityInterceptor is configured with an ObjectDefinitionSource which + it uses to look up the attributes for a secure object. Usually this configuration will be hidden from the user. Configuration + attributes will be entered as annotations on secured methods, or as access attributes on secured URLs (using the + namespace <intercept-url> syntax). + +
+ +
+ RunAsManager Assuming AccessDecisionManager decides to allow the request, the AbstractSecurityInterceptor will normally just proceed with the request. Having said that, on rare @@ -492,7 +526,10 @@ if (obj instanceof UserDetails) { Security automatically propagates security identity from one server to another (assuming you're using a properly-configured RMI or HttpInvoker remoting protocol client), this may be useful. +
+
+ AfterInvocationManager Following the secure object proceeding and then returning - which may mean a method invocation completing or a filter chain proceeding - the AbstractSecurityInterceptor gets @@ -503,14 +540,13 @@ if (obj instanceof UserDetails) { a secure object invocation. Being highly pluggable, AbstractSecurityInterceptor will pass control to an AfterInvocationManager to actually modify the - object if needed. This class even can entirely replace the object, or + object if needed. This class can even entirely replace the object, or throw an exception, or not change it in any way. - Because AbstractSecurityInterceptor is the - central template class, it seems fitting that the first figure should - be devoted to it. + AbstractSecurityInterceptor and its related objects + are shown in . -
+
The key "secure object" model @@ -522,7 +558,10 @@ if (obj instanceof UserDetails) {
+
+
+ Extending the Secure Object Model Only developers contemplating an entirely new way of intercepting and authorizing requests would need to use secure objects directly. For example, it would be possible to build a new secure @@ -533,18 +572,9 @@ if (obj instanceof UserDetails) { three currently supported secure object types (AOP Alliance MethodInvocation, AspectJ JoinPoint and web request - FilterInterceptor) with complete + FilterInvocation) with complete transparency. +
- -
- Conclusion - - Congratulations! You have enough of a high-level picture of - Spring Security to embark on your project. We've explored the shared - components, how authentication works, and reviewed the common - authorization concept of a "secure object". Everything that follows in - this reference guide may or may not apply to your particular needs, - and can be read in any order.
\ No newline at end of file