Follow me learn spring security--online Pet Shop development (i)

The application follows a standard three-tier structure, including the Web layer, the service layer, and the data access layer, as shown in:

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M00/8A/0B/wKioL1glMbjgsL-kAAAb4aXpVL4895.png "title=" 5f3fafb4-55ac-4349-80c4-fb0208660a6b.png "alt=" Wkiol1glmbjgsl-kaaab4axpvl4895.png "/>

The web layer encapsulates the code and functionality of MVC. In the sample code, we used the Spring MVC framework, but we can easily use the spring Web flow,struts or even a spring-friendly web stack such as Apache Wicket.

In a typical Web application that uses spring security, a large number of configuration and parameter codes are located on the Web tier. So, if you don't have Web application development, especially the spring MVC experience, you'd better look at the base code and make sure you understand it before we get into more complex topics. Again, we've tried to make our application simple and build it into a pet store just to give it a reasonable name and a lightweight structure. It can be compared with the complex Java EE Pet Clinic example, which shows the use of many techniques.

The service layer encapsulates the business logic of the application. In the example application, we made a thin faade in front of the data access layer to describe how to protect the application around a particular point in the service approach.

In a typical Web project, this layer will include business rule validation, assembling and factoring Bo, and cross-cutting concerns such as auditing.

The data access layer encapsulates the code that operates the database tables. In many spring-based projects, this will be found here using ORM technology such as Hibernate or JPA. It exposes an object-based API to the service layer. In the sample code, we use the basic JDBC functionality to complete the persistence of Hsql to the memory database.

In a typical Web project, a more complex approach to data access will be used. Developers are puzzled by the ORM, which is data access. So in order to be clearer, this part of us simplifies it as much as possible.

To be more efficient with spring security, it is important to understand some key concepts and terminology before starting to evaluate and improve the security posture of our applications.

Certifications

As we discussed in the first chapter, authentication is the person who identifies the user in our application as the one they claim to be. You may experience different scenarios of certification in your daily life, either online or offline:

• Two-factor authentication: When you want to withdraw money from the ATM, you must insert the card and enter your password before you are allowed to withdraw money and do other business. The authentication of this method is similar to the authentication method of user name and password, and the difference is that the user name information is encoded on the magnetic stripe of the card. Combined use of physical magnetic card and user input password can be the bank to confirm that you may have access to this account. Using a combination of passwords and physical devices (your ATM card) is a common form of two-factor authentication. Professionally, this type of device is common in security-demanding systems, especially when dealing with financial or personally identifiable information. Hardware devices such as RSA's SecurID combine the use of time-based hardware and server-side authentication software to make such an environment extremely difficult to destroy.

• Hardware certification: When you start the car in the morning, you insert the key and fire. Although similar to the other two examples, the match between your key and the ignition device is a hardware-certified method.

In fact, there are many kinds of authentication methods to solve the hardware and software security problems, they have their own advantages and disadvantages. We will cover some of them in later chapters of this book, as they apply to spring Security. In fact, the latter part of the book is basically the original introduction of a lot of common authentication methods with the implementation of spring security.

Spring Security extends the Certified Security entity (the word Principal) in the Java Standard Concept (Java.security.Principal), which is used to uniquely identify an authenticated entity. Although a typical security entity typically points to one user in a system, it may also correspond to various clients of the system, such as the client of the Web service, the auto-running feed aggregator (automated batch feed), and so on. In most scenarios, when you use spring security, a security entity (Principal) simply represents a user, so when we say a security entity, you can equate it with saying the user.

Authorized

Authorization typically involves two different aspects that collectively describe the accessibility of a security system.

The first is a matching relationship (often called a role) of a certified security entity with one or more permissions (authorities). For example, a

An unofficial user visiting your site will be treated as only access and the administrator of a site will be assigned administrative permissions.

The second is to assign permissions to check the resources that are being secured in the system. Typically this will be done during the development of the system and may

Explicit declarations through code can also be set through parameters. For example, the interface for managing the inventory of pet stores in our app can only

Open for users with administrative privileges.

"The resources to be secured can be anything on the system, and they will have selective access control based on the user's permissions." Web

A protected resource in an app can be a single page, a complete part of the site, or a portion of the interface. On the contrary, protected business resources can be

Can be a method call to a business object or a single business object. 】

You might imagine a permission check procedure for a security entity, find its user account, and determine if it is really an administrator. Such as

Check to determine if the security entity attempting to access the protected area is actually an administrator, the request will succeed, otherwise the

A security entity's request will be rejected because it lacks sufficient permissions.

We look at a specific protected resource-the editing interface of the product catalog-in closer proximity. The editing interface of the directory requires an administrator to access

(After all, we don't want ordinary users to be able to adjust our directory hierarchy), so when a security entity accesses it, it requires a specific

Level of permissions.

When we think about how the administrator of a site tries to access a protected resource, we suspect that when a permission control decision is made

The checking process of the permission of the resource can be expressed concisely by the set theory. We will use the Venn diagram to illustrate the decision to manage users

Policy process:

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M02/8A/5A/wKiom1guSvGhAGAjAABatiIysyA601.png "title=" D8d98d32-b917-3e72-9da8-103f5e6024a5.png "alt=" Wkiom1gusvghagajaabatiiysya601.png "/>

For this page, there is an intersection between user rights (normal users and administrators) and required permissions (administrators), so users in the intersection will be able to access them.

You can compare with a visitor who is not authorized:

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M00/8A/56/wKioL1guS8zzggZlAABKod5v-rI879.png "title=" 3e751959-241d-338c-b64e-f9474d188e76.png "alt=" Wkiol1gus8zzggzlaabkod5v-ri879.png "/>

The permission set has no intersection, and there are no common elements. Therefore, the user will be denied access to this interface. So far, we've covered the simple principle of resource authorization.

     

      650) this.width=650; "Src=" http://s5.51cto.com/wyfs02/M02/8A/5A/ Wkiom1guthigtqulaaddbse0ntw930.png "title=" 3decc083-ce44-38a0-aadb-0f33217228fb.png "alt=" Wkiom1guthigtqulaaddbse0ntw930.png "/>         We can see that there is a component called Access Decision Manager (Access Decision manager) that determines whether a security entity has the appropriate access rights and determines the matching of the permissions that are based on the security entity with the resources required by the requested resource.

The process of determining whether access is allowed by a secure access controller can be as simple as looking at the intersection of the set of permissions that a security entity has and the set of resources required by the resource being accessed.

The above article comes from the web about Spring Security3 translations.

This article is from the "attack on the Program Ape" blog, please be sure to keep this source http://zangyanan.blog.51cto.com/11610700/1874108

Follow me learn spring security--online Pet Shop development (i)