Shiro actual combat series (7): real

Realm is an application specific security data access platform (such as users, roles and permissions). Realm converts application specific data into a format that Shiro can understand, so that Shiro can provide a single understandable subject programming API, no matter how many data sources exist or what your application specific data is. Realm usually has a one-to-one correspondence with data sources, such as correlation coefficient Database, LDAP directory, file system, or other similar resources. Therefore, the implementation of the real interface uses data source specific APIs to display authorized data (roles, permissions, etc.), such as JDBC, file IO, hibernate or JPA, or other data access APIs.

Real is essentially a specific secure Dao, because most of these data sources usually store authentication data (such as password credentials) and authorization data (such as roles or permissions). Each Shiro real can perform authentication and authorization operations.

(1)Realm configuration

If you use Shiro's ini configuration file, you can customize and reference realms, just like any other object in the [main] item, but they are configured in one of two ways in securitymanager: explicit or implicit.

(2)Explicit Assignment

Based on the INI configuration knowledge so far, this is a displayed configuration method. After defining one or more realms, you use them as the collection properties of the securitymanager object

Explicit allocation is deterministic - you control which realms are used and the order in which they are used for authentication and authorization. The role of the realm sequence is described in detail in the authentication sequence section of the authentication chapter.

(3) Implicit Assignment

Not preferred

This approach can lead to unexpected behavior if you change the order of realm definitions. It is recommended that you avoid this method and use explicit allocation, which has definite behavior. This feature is likely to be discarded or removed in future Shiro versions. If for some reason you don't want to explicitly configure the securitymanager With the properties of realms, you can allow Shiro to detect all configured realms and directly assign them to the security manager. Using this method, realms will be assigned to the securitymanager instance in their predefined order. That is, for the following Shiro Ini example:

blahRealm = com. company. blah. Realm

fooRealm = com. company. foo. Realm

barRealm = com. company. another. Realm

# no securityManager. realms assignment here

Basically the same effect as the following line:

securityManager. realms = $blahRealm,$fooRealm,$barRealm

However, to implement implicit allocation, only the order defined by realm directly affects their access order in authentication and authorization attempts. If you change the order in which they are defined, you will change how the authentication sequence of the main authenticator works. For this reason, and to ensure explicit behavior, we recommend explicit allocation rather than implicit allocation.

(3) Realm Authentication

After you understand Shiro's main authentication workflow, it is important to understand what happens when the authenticator interacts with real in an authorization attempt.

a.Supporting AuthenticationTokens

As mentioned in the authentication sequence, the supports method of real is called before it is accessed to perform an authorization attempt. If the return value is true, its getauthenticationinfo (token) method will be called only in this way. Usually, realm will check the type (interface or class) of the submitted token to determine whether it can handle it.

For example, a realm that can handle biological data may not understand usernamepasswordtokens at all, so it will return false from the supports method.

b.Handling supported AuthenticationTokens

If the realm supports a submitted authenticationtoken, the authenticator will call the getauthenticationinfo (token) method of the realm. This effectively represents an authorization attempt with the backup data source of real. The method is carried out as follows:

1. Check the token for the main identification information (account identification information).

2. Find the matching account data in the data source based on principal.

3. Ensure that the credentials supported by the token match those stored in the data source.

4. If the credentials match, an authenticationinfo instance encapsulating the account data format that Shiro can understand is returned.

5. If the credentials do not match, an authenticationexception will be thrown.

This is the highest level workflow for all realm getauthenticationinfo implementations. In this method, realms are free to do whatever they want, such as trying to record in the audit log, updating the data record, or anything else that makes sense for the authentication attempt of the data store. The only thing needed is that if credentials matches the given principal (s), a non empty authenticationinfo instance is returned to represent the subject account information from the data source.

c.Save Time

Directly implementing the realm interface may lead to time consumption and errors. Most people choose to subclass the authoringrealm abstract class instead of starting from scratch. This class implements the commonly used authentication and authorization workflow to save you time and energy.

d.Credentials Matching

