This page covers the ways to integrate Shiro into Spring-based applications.
Shiro's JavaBeans compatibility makes it perfectly suited to be configured via Spring XML or other Spring-based configuration mechanisms. Shiro applications need an application singleton SecurityManager instance. Note that this does not have to be a static singleton, but there should only be a single instance used by the application, whether its a static singleton or not.
Here is the simplest way to enable an application singleton SecurityManager in Spring applications:
Shiro has first-rate support for Spring web applications. In a web application, all Shiro-accessible web requests must go through a master Shiro Filter. This filter itself is extremely powerful, allowing for
ad-hoc custom filter chains to be executed based on any URL path expression.
Prior to Shiro 1.0, you had to use a hybrid approach in Spring web applications, defining the Shiro filter and
all of its configuration properties in web.xml but define the SecurityManager in Spring XML. This was a little frustrating since you couldn't 1) consolidate your configuration in one place and 2) leverage the configuration power of the more advanced Spring features, like the PropertyPlaceholderConfigurer or abstract beans to consolidate common configuration.
Now in Shiro 1.0 and later, all Shiro configuration is done in Spring XML providing access to the more robust Spring configuration mechanisms.
Here is how to configure Shiro in a Spring-based web application:
In addition to your other Spring web.xml elements (ContextLoaderListener, Log4jConfigListener, etc), define the following filter and filter mapping:
In your applicationContext.xml file, define the web-enabled SecurityManager and the 'shiroFilter' bean that will be referenced from web.xml.
In both standalone and web applications, you might want to use Shiro's Annotations for security checks (for example, @RequiresRoles, @RequiresPermissions, etc. This requires Shiro's Spring AOP integration to scan for the appropriate annotated classes and perform security logic as necessary.
Here is how to enable these annotations. Just add these two bean definitions to applicationContext.xml:
There are two parts to Shiro's Spring remoting support: Configuration for the client making the remoting call and configuration for the server receiving and processing the remoting call.
When a remote method invocation comes in to a Shiro-enabled server, the Subject associated with that RPC call must be bound to the receiving thread for access during the thread's execution. This is done by defining Shiro's SecureRemoteInvocationExecutor bean in applicationContext.xml:
Once you have defined this bean, you must plug it in to whatever remoting Exporter you are using to export/expose your services. Exporter implementations are defined according to the remoting mechanism/protocol in use. See Spring's Remoting chapter on defining Exporter beans.
For example, if using HTTP-based remoting (notice the property reference to the secureRemoteInvocationExecutor bean):
When a remote call is being executed, the Subject identifying information must be attached to the remoting payload to let the server know who is making the call. If the client is a Spring-based client, that association is done via Shiro's SecureRemoteInvocationFactory:
Then after you've defined this bean, you need to plug it in to the protocol-specific Spring remoting ProxyFactoryBean you're using.
For example, if you were using HTTP-based remoting (notice the property reference to the secureRemoteInvocationFactory bean defined above):
While we hope this documentation helps you with the work you're doing with Apache Shiro, the community is improving and expanding the documentation all the time. If you'd like to help the Shiro project, please consider corrected, expanding, or adding documentation where you see a need. Every little bit of help you provide expands the community and in turn improves Shiro.