Apache Shiro use Manual (ii) Shiro certification _linux

First, Shiro certification process

1. Collect Entity/credential information

Copy Code code as follows:

Example using most common scenario of Username/password pair:
Usernamepasswordtoken token = new Usernamepasswordtoken (username, password);
"Remember Me" built-in:
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 "remember" and "Certified":
The remembered user is only a non-anonymous user, and you can get the user information by Subject.getprincipals (). However, it is not a fully authenticated user, and you still need to resubmit the authentication information when you access the function that requires authenticated users.
This difference can refer to the Amazon site, the site will be remembered by default to log on users, once again visit the site, for the insensitive page features, the page will show the user information to remember, but when you visit the site account information still need to log in again authentication.

2. Submitting Entity/credential information

Copy Code code as follows:

Subject CurrentUser = Securityutils.getsubject ();
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 invoking the login method.

3, authentication processing

Copy Code code as follows:

try {
Currentuser.login (token);
catch (unknownaccountexception UAE) {...
catch (Incorrectcredentialsexception ice) {...
The catch (Lockedaccountexception Lae) {...
The catch (Excessiveattemptsexception Eae) {...
... catch your own ...
catch (Authenticationexception ae) {
Unexpected error?
}

If the login method completes without throwing any exception information, the user authentication is considered passed. Securityutils.getsubject () can then be invoked anywhere in the application to obtain a user instance that is currently authenticated, using subject.isauthenticated () to determine whether the user is authenticated and returns TRUE.
Conversely, if the login method throws an exception during execution, the authentication fails. Shiro has a rich hierarchy of exception classes to describe the reasons for authentication failures, such as code examples.

Second, the logout operation

Logout can delete your login information by calling Subject.logout (), such as:

Copy Code code as follows:

Currentuser.logout (); Removes all identifying information and invalidates their the session too.

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

III. authentication internal processing mechanism

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





As shown above, we use the Shiro frame composition of the certification section to explain the Shiro certification internal processing sequence:

1. The application constructs a Authenticationtoken instance of end-user authentication information, and then invokes the Subject.login method.
2. An instance of Sbuject is usually an instance object of a Delegatingsubject class (or subclass), and the SecurityManager instance of the application setting is delegated to the Securitymanager.login (token) method at the beginning of authentication.
3, SecurityManager received to token (token) The information is then delegated to the built-in authenticator instance (typically an instance of the Modularrealmauthenticator Class) to invoke Authenticator.authenticate (token). Modularrealmauthenticator in the certification process will be set of one or more realm instances of the adaptation, it actually provides a shiro to provide a pluggable authentication mechanism.
4. If multiple realm,modularrealmauthenticator are configured in the application, the realm authentication process will be performed according to the configured Authenticationstrategy (Authentication policy). After the realm is invoked, 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 having to reconfigure the authentication policy.
5, to determine whether each realm support the submission of the token, if supported, realm will call Getauthenticationinfo (token); The Getauthenticationinfo method is the actual authentication processing, we write our custom authentication processing by covering the realm Dogetauthenticationinfo method.

Four, the use of multiple realm processing mechanism:

1, Authenticator
The default implementation is Modularrealmauthenticator, which supports both single realm and multiple realm. If only one realm,modularrealmauthenticator is configured, the realm processing authentication information is invoked directly, and if multiple realm are configured, it will match the realm according to the authentication policy and find the appropriate realm execution authentication information.
Customizing the Authenticator configuration:

Copy Code code as follows:

[Main]
...
Authenticator = Com.foo.bar.CustomAuthenticator
Securitymanager.authenticator = $authenticator

2, Authenticationstrategy (authentication strategy)

When the application is configured with multiple realm, Modularrealmauthenticator will judge the authentication success or failure according to the authentication policy.
For example, if only one realm validation succeeds, and the other realm fails, does the authentication succeed? If most of the realm validation succeeds, does the certification think it is successful? Or, after a realm validation succeeds, is it necessary to judge the results of other realm? The authentication strategy is to make decisions about these issues based on the needs of the application.
Authentication policy is a stateless component that will be invoked 4 times during the authentication process:
Before all realm are called
Before calling the Realm Getauthenticationinfo method
After calling the realm Getauthenticationinfo method
After all realm are called
Another task of the authentication strategy is to encapsulate all realm result information in a AuthenticationInfo instance and return this information as subject identity information.
Shiro has 3 of the specific implementation of the authentication strategy:

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

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

Copy Code code as follows:

[Main]
...
Authcstrategy = Org.apache.shiro.authc.pam.FirstSuccessfulStrategy
SecurityManager.authenticator.authenticationStrategy = $authcStrategy
...

3, the Order of realm

From the authentication strategy just mentioned, we can see that the order of realm in Modularrealmauthenticator has an effect on the authentication.
Modularrealmauthenticator will read the realm configured in SecurityManager. When the authentication is performed, it traverses the Realm collection, calling Getauthenticationinfo for all realm that support the submission of token.
Therefore, if the order of realm affects the outcome of the authentication policy you are using, you should explicitly define the order of realm in the configuration file, such as:

Copy Code code as follows:

Blahrealm = Com.company.blah.Realm
...
Foorealm = Com.company.foo.Realm
...
Barrealm = Com.company.another.Realm
Securitymanager.realms = $fooRealm, $barRealm, $blahRealm