Okay, I’ve been talking about upgrades lately. I have a customer who has fallen behind on their upgrades and I’m getting them caught up by folding in various upgrades into their release schedule. This particular customer is extremely agile when it comes to releases, so this has given me the chance to upgrade them in a piecemeal fashion on a fairly rapid (twice per month) schedule.
And now it’s time to upgrade them to Spring security, which isn’t a big deal because they’re using Acegi 1.0.6 at the moment. So who cares? Like, why am I writing about this, basically noop upgrade? Well, as you system architects out there know, whenever you do an upgrade, you have to really dig into the library(ies) you’re upgrading. So I’m really digging into Acegi to see how the existing code might break when I upgrade them to Spring Security 3.0.3. In doing so, I have been very impressed by the overall design of Acegi. The security in place for my customer is front-ended by a Servlet filter provided by Acegi, which delegates to a set of three components:
– A ProcessingFilter – another Spring Bean which serves as the entry point (from a servlet filter standpoint) and delegates to the:
– Authentication Manager – a Spring Bean for which is configured an AuthenticationProvider, which delegates to the:
– A UserDetailsService, a Spring Bean that provides information about users (like their userid, password, email address, etc).
Through this symphony of components (and it’s configurable, so it doesn’t have to look exactly like I show it above), different concerns are separated. Such as how the user provides their credentials, what component(s) checks them, and how the Acegi Authentication object is returned to the infrastructure. I’m impressed.
So what do you think? What security do you use? I’d love to hear from you.
–jsp
j steven perry, The Blog 