This is the fifth day of my participation in Gwen Challenge

background

At present, the back-end architecture is very popular. The back-end focuses on providing REST API interfaces to the front end, which is also very important for interface authentication.

Currently, Shiro and Spring Security are the mainstream authorization frameworks in the market, but they both have flaws. For example, Shiro does not support RESTful natively, and Spring Security is deeply bound to Spring, making it difficult to get started.

Sureness framework solves the above problems by providing a REST ORIENTED API, no framework dependency, dynamic permission modification, multiple authentication policies, faster, easy to use and extensible authentication framework.

A comparison of the various permissions frameworks from sureness:

~ Sureness Shiro Spring Security
Multi-framework support support Change support Does not support
REST API support Change support support
Websocket support Does not support Does not support
Filter chain matching Optimized dictionary matching tree Ant matching Ant matching
Annotation support support support support
Servlet support support support
JAX-RS support Does not support Does not support
Dynamic Permission Change support Change support Change support
Performance speed faster The slower The slower
The learning curve simple simple steep

Resources agreed

A resource is the smallest unit of granularity that a user can access.

In a separate architecture, the backend provides a set of APIS to the front end, consisting of resource names + request methods.

For example, for the user module, / API /user’s GET request means to acquire the user, while/API /user’s POST request means to create the user. A single URL cannot specifically reflect the business, and must be combined with a verb.

So Sureness is very innovative in adding resources to verbs (get,post,put,delete…) Form a whole as a resource for authentication.

For example, the above user acquisition can be represented as/API /user=== GET according to sureness rules, and the creation of a user can be represented as/API /user===post.

RBAC model

RBAC role-based Access Control (RBAC) is one of the most common permission management techniques in commercial systems.

In RBAC, permissions are associated with roles, and users gain permissions for those roles by becoming members of the appropriate roles, which greatly simplifies permission management.

In an organization, roles are created to perform various tasks, and users are assigned roles based on their responsibilities and qualifications. Users can be easily assigned from one role to another. Roles can be assigned new permissions based on new requirements and system consolidation, and permissions can be reclaimed from a role as required.

The most classic database implementation of RBAC is the five-table design, which consists of three real tables (users, roles, and permissions) plus two relational tables (user-role, role-permissions, both many-to-many relationships).

Sureness authentication and authorization

Authorization frameworks typically address two issues: authentication and authorization.

Authentication verifies whether a user has a corresponding identity.

Authorization verifies whether an authenticated user has a certain permission. Check whether a user can do something, for example, check whether a user has a role. Or fine-grained verification of whether a user has permissions on a resource.

The Sureness framework supports some simple login authentication methods, such as Basic Auth, JWT, etc. Authorization is also implemented using the ideas of RBAC.

To see what Sureness can do, see the official hand-held tutorial example.

In this tutorial, there is not much customization, but more simulation of authentication and authorization through file configuration.

The configuration file is:

## -- sureness.yml text source -- ##

The resources loaded into the matching dictionary, that is, those that need to be protected, set the resources to be accessed by the supported role
/ API /v1/source2===get
# eg: / API /v1/source1===get===[role2] indicates that/API /v1/source1===get supports role2
# eg: / API /v2/source2===get===[] indicates that/API /v2/source2===get does not support access by any role
resourceRole:
  - /api/v1/source1===get===[role2]
  - /api/v1/source1===delete===[role3]
  - /api/v1/source1===put===[role1,role2]
  - /api/v2/source2===get===[]
  - /api/v1/source2/*/*===get===[role2]
  - /api/v2/source3/*===get===[role2]

# Access resources that need to be filtered without authentication
/ API /v1/source3===get indicates that/API /v1/source3===get can be accessed by anyone without login authentication
excludedResource:
  - /api/v1/account/auth===post
  - /api/v1/source3===get
  - /**/*.html===get
  - /**/*.js===get
  - /**/*.css===get
  - /**/*.ico===get

# User account information
# admin/root/Tom
# eg: admin have [role1, role2] role, clear text password for admin, password is 0192023 a7bbd73250516f069df18b500 with salt
# eg: root has [role1] and the password is plain text 23456
# eg: Tom has [role3] and the password is plaintext 32113
account:
  - appId: admin
    Credential MD5(password+salt) MD5(password+salt
    # no salt considers unencrypted,credential as plaintext
    If salt is added to the password, the digest authentication is not supported
    credential: 0192023A7BBD73250516F069DF18B500
    salt: 123
    role: [role1.role2]
  - appId: root
    credential: 23456
    role: [role1]
  - appId: tom
    credential: 32113
    role: [role3]
Copy the code

In addition to configuration files, Sureness also supports custom data sources that persist all role and resource information into the database.

In addition, Sureness has a number of extension points, such as custom user objects, custom authentication methods, and more, which I will cover in a later article.

Java Permissions Framework series of articles

Java Authority Framework 1 — Business Pain Points and Technology Research

The resources

RESTful API Best Practices

Understanding RESTful Architecture

Sureness Official Documentation