Apache Shiro User Manual (ii) Shiro certification

Authentication is the process of verifying a user's identity. During the authentication process, the user is required to submit entity information (principals) and credential information (Credentials) to verify that the user is legitimate. The most common "entity/credential" combination is the "username/password" combination.

First, the Shiro certification process

1. Collect Entity/credential information

Java code

1. Example using the most common scenario of Username/password pair:
2. Usernamepasswordtoken token = new Usernamepasswordtoken (username, password);
3. "Remember Me" built-in:
4. Token.setrememberme (true);

Usernamepasswordtoken supports the most common user name/password authentication mechanism. At the same time, because it implements the Remembermeauthenticationtoken interface, we can set the "Remember Me" function through the token.
However, there is a difference between "remembered" and "Certified":
The remembered user is just a non-anonymous user, and you can get user information through Subject.getprincipals (). However, it is not a fully authenticated user, and you still need to resubmit the authentication information when you access the functionality that requires the authenticated user.
This distinction can be referred to the Amazon website, the site will default to remember the logged-in users, re-visit the site, for the non-sensitive page features, the page will display the remembered user information, but when you visit the website account information, you still need to re-login authentication.

2. Submit Entity/Credential information

Java code

1. Subject CurrentUser = Securityutils.getsubject ();
2. Currentuser.login (token);

After collecting the entity/credential information, we can get the current user through the Securityutils tool class, and then submit the authentication by calling the login method.

3, authentication processing

Java code

2. try {
4. Currentuser.login (token);
6. } catch (unknownaccountexception UAE) {...
8. } catch (Incorrectcredentialsexception ice) {...
10. } catch (Lockedaccountexception lae) {...
12. } catch (Excessiveattemptsexception Eae) {...
14. } ... catch your own ...
16. } catch (Authenticationexception ae) {
18. //unexpected error?
20. }

If the login method executes and does not throw any exception information, then the user authentication is considered passed. Securityutils.getsubject () can then be called anywhere in the application to obtain the user instance passed to the current authentication, using subject.isauthenticated () to determine whether the user is authenticated and returns TRUE.
Conversely, if an exception is thrown during the execution of the login method, the authentication will be considered unsuccessful. Shiro has a rich layer of distinct exception classes to describe the reasons for authentication failures, such as code examples.

Second, the logout operation
The logout operation can delete your login information by calling Subject.logout (), such as:

Java code

1. Currentuser.logout ();  //removes All identifying information and invalidates their session too.

When the logout operation is completed, the session information will be emptied and subject will be treated as an anonymous user.

third, authentication internal processing mechanism
Above, is the Shiro authentication in the application processing process, below will explain in detail the Shiro authentication internal processing mechanism.


For example, we use the certification section of the Shiro frame composition to illustrate the processing order within the Shiro certification:
1. After the application constructs an Authenticationtoken instance of the end user authentication information, the Subject.login method is called.
2. An instance of Sbuject is typically an instance object of the Delegatingsubject class (or subclass) that, at the beginning of authentication, delegates the SecurityManager instance set by the application to invoke the Securitymanager.login (token) method.
3, SecurityManager received token (token) The information is then delegated to the built-in authenticator instance (usually an instance of the Modularrealmauthenticator Class) to invoke Authenticator.authenticate (token). Modularrealmauthenticator in the authentication process, the set of one or more realm instances to adapt, it actually provides Shiro a pluggable authentication mechanism.
4. If multiple realm,modularrealmauthenticator are configured in the application, a multi-realm authentication process will be performed based on the configured authenticationstrategy (Authentication policy). After realm is called, Authenticationstrategy will respond to the results of each realm.
Note: If only one Realm,realm is configured in the application, it will be called directly without the need to configure the authentication policy.
5, judge whether each realm supports the submission of tokens, if supported, realm will call Getauthenticationinfo (token); Getauthenticationinfo method is the actual authentication processing, we write our custom authentication processing by covering realm's Dogetauthenticationinfo method.

Four, the use of multiple realm processing mechanism:

1, Authenticator
The default implementation is Modularrealmauthenticator, which supports both a single realm and multiple realms. If only one realm,modularrealmauthenticator is configured to directly invoke the realm processing authentication information, if more than one realm is configured, it will adapt realm according to the authentication policy and find the appropriate realm to perform the authentication information.
Customizing the configuration of the authenticator:

Java code

1. [Main]
2. ...
3. Authenticator = Com.foo.bar.CustomAuthenticator
4. Securitymanager.authenticator = $authenticator

2, Authenticationstrategy (Authentication policy)
When the application is configured with multiple realms, Modularrealmauthenticator will determine the authentication success or failure according to the authentication policy.
For example, if only one realm authentication succeeds and the other realm fails, is the certification successful? If most realm validation succeeds, does the certification think it is successful? Or, after a realm verification succeeds, is it necessary to determine the results of other realms? The authentication strategy is to make decisions about these issues based on the needs of the application.
The authentication policy is a stateless component that is called 4 times during the authentication process:

• Before all realms have been called
• Before calling the realm's Getauthenticationinfo method
• After calling the realm's Getauthenticationinfo method
• After all realms have been called

Another task of the authentication strategy is to aggregate the result information of all realms into a AuthenticationInfo instance and return this information as subject identity information.
Shiro has 3 of the specific implementation of the authentication policy:

Atleastonesuccessfulstrategy	As long as one (or more) realm verification is successful, the certification will be considered a success
Firstsuccessfulstrategy	The first realm verification succeeds, the overall certification will be considered successful, and the subsequent realm will be ignored
Allsuccessfulstrategy	All realms are successful and certified as successful

The default implementation of the Modularrealmauthenticator built-in authentication policy is atleastonesuccessfulstrategy, because this approach is also widely used as an authentication strategy. Of course, you can also define the policies you need through the configuration file, such as:

Java code

1. [Main]
2. ...
3. Authcstrategy = Org.apache.shiro.authc.pam.FirstSuccessfulStrategy
4. SecurityManager.authenticator.authenticationStrategy = $authcStrategy
5. ...

3. Order of Realm
By the authentication strategy just mentioned, you can see that the order of realm in Modularrealmauthenticator has an impact on authentication.
Modularrealmauthenticator will read the realm configured in SecurityManager. When the authentication is performed, it traverses the realm collection and calls Getauthenticationinfo for all realms that support the token being submitted.
Therefore, if the order of realms affects the results of the authentication policy you use, you should explicitly define the order of realms in the configuration file, such as:

Java code

1. Blahrealm = Com.company.blah.Realm
2. ...
3. Foorealm = Com.company.foo.Realm
4. ...
5. Barrealm = Com.company.another.Realm
7. Securitymanager.realms = $fooRealm, $barRealm, $blahRealm

Apache Shiro User Manual (ii) Shiro certification