Apache Shiro Architecture

Apache Shiro's design goals are to simplify application security by being intuitive and easy to use. Shiro's core design models how most people think about application security - in the context of someone (or something) interacting with an application.

Software applications are usually designed based on user stories. That is, you'll often design user interfaces or service APIs based on how a user would (or should) interact with the software. For example, you might say, "If the user interacting with my application is logged in, I will show them a button they can click to view their account information. If they are not logged in, I will show a sign-up button."

This example statement indicates that applications are largely written to satisfy user requirements and needs. Even if the 'user' is another software system and not a human being, you still write code to reflect behavior based on who (or what) is currently interacting with your software.

Shiro reflects these concepts in its own design. By matching what is already intuitive for software developers, Apache Shiro remains intuitive and easy to use in practically any application.

High-Level Overview

At the highest conceptual level, Shiro's architecture has 3 primary concepts: the Subject, SecurityManager and Realms. The following diagram is a high-level overview of how these components interact, and we'll cover each concept below:





Detailed Architecture

The following diagram shows Shiro's core architectural concepts followed by short summaries of each:

The SecurityManager

Because Shiro's API encourages a Subject-centric programming approach, most application developers will rarely, if ever, interact with the SecurityManager directly (framework developers however might sometimes find it useful). Even so, it is still important to know how the SecurityManager functions, especially when configuring one for an application.

Design

As stated previously, the application's SecurityManager performs security operations and manages state for all application users. In Shiro's default SecurityManager implementations, this includes:

But this is a lot of functionality to try to manage in a single component. And, making these things flexible and customizable would be very difficult if everything were lumped into a single implementation class.

To simplify configuration and enable flexible configuration/pluggability, Shiro's implementations are all highly modular in design - so modular in fact, that the SecurityManager implementation (and its class-hierarchy) does not do much at all. Instead, the SecurityManager implementations mostly act as a lightweight 'container' component, delegating almost all behavior to nested/wrapped components. This 'wrapper' design is reflected in the detailed architecture diagram above.

While the components actually execute the logic, the SecurityManager implementation knows how and when to coordinate the components for the correct behavior.

The SecurityManager implementations and are also JavaBeans compatible, which allows you (or a configuration mechanism) to easily customize the pluggable components via standard JavaBeans accessor/mutator methods (get*/set*). This means the Shiro's architectural modularity can translate into very easy configuration for custom behavior.

Easy Configuration
Because of JavaBeans compatibility, it is very easy to configure the SecurityManager with custom components via any mechanism that supports JavaBeans-style configuration, such as Spring, Guice, JBoss, etc.

We will cover Configuration next.

Lend a hand with documentation

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.

The easiest way to contribute your documentation is to send it to the User Forum or the User Mailing List.