Shulou(Shulou.com)06/02 Report--

This article is about how to let Apache Shiro protect your application. I think it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it.

* authentication: authentication * authorization: authorization * cryptography: cryptography 1: Overview (1) What is Apache Shiro?

Apache Shiro is a powerful and flexible open source security framework that neatly handles authentication, authorization, enterprise session management, and encryption.

(2) Apache Shiro Features

Second, core concepts: Subject,SecurityManager,Realms (1) Subject

When considering application security, the most common question you ask may be "who is the current user?" Or "is the current user allowed to do X?" .

For us, the most natural way to consider application security is based on the current user. Shiro's API fundamentally embodies this way of thinking with its Subject concept.

The word Subject is a security term that basically means "current operating user". It is not accurate to call it "user" because the word "user" is usually related to people. In the security world, the term "Subject" can be a person, a third-party process, a back-end account (Daemon Account), or something like that. It just means * "what currently interacts with the software". But for most purposes and uses, you can think of it as Shiro's "user" concept. You can easily get Shiro Subject anywhere in the code.

Import org.apache.shiro.subject.Subject;import org.apache.shiro.SecurityUtils;...Subject currentUser = SecurityUtils.getSubject ()

Once you get Subject, you can immediately get 90% of the things you want to do with Shiro for current users, such as logging in, logging out, accessing sessions, performing authorization checks, and so on.

(2) the "behind the scenes" driver of SecurityManager1.Subject is SecurityManager

Subject represents the security operations of current users, while SecurityManager manages the security operations of all users. It is the core of the Shiro framework and acts as an umbrella, referencing multiple internally nested security components that form an object graph. However, once SecurityManager and its internal object graph are configured, it retreats behind the scenes, and we are only responsible for calling Subject API.

two。 So, how do you set up SecurityManager?

It depends on the environment of the application. For example, Web applications typically specify a Shiro Servlet Filter in Web.xml, which creates an instance of SecurityManager.

(3) Realms

Realm acts as a bridge or connector between Shiro and application security data. In other words, when actually interacting with security-related data such as user accounts and performing authentication (login) and authorization (access control), Shiro will look up a lot of content in the Realm configured by the application.

In this sense, Realm is essentially a security-related DAO that encapsulates the connection details of the data source and provides the relevant data to the Shiro when needed. When configuring Shiro, you must specify at least one Realm for authentication and / or authorization. It is possible to configure multiple Realm, but at least one is required.

Third: authentication (authentication)

Authentication is the process of verifying the identity of a user. Sometimes this is understood as "login". It is a typical three-step process.

Collect the user's identity information, called the party (principal), and the supporting proof of identity, called the certificate (Credential).

Submit the parties and certificates to the system.

If the submitted certificate matches the expected identity of the user (the party), the user is considered authenticated, otherwise it is considered unauthenticated.

A common example of this process is the familiar "user / password" combination. When most users log in to the software system, they usually provide their own user name (party) and password (certificate) that supports them. If the password (or password representation) stored in the system matches the one provided by the user, they are considered authenticated.

Shiro supports the same process in a simple and intuitive way. As we said earlier, Shiro has a Subject-centric API-almost everything you want to accomplish at runtime with Shiro can be achieved by interacting with the currently executed Subject. Therefore, to log in to Subject, simply call its login method, passing in an AuthenticationToken instance that represents the party being submitted and the certificate (in this case, the user name and password).

/ / 1. Acceptance of submitted parties and certificates: AuthenticationToken token = new UsernamePasswordToken (username, password); / / 2. Get the current Subject:Subject currentUser = SecurityUtils.getSubject (); / / 3. Login: currentUser.login (token)

Shiro's API easily reflects this common process. You will continue to see this simple style in all Subject operations. After the login method is called, the SecurityManager receives the AuthenticationToken and sends it to the configured Realm to perform the necessary authentication checks. Each Realm can respond to the submitted AuthenticationTokens if necessary.

What happens if the login fails? What happens if the user provides the wrong password? You can control failures by responding to Shiro's runtime AuthenticationException

/ / 3. Login: try {currentUser.login (token);} catch (IncorrectCredentialsException ice) {… } catch (LockedAccountException lae) {… }... Catch (AuthenticationException ae) {… }

