We have doubtlessly learned that new requirements are always coming, and we have to be ready to implement them quickly. We started our application by implementing the core functionality. Now we need to support multiple users and need to control who edits what pages.
The first step towards securing an application is authenticating the user. This identifies who the user is, and is usually accomplished by the user providing a username and a password. The following diagram shows an update to our application's design. It includes a new component not found in the previous diagram: a Spring Python Security agent that polices every web request combined with a 3rd party security resource. Before allowing the user to actually touch our wiki application or the database, our security agent checks if the user has been authenticated. If not, Spring Python redirects the user to a login page. In the diagram, we pick up at the point where the user submits new wiki text.
The security agent meets one of our earlier requirements: application of security must be decoupled from the application. The agent is a separate piece of code charged with the responsibility of managing security between the user and our application. Its configuration its not part of our wiki application, but instead configured using the IoC container. We will see how to configure this agent shortly.
The following diagram shows the user submitting credentials. The security agent checks the credentials against the 3rd party security resource to confirm the user's identity. The most common implementation is a simple database table containing user data.
It is important to point out that our security agent is not done. After confirming the user's identity, Spring Python next looks up what authorities the user is granted. One user may have the authority to read articles, while another has the authority to read articles and also edit them. The last few steps of the previous diagram shows this as authorities are looked up and stored in Spring Python Security's context holder.
The standard convention is to allow a user to have zero or more roles. Having collected this information, our security agent stores the user's identity, granted authorities, and authenticated status in a globally accessible SecurityContextHolder. This is important, because it provides a way for our application to look up information about the user's security status without modifying the application's APIs. This meets another one of our requirements: credential data must be available non-intrusively. After securing our application, we will see how this is available.
After authenticating and authorizing the user, the web request is allowed through to the web application. The following diagram shows what happens when we again submit our new wiki text, assuming we are authenticated and authorized to do so.
It is important to point out that this requires no changes in either SpringWiki or SpringWikiController. We will quickly demonstrate that applying these changes involves only some configuration changes.