登入操作一般都是我們觸發的：

Subject subject = SecurityUtils.getSubject();
AuthenticationToken authenticationToken = new ...
subject.login(authenticationToken);

Subject的登入將委託給SecurityManager，SecurityManager的login方法實際上是產生了一個新的Subject，然後將相關屬性賦予當前呼叫者Subject:

public void login(AuthenticationToken token) throws
 
 AuthenticationException {
    clearRunAsIdentitiesInternal();
    Subject subject = securityManager.login(this, token);

    PrincipalCollection principals;

    String host = null;

    if (subject instanceof DelegatingSubject) {
        DelegatingSubject delegating = (DelegatingSubject) subject;
        //we have to do this in case there are assumed identities - we don't want to lose the 'real' principals:
 

        principals = delegating.principals;
        host = delegating.host;
    } else {
        principals = subject.getPrincipals();
    }

    if (principals == null || principals.isEmpty()) {
        String msg = "Principals returned from securityManager.login( token ) returned a null or " +
                "empty value.  This value must be non null and populated with one or more elements."
 
;
        throw new IllegalStateException(msg);
    }
    this.principals = principals;
    this.authenticated = true;
    if (token instanceof HostAuthenticationToken) {
        host = ((HostAuthenticationToken) token).getHost();
    }
    if (host != null) {
        this.host = host;
    }
    Session session = subject.getSession(false);
    if (session != null) {
        this.session = decorate(session);
    } else {
        this.session = null;
    }
}

DefaultSecurityManager實現了login方法：

public Subject login(Subject subject, AuthenticationToken token) throws AuthenticationException {
    AuthenticationInfo info;
    try {
        info = authenticate(token);
    } catch (AuthenticationException ae) {
        try {
            onFailedLogin(token, ae, subject);
        } catch (Exception e) {
            if (log.isInfoEnabled()) {
                log.info("onFailedLogin method threw an " +
                        "exception.  Logging and propagating original AuthenticationException.", e);
            }
        }
        throw ae; //propagate
    }

    Subject loggedIn = createSubject(token, info, subject);

    onSuccessfulLogin(token, info, loggedIn);

    return loggedIn;
}

父類AuthenticatingSecurityManager實現authenticate方法：

public abstract class AuthenticatingSecurityManager extends RealmSecurityManager {

    private Authenticator authenticator;

    public AuthenticatingSecurityManager() {
        super();
        this.authenticator = new ModularRealmAuthenticator();
    }

    public AuthenticationInfo authenticate(AuthenticationToken token) throws AuthenticationException {
        return this.authenticator.authenticate(token);
    }

    //......
}

利用一個ModularRealmAuthenticator型別的authenticator來實現：

protected AuthenticationInfo doAuthenticate(AuthenticationToken authenticationToken) throws AuthenticationException {
    assertRealmsConfigured();
    Collection<Realm> realms = getRealms();
    if (realms.size() == 1) {
        return doSingleRealmAuthentication(realms.iterator().next(), authenticationToken);
    } else {
        return doMultiRealmAuthentication(realms, authenticationToken);
    }
}

然後根據realms集合是單個還是多個分別處理，最終無非是這樣：

AuthenticationInfo info = realm.getAuthenticationInfo(token);

父類AuthenticatingRealm的getAuthenticationInfo方法實現了info的獲取和身份的校驗，僅僅呼叫自己實現的realm的doGetAuthenticationInfo方法，初步驗證後構造一個SimpleAuthenticationInfo：

SimplePrincipalCollection principalCollection = new SimplePrincipalCollection(principals, this.getName());
return new SimpleAuthenticationInfo(principalCollection, authenticationInfo.getCredentials());

AuthenticatingRealm的getAuthenticationInfo方法邏輯如下：

首先去快取找info:

AuthenticationInfo info = getCachedAuthenticationInfo(token);

快取沒有則呼叫子類實現的方法：

info = doGetAuthenticationInfo(token);

info不為null的時候就要驗證了（這裡還可以加密驗證）：

assertCredentialsMatch(token, info);

兩次建立Subject

