With the rise of the web over the last ten years, many companies have adopted e-commerce solutions to support their business models. Retail, sales, banking, financial, and other industries have adopted the web as a key means to generate revenue. This has triggered a security crisis, since early web applications had little to no security, and the ways to exploit systems were vast. This doesn't involve a small corner of the market, but potentially compromises a huge segment of the market. It is no wonder that companies hire security consultants to come up with the means to protect their already built e-commerce sites.
Software development teams are starting to realize that security needs to be coded into their applications sooner rather than later. However, competitive deadlines and getting products to market sooner rather than later can cause security requirements to get pushed to the back of the line. Many web applications that hit the market have security implemented as more of an after thought. Part of this is due to the fact that coding effective security protocols is hard. Acegi Security, a Java framework based on the Spring Framework, was initially released in 2003. Its pluggable architecture and non-intrusive nature took the Java world by storm. By providing support for many security protocols including database, LDAP, OpenID, X.509, Central Authentication Service (CAS), Kerberos, Java Authentication and Authorization Service (JAAS), along with many others, it has become widely used in many industries, and in both the private and public sector.
Spring Python's pythonic implementation of this powerful architecture provides the same mechanisms to secure applications of all types simply and effectively to the Python community. Spring Python Security currently supports web application security. There are future plans to support method-level security just like Spring Security.
In this chapter, we will learn:
- The security problems software developers have to deal with and the challenge faced in effectively coding security
- The requirements for an effective security solution, and the ability of Spring Python Security to meet them
- Wrapping an unsecured web application with a simple solution that cleanly protects by delegating to a security handler
- The concept of authenticating who the user is, and determining what they are authorized to do
- Testing the security of our application
- Configuring a SQL-based security system, including adapting to a custom user/role schema
- Configuring an LDAP-based security system
- Making your application support multiple user communities or migrating from one security system to another with no downtime
- Coding our own security extension for systems not yet supported out-of-the-box by Spring Python Security
Securing an application is hard. When coded by hand using simple tactics, security becomes very invasive. For applications to have true access to security settings, the following must be available:
- Securing URLs based on primitive rules is a start, but is rarely adequate as business rules and requirements are revised and updated over time.
- Relying on container security tends to be inflexible and prone to lock-in. For example, using Apache web server
.htaccessfiles may work for simple situations. But complex rules are hard to get right, difficult to test automatically, and also discourage relocating to another type of container. Making security a part of the application, and not dependent on another container frees the application from container lock-in. - To support specialized situations, any method in the code must be able to lookup who the current user is, and what permissions he or she has. Usually this is only needed in a few places, but altering all the necessary APIs to get this information passed from the logon screen to the code logic can have too wide an impact over such an isolated need.
- Security code has a repeating pattern. Developers sometimes abstract this behavior into a base class, with subclasses handling business logic. This may appear to support the DRY (Don't Repeat Yourself) principle, but it violates the"is-a" concept of OOP. It is important to realize that security is a crosscutting behavior that is independent of and orthogonal to the business logic, and must be solved using aspect-oriented concepts.
- When coded by hand, the solution is often hard-wired into the application. Upgrading from a simple username/password management system to something more sophisticated like OpenID, LDAP, or two-factor authentication systems can become impossible due to the ripple effect of changes. This type of switch is often needed when moving users from one security solution to another, or when supporting multiple user communities. Most production systems would prefer to stay where they are rather than spend the money to re-write the security layer of their application.
These issues shine a light on what it takes to implement a reliable security solution:
- The security solution must be orthogonal to the class hierarchy.
- Credential data and other security APIs must be available non-intrusively, to avoid requiring applications to re-write existing APIs.
- Usage of security by the application must be decoupled from the actual securing resource. For example, if the system uses LDAP to store username and password information, the application shouldn't have to make LDAP calls.
- Multiple security providers must be allowed, in order to support users from different communities as well as the ability to transition from one system to another while new credentials are issued to the user community.
- Security policies must be flexible and easy to fine tune, in order to support up-and-coming business requirements.
- Even though there are many standard conventions, users must be able to quickly write custom security extensions to support legacy security solutions.
The Spring Python Security module meets all these requirements. Throughout this chapter, as we develop our example web application and then secure it, we will point out how these requirements are being met.