<para>Let's assume you're developing an enterprise application based on Spring. There are four security concerns you typically need to address: authentication, web request security, service layer security (i.e. your methods that implement business logic), and domain object instance security (i.e. different domain objects have different permissions). With these typical requirements in mind: <orderedlist>
<listitem>
<para><emphasis>Authentication</emphasis>: The servlet specification provides an approach to authentication. However, you will need to configure the container to perform authentication which typically requires editing of container-specific "realm" settings. This makes a non-portable configuration, and if you need to write an actual Java class to implement the container's authentication interface, it becomes even more non-portable. With Spring Security you achieve complete portability - right down to the WAR level. Also, Spring Security offers a choice of production-proven authentication providers and mechanisms, meaning you can switch your authentication approaches at deployment time. This is particularly valuable for software vendors writing products that need to work in an unknown target environment.</para>
</listitem>
<listitem>
<para><emphasis>Web request security:</emphasis> The servlet specification provides an approach to secure your request URIs. However, these URIs can only be expressed in the servlet specification's own limited URI path format. Spring Security provides a far more comprehensive approach. For instance, you
can use Ant paths or regular expressions, you can consider parts
of the URI other than simply the requested page (eg you can
consider HTTP GET parameters), and you can implement your own
runtime source of configuration data. This means your web
request security can be dynamically changed during the actual
execution of your webapp.</para>
</listitem>
<listitem>
<para><emphasis>Service layer and domain object security:</emphasis>
The absence of support in the servlet specification for services
layer security or domain object instance security represent
serious limitations for multi-tiered applications. Typically
developers either ignore these requirements, or implement
security logic within their MVC controller code (or even worse,
inside the views). There are serious disadvantages with this
approach: <orderedlist>
<listitem>
<para><emphasis>Separation of concerns:</emphasis>
Authorization is a crosscutting concern and should
be implemented as such. MVC controllers or views
implementing authorization code makes it more
difficult to test both the controller and
authorization logic, more difficult to debug, and
will often lead to code duplication.</para>
</listitem>
<listitem>
<para><emphasis>Support for rich clients and web
services:</emphasis> If an additional client type
must ultimately be supported, any authorization code
embedded within the web layer is non-reusable. It
should be considered that Spring remoting exporters
only export service layer beans (not MVC
controllers). As such authorization logic needs to
be located in the services layer to support a
multitude of client types.</para>
</listitem>
<listitem>
<para><emphasis>Layering issues:</emphasis> An MVC
controller or view is simply the incorrect
architectural layer to implement authorization
decisions concerning services layer methods or
domain object instances. Whilst the Principal may be
passed to the services layer to enable it to make
the authorization decision, doing so would introduce
It is often said of web frameworks that they "make
it easier to do the right things, and harder to do
the wrong things". Security frameworks are the same,
because they are designed in an abstract manner for
a wide range of purposes. Writing your own
authorization code from scratch does not provide the
"design check" a framework would offer, and in-house
authorization code will typically lack the
improvements that emerge from widespread deployment,
peer review and new versions. </para>
</listitem>
</orderedlist></para>
</listitem>
</orderedlist></para>
<listitem>
<para><emphasis>Authentication</emphasis>: The servlet specification provides an approach to authentication. However, you will need to configure the container to perform authentication which typically requires editing of container-specific "realm" settings. This makes a non-portable configuration, and if you need to write an actual Java class to implement the container's authentication interface, it becomes even more non-portable. With Spring Security you achieve complete portability - right down to the WAR level. Also, Spring Security offers a choice of production-proven authentication providers and mechanisms, meaning you can switch your authentication approaches at deployment time. This is particularly valuable for software vendors writing products that need to work in an unknown target environment.</para>
</listitem>
<listitem>
<para><emphasis>Web request security:</emphasis> The servlet specification provides an approach to secure your request URIs. However, these URIs can only be expressed in the servlet specification's own limited URI path format. Spring Security provides a far more comprehensive approach. For instance, you
can use Ant paths or regular expressions, you can consider parts
of the URI other than simply the requested page (e.g. you can
consider HTTP GET parameters) and you can implement your own
runtime source of configuration data. This means your web
request security can be dynamically changed during the actual
execution of your webapp.</para>
</listitem>
<listitem>
<para><emphasis>Service layer and domain object security:</emphasis>
The absence of support in the servlet specification for services
layer security or domain object instance security represent
serious limitations for multi-tiered applications. Typically
developers either ignore these requirements, or implement
security logic within their MVC controller code (or even worse,
inside the views). There are serious disadvantages with this
approach:
<orderedlist>
<listitem>
<para><emphasis>Separation of concerns:</emphasis>
Authorization is a crosscutting concern and should
be implemented as such. MVC controllers or views
implementing authorization code makes it more
difficult to test both the controller and
authorization logic, more difficult to debug, and
will often lead to code duplication.</para>
</listitem>
<listitem>
<para><emphasis>Support for rich clients and web
services:</emphasis> If an additional client type
must ultimately be supported, any authorization code
embedded within the web layer is non-reusable. It
should be considered that Spring remoting exporters
only export service layer beans (not MVC
controllers). As such authorization logic needs to
be located in the services layer to support a
multitude of client types.</para>
</listitem>
<listitem>
<para><emphasis>Layering issues:</emphasis> An MVC
controller or view is simply the incorrect
architectural layer to implement authorization
decisions concerning services layer methods or
domain object instances. Whilst the Principal may be
passed to the services layer to enable it to make
the authorization decision, doing so would introduce
Luke Taylor
17 years ago