進入AbstractShiroFilter的時候，會預設建立一個Subject，這個是在Subject介面中的內部類實現的，但是同樣也是呼叫了DefaultSecurityManager中的createSubject方法：

public Subject createSubject(SubjectContext subjectContext) {
    //create a copy so we don't modify the argument's backing map:
    SubjectContext context = copy(subjectContext);

    //ensure that the context has a SecurityManager instance, and if not, add one:
    context = ensureSecurityManager(context);

    //Resolve an associated Session (usually based on a referenced session ID), and place it in the context before
    //sending to the SubjectFactory.  The SubjectFactory should not need to know how to acquire sessions as the
    //process is often environment specific - better to shield the SF from these details:
    context = resolveSession(context);

    //Similarly, the SubjectFactory should not require any concept of RememberMe - translate that here first
    //if possible before handing off to the SubjectFactory:
    context = resolvePrincipals(context);

    Subject subject = doCreateSubject(context);

    //save this subject for future reference if necessary:
    //(this is needed here in case rememberMe principals were resolved and they need to be stored in the
    //session, so we don't constantly rehydrate the rememberMe PrincipalCollection on every operation).
    //Added in 1.2:
    save(subject);

    return subject;
}

初次進入shiroFilter，會建立一個Subject，這個Subject沒有驗證通過，保留了三個屬性：request，response，securityManager。

當我們呼叫subject.login的時候，我們在DefaultSecurityManager中為subjectContext設定了相關屬性：

protected Subject createSubject(AuthenticationToken token, AuthenticationInfo info, Subject existing) {
    SubjectContext context = createSubjectContext();
    context.setAuthenticated(true);
    context.setAuthenticationToken(token);
    context.setAuthenticationInfo(info);
    if (existing != null) {
        context.setSubject(existing);
    }
    // 這個方法的具體實現在上面
    return createSubject(context);
}

一個save方法為我們構造了session：

save(subject);

這個session是根據我們的principals（放在登入成功返回的那個AuthenticationInfo中）構造的。

下一次進入的時候，依然是：

final Subject subject = createSubject(request, response);

但是下面的方法為我們找回了session，通過request.getSession(false)就可以取到。

context = resolveSession(context);

有了session後其他的東西都可以恢復，這樣就可以識別並維持一個subject的狀態，即使每次都重新建立了Subject物件。

具體是在DefaultWebSubjectFactory這個方法裡恢復的，並且通過構造器賦值給下一個新的subject了：

public Subject createSubject(SubjectContext context) {
    if (!(context instanceof WebSubjectContext)) {
        return super.createSubject(context);
    }
    WebSubjectContext wsc = (WebSubjectContext) context;
    SecurityManager securityManager = wsc.resolveSecurityManager();
    Session session = wsc.resolveSession();
    boolean sessionEnabled = wsc.isSessionCreationEnabled();
    PrincipalCollection principals = wsc.resolvePrincipals();
    boolean authenticated = wsc.resolveAuthenticated();
    String host = wsc.resolveHost();
    ServletRequest request = wsc.resolveServletRequest();
    ServletResponse response = wsc.resolveServletResponse();

    return new WebDelegatingSubject(principals, authenticated, host, session, sessionEnabled,
            request, response, securityManager);
}

舉兩個例子：

PrincipalCollection principals = wsc.resolvePrincipals();
-> principals = (PrincipalCollection) session.getAttribute(PRINCIPALS_SESSION_KEY);

boolean authenticated = wsc.resolveAuthenticated();
-> Session session = resolveSession();
if (session != null) {
    Boolean sessionAuthc = (Boolean) session.getAttribute(AUTHENTICATED_SESSION_KEY);
    authc = sessionAuthc != null && sessionAuthc;
}

通過上面兩個方法就恢復了Subject的兩個屬性，其實都是存放在session中。

其實只要你使用了Shiro，不管你是否登入，核心過濾器都會為我們構造Subject例項，當我們主動呼叫subject.login方法時，會間接呼叫我們自己實現的realm的doGetAuthenticationInfo，根據我們在資料庫中獲取的資訊（存放在info中）和呼叫login方法時傳遞的AuthenticationToken中的資訊對比。

當info為null或者丟擲了AuthenticationException異常，都視為登入失敗。