Apache Shiro-Benutzerhandbuch (2) Shiro-Zertifizierung

Apache Shiro-Benutzerhandbuch (2) Shiro-Authentifizierung

Authentifizierung ist der Prozess der Überprüfung der Benutzeridentität. Während des Authentifizierungsprozesses müssen Benutzer Entitätsinformationen (Principals) und Anmeldeinformationen (Credentials) übermitteln, um zu überprüfen, ob der Benutzer legitim ist. Die häufigste Kombination aus „Entität/Anmeldeinformation“ ist die Kombination aus „Benutzername/Passwort“.

1. Shiro-Authentifizierungsprozess

1. Sammeln Sie Entitäts-/Anmeldeinformationen

//Example using most common scenario of username/password pair:  
UsernamePasswordToken token = new UsernamePasswordToken(username, password);  
//”Remember Me” built-in:  
token.setRememberMe(true);

UsernamePasswordToken unterstützt die gängigsten Benutzernamen-/Passwort-Authentifizierungsmechanismen. Da es die Schnittstelle RememberMeAuthenticationToken implementiert, können wir gleichzeitig die Funktion „An mich erinnern“ über das Token festlegen.
Es gibt jedoch einen Unterschied zwischen „erinnert“ und „authentifiziert“:
Gemerkte Benutzer sind nur nicht anonyme Benutzer, und Sie können Benutzerinformationen über subject.getPrincipals() erhalten. Es handelt sich jedoch nicht um einen vollständig authentifizierten Benutzer. Wenn Sie auf Funktionen zugreifen, die authentifizierte Benutzer erfordern, müssen Sie die Authentifizierungsinformationen erneut übermitteln.
Diesen Unterschied können Sie auf der Amazon-Website nachlesen. Die Website merkt sich standardmäßig angemeldete Benutzer. Bei nicht vertraulichen Seitenfunktionen werden die gespeicherten Benutzerinformationen auf der Seite angezeigt. Wenn Sie jedoch auf die Kontoinformationen der Website zugreifen, müssen Sie sich erneut anmelden.

2. Entitäts-/Anmeldeinformationen übermitteln

Subject currentUser = SecurityUtils.getSubject();  
currentUser.login(token);

Nach dem Sammeln der Entitäts-/Anmeldeinformationen können wir den aktuellen Benutzer über die SecurityUtils-Toolklasse abrufen und dann die Authentifizierung übermitteln, indem wir die Anmeldemethode.

3. Authentifizierungsverarbeitung

try {  
    currentUser.login(token);  
} catch ( UnknownAccountException uae ) { ...  
} catch ( IncorrectCredentialsException ice ) { ...  
} catch ( LockedAccountException lae ) { ...  
} catch ( ExcessiveAttemptsException eae ) { ...  
} ... catch your own ...  
} catch ( AuthenticationException ae ) {  
    //unexpected error?  
}

Wenn die Anmeldemethode ohne Auslösen von Ausnahmeinformationen abgeschlossen wird, gilt die Benutzerauthentifizierung als bestanden. Anschließend kann durch Aufrufen von SecurityUtils.getSubject() an einer beliebigen Stelle in der Anwendung die aktuell authentifizierte Benutzerinstanz abgerufen werden. Wenn Sie mit subject.isAuthenticated() ermitteln, ob der Benutzer authentifiziert wurde, wird „true“ zurückgegeben ausgeführt. Wenn eine Ausnahme ausgelöst wird, wird die Authentifizierung als fehlgeschlagen betrachtet. Shiro verfügt über einen umfangreichen Satz unterschiedlicher Ausnahmeklassen, um die Gründe für Authentifizierungsfehler zu beschreiben, beispielsweise Codebeispiele.

2. Abmeldevorgang
Der Abmeldevorgang kann Ihre Anmeldeinformationen durch Aufrufen von subject.logout() löschen, z. B.:

currentUser.logout(); //removes all identifying information and invalidates their session too.

Nachdem der Abmeldevorgang abgeschlossen ist, wird die Sitzung beendet Die Informationen werden gelöscht und der Betreff wird als anonymer Benutzer betrachtet.

3. Interner Verarbeitungsmechanismus der Shiro-Authentifizierung
Das Obige ist der Verarbeitungsprozess der Shiro-Authentifizierung in der Anwendung. Der interne Verarbeitungsmechanismus der Shiro-Authentifizierung wird im Folgenden ausführlich erläutert.

Wie oben gezeigt, verwenden wir den Authentifizierungsteil des Shiro-Architekturdiagramms, um die interne Verarbeitungssequenz der Shiro-Authentifizierung zu veranschaulichen:

