Licensed by Apache Shiro

Chapter 2 Apache Shiro Authorization

1. Understand authorization

Authorization, that is, access control, in the application, is used to control the access rights of various roles to resources, etc. In authorization, there are several key objects, subject (Subject), resource (Resuorce), permission (Permission), role (Role)

Subject: The visitor, any visitor of the application, not just a person, but also a crawler.

Resource: In the application, anything that the subject can access, such as a page, a business method, some data, etc.

Permission: The yard authorization unit in the security policy. Through the permission, we can indicate that in the application, the subject does not have the right to operate a certain resource, such as: add, delete, modify and check. Apache Shiro supports coarse-grained permissions (such as all permissions of user modules) and fine -grained permissions. Granular permissions (permission to operate a user, that is, instance-level)

Role: A role represents a set of operations, which can be understood as a set of permissions. Generally, a role is granted to a user, that is, a set of permissions.

2. Authorization method

programmatically

Subject subject = SecurityUtils.getSubject();  
if(subject.hasRole(“admin”)) {  
    //Have permission  
} else {  
    //No permission  
}   

Annotated way

@RequiresRoles("admin")  
public void hello() {  
    //Have permission  
}   

label method

<shiro:hasRole name="admin">  
<!—authorized—>  
</shiro:hasRole>   

3. Authorization

Role-Based Access Control (Implicit Roles)

[users]
chen=123,role1,role2
he=123,role3
[roles]
role1=user:create,user:update
role2=user:select
role3=user:delete

Test code (test whether the user has a role)

@Test(expected = UnauthorizedException.class)
    public void testHasRole() {
        //User login
        Subject subject = login("classpath:shiro-capter3.ini", "chen", "123");
        //User chen, has role role1
        Assert.assertTrue(subject.hasRole("role1"));
        //User chen, no role role2
        Assert.assertFalse(subject.hasRole("noRole"));
        //Check whether the user has the permission in the list, if not, an UnauthorizedException will be thrown
        subject.checkRoles("role1","role2","role3");

Test whether a user has a permission

@Test(expected = UnauthorizedException.class)
    public void testHashRight(){
        Subject subject = login("classpath:shiro-capter3.ini", "chen", "123");
        //Assert that the user has user:create permission
        Assert.assertTrue(subject.isPermitted("user:create"));
        //Assert the user does not have user:delete
        Assert.assertFalse(subject.isPermitted("user:delete"));
        //If a permission does not exist, an UnauthorizedException will be thrown
        subject.checkPermissions("user:create","user:select","user:delete");
    }

ini configuration file wildcard writing method

Single resource, single permission role1=user:create,update
A single resource, all permissions role=user:*
All resources, single permission role = *:create
Single instance, single permission role=user:create:1 #1 instance of user, with create permission
Single instance, multiple permissions role=user:create,update:1
Single instance, all permissions role=user:*:1
All instances, single permission role=use:create:*
All instances, all permissions role=user:*:*

Authorization process

1. First call the Subject.isPermitted("") interface, which will delegate the SecurityManager, and the SecurityManager will then delegate to the Authorizer
2. Authorizer is the real authorizer. If we call isPermitted("user:create"), it will first convert the string into the corresponding Permission instance through PermissionResolver;
3. Before authorization, it will call the corresponding Realm to obtain the corresponding role/permission of the Subject for matching the incoming role/permission;
4. The Authirizer will judge whether the role/authority of the Realm matches the incoming one, and the match returns true, otherwise it returns false. Note: If there are multiple Realm, it will be delegated to ModularRealmAuthorizer for cyclic matching;

ModularRealmAuthorizer performs multiple Realm matching process:

1. First check if the corresponding Realm implements Authorizer;
2. If Authorizer is implemented, then call its corresponding isPermitted/hasRole interface to match
3. Returns true if a Realm matches, false otherwise

If Realm is authorized, it should inherit AuthorizingRealm

Authorizer,PermissionResolver,RolePermissionResolver

Authorizer The responsibility is to authorize, which provides the corresponding role permission judgment interface.