After Subject login is successful, they are considered to be authenticated, and usually you will allow them to use your application. But just proving the identity of a user doesn't mean they can do whatever they want with your app. This leads to another question, "how can I control what users can or cannot do?" The process of determining what a user is allowed to do is called authorization

IV: authorization (Authorization)

Authorization is essentially access control-controlling what content in the application users can access, such as resources, Web pages, and so on. Most users perform access control by using concepts such as roles and permissions. That is, what users are usually allowed or disallowed to do is based on the roles or permissions assigned to them. Then, by checking these roles and permissions, your application can control which features can be exposed. Subject API allows you to easily perform role and permission checks.

If (subject.hasRole ("administrator")) {/ / display the 'Create User' button} else {/ / button grayed out?}

As you can see, your application can turn certain functions on or off based on access control checks.

Permission checking is another way to perform authorization. The role check in the above example has a big flaw: you cannot add or delete roles at run time. Character names are hard-coded here, so if you change the role name or configuration, your code will be messed up! If you need to change the meaning of roles at run time, or if you want to add or delete roles, you have to find another way.

For this reason, Shiro supports the concept of permissions. Permissions are the original expressions of functions, such as' open the door', 'create a blog post', 'delete' jsmith' users, etc. By letting permissions reflect the original function of the application, you only need to change the permission check when you change the function of the application. In turn, you can assign permissions to roles or users as needed at runtime.

We can rewrite the previous user check and use the permission check instead.

If (subject.isPermitted ("user:create")) {/ / display the 'Create User' button} else {/ / button grayed out?}

In this way, any role or user with * * "user:create" * * permission can click the 'Create User' button, and these roles and assignments can even be changed at run time, which provides you with a very flexible security model.

The "user:create" string is an example of a permission string that follows specific parsing conventions. Shiro supports this out-of-the-box convention with its WildcardPermission. Although this is beyond the scope of this article, you will see that WildcardPermission is very flexible when creating security policies and even supports features such as instance-level access control.

If (subject.isPermitted ("user:delete:jsmith")) {/ / Delete 'jsmith' user} else {/ / do not delete' jsmith'} summary

The operation of subject will eventually turn to SecurityManager, which will consult Realm to make its own access control decisions.

If necessary, allow a single realm to respond to both authentication and authorization

Five: session Manager (Session Managerment)

In the area of security frameworks, Apache Shiro provides something unique: Session API can be used consistently at any application or architectural layer. That is, Shiro provides a session programming paradigm for any application

From small background independent applications to large cluster Web applications. This means that application developers who want to use sessions are not forced to use Servlet or EJB containers. Or, if you are using these containers, developers can now choose to use a consistent session API at any layer instead of the Servlet or EJB mechanism.

But perhaps one of the most important benefits of Shiro sessions is that they are container independent. This has a subtle but very powerful impact. For example, let's consider session clustering. How many container-specific ways are there to support fault tolerance and failover for cluster sessions? The way of Tomcat is different from that of Jetty, and Jetty is different from Websphere, and so on. But through Shiro sessions, you can get a container-independent clustering solution. Shiro's architecture allows pluggable session data storage, such as enterprise caches, relational databases, NoSQL systems, and so on. This means that as long as the session cluster is configured once, it will work in the same way, regardless of the deployment environment

Tomcat, Jetty, JEE server or stand-alone application. No matter how the application is deployed, there is no need to reconfigure the application.

Another benefit of Shiro sessions is that session data can be shared across client technologies if needed. For example, Swing desktop clients can participate in the same Web application session when needed-a feature that is useful if end users are using both applications. So how do you access Subject sessions in any environment? Take a look at the following example, which uses two methods of Subject.

Session session = subject.getSession (); Session session = subject.getSession (boolean create)

These methods are conceptually equivalent to HttpServletRequest API. The first method returns an existing session of Subject, or if it does not already have a session, it creates a new one and returns it. The second method accepts a Boolean parameter that is used to determine whether to create a new session if the session does not exist. Once you have a session for Shiro, you can use it almost as if you were using HttpSession. The Shiro team found HttpSession API too comfortable for Java developers, so we retained a lot of its feel. Of course, the biggest difference is that you can use Shiro sessions in any application, not just Web applications.

Session session = subject.getSession (); session.getAttribute ("key", someValue); Date start = session.getStartTimestamp (); Date timestamp = session.getLastAccessTime (); session.setTimeout (millis); Six: encryption (Cryptography)

