Default {@code SubjectDAO} implementation that stores Subject state in the Subject's Session by default (but this can be disabled - see below). The Subject instance can be re-created at a later time by first acquiring the associated Session (typically from a {@link hunt.shiro.session.mgt.SessionManager SessionManager}) via a session ID or session key and then building a {@code Subject} instance from {@code Session} attributes. <h2>Controlling how Sessions are used</h2> Whether or not a {@code Subject}'s {@code Session} is used or not to persist its own state is controlled on a <em>per-Subject</em> basis as determined by the configured {@link #setSessionStorageEvaluator(SessionStorageEvaluator) sessionStorageEvaluator}. The default {@code Evaluator} is a {@link DefaultSessionStorageEvaluator}, which supports enabling or disabling session usage for Subject persistence at a global level for all subjects (and defaults to allowing sessions to be used). <h3>Disabling Session Persistence Entirely</h3> Because the default {@code SessionStorageEvaluator} instance is a {@link DefaultSessionStorageEvaluator}, you can disable Session usage for Subject state entirely by configuring that instance directly, e.g.: <pre> ((DefaultSessionStorageEvaluator)sessionDAO.getSessionStorageEvaluator()).setSessionStorageEnabled(false); </pre> or, for example, in {@code shiro.ini}: <pre> securityManager.subjectDAO.sessionStorageEvaluator.sessionStorageEnabled = false </pre> but <b>note:</b> ONLY do this your application is 100% stateless and you <em>DO NOT</em> need subjects to be remembered across remote invocations, or in a web environment across HTTP requests. <h3>Supporting Both Stateful and Stateless Subject paradigms</h3> Perhaps your application needs to support a hybrid approach of both stateful and stateless Subjects: <ul> <li>Stateful: Stateful subjects might represent web end-users that need their identity and authentication state to be remembered from page to page.</li> <li>Stateless: Stateless subjects might represent API clients (e.g. REST clients) that authenticate on every request, and therefore don't need authentication state to be stored across requests in a session.</li> </ul> To support the hybrid <em>per-Subject</em> approach, you will need to create your own implementation of the {@link SessionStorageEvaluator} interface and configure it via the {@link #setSessionStorageEvaluator(SessionStorageEvaluator)} method, or, with {@code shiro.ini}: <pre> myEvaluator = com.my.CustomSessionStorageEvaluator securityManager.subjectDAO.sessionStorageEvaluator = $myEvaluator </pre> <p/> Unless overridden, the default evaluator is a {@link DefaultSessionStorageEvaluator}, which enables session usage for Subject state by default.