A {@code SecurityManager} executes all security operations for
all Subjects (aka users) across asingle application.
The interface itself primarily exists as a convenience - it extends the {@link org.apache.shiro.authc.Authenticator}, {@link Authorizer}, and {@link SessionManager} interfaces, thereby consolidatingthese behaviors into a single point of reference. For most Shiro usages, this simplifies configuration and tends to be a more convenient approach than referencing {@code Authenticator}, {@code Authorizer}, and {@code SessionManager} instances separately; instead one only needs to interact with a single{@code SecurityManager} instance.
In addition to the above three interfaces, this interface provides a number of methods supporting {@link Subject} behavior. A {@link org.apache.shiro.subject.Subject Subject} executesauthentication, authorization, and session operations for a
single user, and as such can only be managed by {@code A SecurityManager} which is aware of all three functions. The three parent interfaces on theother hand do not 'know' about {@code Subject}s to ensure a clean separation of concerns.
Usage Note: In actuality the large majority of application programmers won't interact with a SecurityManager very often, if at all.
Most application programmers only care about security operations for the currently executing user, usually attained by calling {@link org.apache.shiro.SecurityUtils#getSubject() SecurityUtils.getSubject()}.
Framework developers on the other hand might find working with an actual SecurityManager useful.
@author Les Hazlewood
@see org.apache.shiro.mgt.DefaultSecurityManager
@since 0.2