Encryption is the process of hiding or confusing data to avoid peeping. In terms of encryption, the goal of Shiro is to simplify and make JDK's encryption support available.

It is important to be clear that, in general, encryption is not specific to Subject, so it is part of Shiro API, but not specific to Subject. You can use Shiro encryption support anywhere, even without using Subject. When it comes to encryption support, the two areas that Shiro really focuses on are encrypted hashes (aka message digests) and encrypted passwords.

(1) Hash

If you have ever used JDK's MessageDigest class, you will immediately realize that it is a bit troublesome to use. The MessageDigest class has a clumsy factory-based static method API, which is not object-oriented, and you are forced to capture Checked Exceptions that you never have to capture. If you need to output message digests with hexadecimal or Base64 codes, you are on your own-there is no standard JDK to support both. Shiro solves this problem with a clean and intuitive hash API.

For example, consider the more common situation of using MD5 to hash a file and determine the hexadecimal value of the hash. It is called a 'checksum' and is often used when providing file downloads-users can perform their own MD5 hash on the downloaded file. If they match, the user can assume that the file has not been tampered with during the transfer.

1. Without using Shiro, you need the following steps to complete the above: 1) convert the file to a byte array.

No one in JDK does this, so you need to create a helper method to open the FileInputStream, use the byte cache, throw the relevant IOExceptions, and so on.

2) use the MessageDigest class to hash the byte array and handle related exceptions. Try {MessageDigest md = MessageDigest.getInstance ("MD5"); md.digest (bytes); byte [] hashed = md.digest ();} catch (NoSuchAlgorithmException e) {e.printStackTrace ();} 3) encodes the hashed byte array into hexadecimal characters.

You still don't do this in JDK, and you still need to create another helper method that may use bit manipulation and bit movement in your implementation.

two。 Use shiro to complete String hex = new Md5Hash (myFile) .toHex ()

When using Shiro to simplify all this work, everything is very simple and straightforward. Completing the Base64 encoding of SHA-512 hashes and passwords is just as simple.

String encodedPassword = new Sha512Hash (password, salt, count). ToBase64 ()

You can see that Shiro simplifies hashing and coding, saving the brain cells you consume in dealing with such problems.

(2) password

Encryption is an encryption algorithm that uses a key to inversely convert data. We use it to ensure the security of data, especially when it is transmitted or stored, and when it is easy to snoop.

If you have ever used JDK's Cryptography API, especially the javax.crypto.Cipher class, you will know that it is an extremely complex beast that needs to be tamed. For beginners, each possible encryption configuration is always represented by an javax.crypto.Cipher instance. Must public / private key encryption be performed? You have to use Cipher. Need to use block cipher (Block Cipher) for stream operations? You have to use Cipher. Need to create an AES 256bit Cipher to protect data? You have to use Cipher. You know.

So how do you create the Cipher instance you need? You have to create a non-intuitive, tag-delimited encryption option string, called "converted string (transformation string)", which is passed to the Cipher.getInstance static factory method. This string-style cipher option is not type-safe to ensure that you are using valid options. This also implies that there is no JavaDoc to help you understand the relevant options. And if the string format is not properly organized, you need to deal with Checked Exception further, even if you know the configuration is correct. As you can see, using JDK Cipher is a rather onerous task. A long time ago, these technologies were the standard for Java API, but things have changed and we need a simpler approach.

Shiro tries to simplify the whole concept of encrypted passwords by introducing its CipherService API. CipherService is what most developers dream of when protecting data: a simple, stateless, thread-safe API that can encrypt or decrypt entire data in a single method call. All you need to do is provide your key, and you can encrypt or decrypt it as needed.

AesCipherService cipherService = new AesCipherService (); cipherService.setKeySize (256); / / create a test key: byte [] testKey = cipherService.generateNewKey (); / / Bytes of encrypted file: byte [] encrypted = cipherService.encrypt (fileBytes, testKey)

It is much simpler than the example of JDK's Cipher API,Shiro:

You can instantiate a CipherService directly-no strange or confusing factory methods

Cipher configuration options can be expressed as JavaBean-compatible getter and setter methods-without strange and incomprehensible "conversion strings"

Encryption and decryption are done in a single method call

There is no imposed Checked Exception. If you prefer, you can capture the CryptoException of Shiro.

Shiro's CipherService API has other benefits, such as support for both byte array-based encryption / decryption (called "block" operations) and stream-based encryption / decryption (such as encrypting audio or video).

