Interface SecurityManager

All Superinterfaces:
Authenticator, Authorizer, SessionManager
All Known Implementing Classes:
AuthenticatingSecurityManager, AuthorizingSecurityManager, CachingSecurityManager, DefaultSecurityManager, RealmSecurityManager, SessionsSecurityManager
public interface SecurityManager extends Authenticator, Authorizer, SessionManager
A SecurityManager executes all security operations for all Subjects (aka users) across a single application.

The interface itself primarily exists as a convenience - it extends the Authenticator, Authorizer, and SessionManager interfaces, thereby consolidating these behaviors into a single point of reference. For most Shiro usages, this simplifies configuration and tends to be a more convenient approach than referencing Authenticator, Authorizer, and SessionManager instances separately; instead one only needs to interact with a single SecurityManager instance.

In addition to the above three interfaces, this interface provides a number of methods supporting Subject behavior. A Subject executes authentication, authorization, and session operations for a single user, and as such can only be managed by A SecurityManager which is aware of all three functions. The three parent interfaces on the other hand do not 'know' about Subjects 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 SecurityUtils.getSubject().

Framework developers on the other hand might find working with an actual SecurityManager useful.

Since:
0.2
See Also:

  • Method Details

    • login

      Subject login(Subject subject, AuthenticationToken authenticationToken) throws AuthenticationException
      Logs in the specified Subject using the given authenticationToken, returning an updated Subject instance reflecting the authenticated state if successful or throwing AuthenticationException if it is not.

      Note that most application developers should probably not call this method directly unless they have a good reason for doing so. The preferred way to log in a Subject is to call subject.login(authenticationToken) (usually after acquiring the Subject by calling SecurityUtils.getSubject()).

      Framework developers on the other hand might find calling this method directly useful in certain cases.

      Parameters:
      subject - the subject against which the authentication attempt will occur
      authenticationToken - the token representing the Subject's principal(s) and credential(s)
      Returns:
      the subject instance reflecting the authenticated state after a successful attempt
      Throws:
      AuthenticationException - if the login attempt failed.
      Since:
      1.0

    • logout

      void logout(Subject subject)
      Logs out the specified Subject from the system.

      Note that most application developers should not call this method unless they have a good reason for doing so. The preferred way to logout a Subject is to call Subject.logout(), not the SecurityManager directly.

      Framework developers on the other hand might find calling this method directly useful in certain cases.

      Parameters:
      subject - the subject to log out.
      Since:
      1.0

    • createSubject

      Subject createSubject(SubjectContext context)
      Creates a Subject instance reflecting the specified contextual data.

      The context can be anything needed by this SecurityManager to construct a Subject instance. Most Shiro end-users will never call this method - it exists primarily for framework development and to support any underlying custom SubjectFactory implementations that may be used by the SecurityManager.

      Usage

      After calling this method, the returned instance is not bound to the application for further use. Callers are expected to know that Subject instances have local scope only and any other further use beyond the calling method must be managed explicitly.
      Parameters:
      context - any data needed to direct how the Subject should be constructed.
      Returns:
      the Subject instance reflecting the specified initialization data.
      Since:
      1.0
      See Also: