A total of five tables
- user table
- Roles table
- Permissions table
- User Roles middle of the table
- Role Permissions middle of the table
ASD
- Through role to determine there is no authority. For example, if users have the role of manager in the user role in the middle of the table, you can view wages. It is judged more general. For example to achieve a different role after logging see a different menu.
- Be judged by the authority identified the need to identify specific permissions they have. The more detailed access control.
For detailed, such as parts of the company's administrators, employees can only modify data in the sector.
Shiro point
- Subject: subject, represents the current "user
- SecurityManager: security manager; that is, all safety-related operations will interact with the SecurityManager; and it manages all Subject; we can see it is the core of Shiro
- Realm: domain, Shiro from acquiring security data from Realm (such as users, roles, permissions)
- Shiro a simple application:
1, the application code to perform authentication and authorization by Subject, and Subject commissioned to SecurityManager;
2, we need to Shiro of SecurityManager injection Realm, so that SecurityManager to get legitimate users and their privileges to judge.
Shiro authorization process
-
1, the first call Subject.isPermitted Interface
-
2 call the appropriate Realm Get themes appropriate roles / permissions;
-
3, Authorizer will determine the role of Realm / authority whether incoming match and, if there are multiple Realm, will be entrusted to ModularRealmAuthorizer cycle to determine if a match as isPermitted returns true, false otherwise express authorization failure.