No longer have to endure the pain caused by Java Cryptography. Shiro's Cryptography support is designed to reduce your efforts to ensure data security.

Seven: web support (Web Support)

Shiro comes with a strong Web support module that helps protect Web applications. For Web applications, installing Shiro is easy. The only thing that needs to be done is to define a Shiro Servlet filter in web.xml.

(1) ShiroFilter ShiroFilter org.apache.shiro.web.servlet.IniShiroFilter ShiroFilter / * in web.xml

This filter reads the shiro.ini configuration so that you have a consistent configuration regardless of the development environment. Once configured, Shiro Filter filters each request and ensures that the Subject for a particular request is accessible during the request. And because it filters each request, you can implement security-specific logic to ensure that only requests that meet certain criteria are allowed to pass.

(2) URL-specific Filter chain

Shiro supports security-specific filtering rules through its innovative * * URL filter chain * * feature. It allows you to specify an informal filter chain for any matching URL pattern. This means that with Shiro's filter mechanism, you have the flexibility to enforce security rules (or combinations of rules)-far more than you get when you define filters in web.xml alone.

[urls] / assets/** = anon/user/signup = anon/user/** = user/rpc/rest/** = perms [rpc:invoke], authc/** = authc

Web applications can use the [urls] INI paragraph. For each line, the value to the left of the equal sign represents the Web application path relative to the context. The value to the right of the equal sign defines the filter chain-a comma-separated ordered list of Servlet filters that executes against the given path. Each filter is a normal Servlet filter, and the filter name you see above (anon,user,perms,authc) is a special security-related filter built into Shiro. You can use these security filters to create a highly customized security experience. You can also specify any other existing Servlet filter.

What are the benefits of this approach compared to using web.xml, where filter blocks are defined first and then separate filter pattern blocks are defined? Using the Shiro method, it is easy to know exactly which filter chain is executed for a given matching path. If you want to do this, you can define only Shiro Filter in web.xml and all other filters and filter chains in shiro.ini, which is much simpler than web.xml and makes it easier to understand the filter chain definition mechanism. Even if you don't use any of the security features of Shiro, it's worth using Shiro for such a small convenience.

(3) JSP tag library

Shiro also provides a JSP tag library that allows you to control the output of JSP pages based on the current state of Subject. A useful common example is to display the "Hello" text after the user logs in. But if you are anonymous, you may want to display other content, such as "Hello! Register Today!" instead.

...

Hello!! Register today!

In addition to the tags used in the example above, there are other tags that allow you to assign (or not) permissions based on the role the user belongs to (or does not belong to), whether authenticated, from the memory of the "remember me" service, or anonymous visitors, including output.

Shiro also supports many other Web features, such as simple "remember me" services, REST and BASIC authentication. Of course, it also provides transparent HttpSession support if you want to use Shiro's native enterprise session. See the Apache Shiro Web documentation for more information.

(4) Web session management

Finally, it is worth mentioning Shiro's support for sessions in the Web environment.

1. Default Http session

For Web applications, Shiro defaults to using the Servlet container session that we are used to as its session infrastructure. That is, when you call the subject.getSession () and subject.getSession (boolean) methods, Shiro returns the Session instance supported by the HttpSession instance of the Servlet container. The beauty of this approach is that the business layer code that calls subject.getSession () interacts with a Shiro Session instance-not yet "aware" that it is dealing with a Web-based HttpSession. This is a very good thing when maintaining a clear separation between architectural layers.

Native session of Shiro in the 2.Web layer

If you turn on native session management for Shiro due to the need for Shiro's enterprise session features (such as container-independent clustering), you certainly want HttpServletRequest.getSession () and HttpSession API to collaborate with "native" sessions rather than Servlet container sessions. If you have to ReFactor all the code that uses HttpServletRequest and HttpSession API and replace it with Shiro's Session API, it will be very frustrating. Shiro certainly would never expect you to do that.

Instead, Shiro fully implements the Session part of the Servlet specification to support native sessions in Web applications. This means that whenever you use the corresponding HttpServletRequest or HttpSession method calls, Shiro delegates those calls to the internal native session API. As a result, you don't need to modify the Web code, even if you're using Shiro's' native 'enterprise session management-a very convenient (and necessary) feature indeed.

The above is how to make Apache Shiro protect your application. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.