1. Benutzerauthentifizierungsinformationen Rufen Sie nach der AuthenticationToken-Instanz die Methode Subject.login auf.
2. Die Instanz von Sbuject ist normalerweise ein Instanzobjekt der DelegatingSubject-Klasse (oder Unterklasse). Wenn die Authentifizierung beginnt, wird die von der Anwendung festgelegte securityManager-Instanz zum Aufrufen der securityManager.login(token)-Methode delegiert.
3. Nach Erhalt der Token-Informationen vertraut SecurityManager eine Instanz des integrierten Authenticators (normalerweise eine Instanz der ModularRealmAuthenticator-Klasse) an, um Authenticator.authenticate(token) aufzurufen, oder es werden mehrere Realm-Instanzen angepasst , das tatsächlich einen steckbaren Authentifizierungsmechanismus für Shiro bereitstellt.
4. Wenn in der Anwendung mehrere Realms konfiguriert sind, führt ModularRealmAuthenticator den Multi-Realm-Authentifizierungsprozess gemäß der konfigurierten AuthenticationStrategy (Authentifizierungsstrategie) durch. Nachdem Realm aufgerufen wurde, antwortet AuthenticationStrategy auf jedes Realm-Ergebnis.
Hinweis: Wenn in der Anwendung nur ein Realm konfiguriert ist, wird Realm direkt aufgerufen, ohne die Authentifizierungsrichtlinie zu konfigurieren.
Bestimmen Sie, ob jeder Realm das übermittelte Token unterstützt. Die getAuthenticationInfo-Methode ist die eigentliche Authentifizierungsverarbeitung, indem wir die doGetAuthenticationInfo-Methode von Realm überschreiben.

4. Verarbeitungsmechanismus mit mehreren Realms:

1. Authenticator
Die Standardimplementierung ist ModularRealmAuthenticator, der sowohl einzelne Realms als auch mehrere Realms unterstützt. Wenn nur ein Realm konfiguriert ist, ruft ModularRealmAuthenticator den Realm direkt auf, um die Authentifizierungsinformationen zu verarbeiten. Wenn mehrere Realms konfiguriert sind, passt er den Realm entsprechend der Authentifizierungsrichtlinie an und findet den entsprechenden Realm zum Ausführen der Authentifizierungsinformationen.
Authentifikatorkonfiguration anpassen:

[main]  
...  
authenticator = com.foo.bar.CustomAuthenticator  
securityManager.authenticator = $authenticator

2、AuthenticationStrategy（认证策略）
当应用程序配置了多个Realm时，ModularRealmAuthenticator将根据认证策略来判断认证成功或是失败。
例如，如果只有一个Realm验证成功，而其他Realm验证失败，那么这次认证是否成功呢？如果大多数的Realm验证成功了，认证是否就认为成功呢？或者，一个Realm验证成功后，是否还需要判断其他Realm的结果？认证策略就是根据应用程序的需要对这些问题作出决断。
认证策略是一个无状态的组件，在认证过程中会经过4次的调用：

在所有Realm被调用之前

在调用Realm的getAuthenticationInfo 方法之前

在调用Realm的getAuthenticationInfo 方法之后

在所有Realm被调用之后

认证策略的另外一项工作就是聚合所有Realm的结果信息封装至一个AuthenticationInfo实例中，并将此信息返回，以此作为Subject的身份信息。
Shiro有3中认证策略的具体实现：

AtLeastOneSuccessfulStrategy 只要有一个（或更多）的Realm验证成功，那么认证将被视为成功

FirstSuccessfulStrategy 第一个Realm验证成功，整体认证将被视为成功，且后续Realm将被忽略

AllSuccessfulStrategy 所有Realm成功，认证才视为成功

ModularRealmAuthenticator 内置的认证策略默认实现是AtLeastOneSuccessfulStrategy 方式，因为这种方式也是被广泛使用的一种认证策略。当然，你也可以通过配置文件定义你需要的策略，如：

[main]  
...  
authcStrategy = org.apache.shiro.authc.pam.FirstSuccessfulStrategy  
securityManager.authenticator.authenticationStrategy = $authcStrategy  
...

3、Realm的顺序
由刚才提到的认证策略，可以看到Realm在ModularRealmAuthenticator 里面的顺序对认证是有影响的。
ModularRealmAuthenticator 会读取配置在SecurityManager里的Realm。当执行认证是，它会遍历Realm集合，对所有支持提交的token的Realm调用getAuthenticationInfo 。
因此，如果Realm的顺序对你使用的认证策略结果有影响，那么你应该在配置文件中明确定义Realm的顺序，如：

blahRealm = com.company.blah.Realm  
...  
fooRealm = com.company.foo.Realm  
...  
barRealm = com.company.another.Realm  
  
securityManager.realms = $fooRealm, $barRealm, $blahRealm

以上就是Apache Shiro 使用手册（二）Shiro 认证的内容，更多相关内容请关注PHP中文网（www.php.cn）！