In the realauthentication workflow above, Realm had to verify the credentials submitted by the subject (e.g., password) must match the credentials stored in the data store. If they match, the authentication is considered successful, and the system must also verify the identity of the end user. Real credentials matching is the responsibility of each real to match the submitted credentials and those stored in the real backup data store, not authentica Responsibility of the contractor. Each realm has the credentials format for private information, stores and can perform detailed credentials matching. However, authenticator is only an ordinary workload component.

The matching process of credentials is almost the same in all applications. What is usually different is the data for comparison. To ensure that the process is pluggable and customizable, authenticatingrealm and its subclasses support the concept of credentials matcher to perform credentials comparison if necessary. After discovering the account data, it and the submitted authenticationtoken are used to represent a credentialsmatcher to judge whether the submitted data matches the stored data. Shiro has some credentialsmatcher implementations that you can use immediately, such as simplecredentialsmatcher and hashedcredentialsmatcher, but if you want to configure a custom implementation for custom logic, you can do it directly as follows:

e.Simple Equality Check

By default, simplecredentialsmatcher is used for all realms available immediately by Shiro. Simplecredentialsmatcher performs a normal direct equality check between the stored account credentials and the submitted in the authenticationtoken.

For example, if a usernamepasswordtoken is submitted, the simplecredentialsmatcher verifies that the password is actually the same as the password stored in the database. Simplecredentialsmatcher does more than just perform direct equality comparisons for strings. It can handle most commonly used bytecodes, such as strings, character arrays, byte arrays, files and input streams. Please refer to its Javadoc for more information.

f.Hashing Credentials

Instead of storing credentials in its original form and performing original / normal comparison, A more secure way to store end-user credentials (e.g., passwords) is to hash them one-way before storing them in the data store. This ensures that end-user credentials will never be stored in the original form, and no one will know the original value. This is a more secure mechanism than plain text or original comparison, and all applications concerned with security should prefer non hashed storage. In order to Supporting these preferred encryption hash policies, Shiro provides the implementation of hashedcredentialsmatcher, which is configured on the realm instead of the simplecredentialsmatcher described above. The benefits of hash credentials and salting and multiple hash iterations are beyond the scope of this real document, but it is absolutely necessary to read the Javadoc of hashedcredentialsmatcher, which will cover these details in detail.

g.Hashing and Corresponding Matchers

So how can you easily configure a Shiro enabled application? Shiro provides several subclass implementations of hashedcredentialsmatcher. You must configure the specified implementation in your realm to match the hash algorithm you use when hashing your user credentials.

For example, suppose your application uses a username / password pair for authentication. Because of the benefits of hash credentials described above, suppose that when you create a user account, you want to use the SHA-256 algorithm to hash the user's password one way. You will hash the plain text password entered by the user and keep the value:

Since you use SHA-256 to hash your user's password, you need to tell Shiro to use the appropriate hashedcredentials matcher to match your hash parameter selection. In this example, we create a random salt and perform 1024 hash iterations. For strong security (see the Javadoc of hashedcredentialsmatcher for the reason). Here is the Shiro ini configuration to complete this work:

h.SaltedAuthenticationInfo

In order to ensure this project, the last thing to do is that your real implementation must return a saltedauthenticationinfo instance instead of an ordinary authenticationinfo instance. The saltedauthenticationinfo interface ensures that you create a user account (for example, user. Setpasswordsalt (salt); Salt used in call above) can be referenced by hashedcredentialsmatcher Hashedcredentialsmatcher needs the salt to perform the same hash technology on the submitted authenticationtoken to determine whether the token matches what you save in the data store. Therefore, if you use salting for user passwords (and you should!!!), ensure that your real implementation can represent passwords through the returned saltedauthenticationinfo instance.

i.Disabling Authentication

If for some reason, You don't want to authenticate the data source with realm (perhaps because you only want real to perform authorization), you can completely disable real's support for authentication by returning false from real's support method. Then your real will never be accessed in authentication attempts. Of course, at least one configured real that supports authenticationtokens is required if you want to verify subjects