Written in the beginning

It’s been two years since I read the last article in this column. Time has flown by. Should be out of school time soon. After using Shiro two years ago, I started to build a authentication authentication framework – Sureness according to my idea. I think it is aimed at RESTful API, it is easy to use, and it has no framework binding. I wrote these ideas on and off for two years, in the middle of which I released 10 versions in the Maven repository, verifying the online environment. Start writing in this column and hope someone pays attention and uses Sureness – https://su.usthe.com

Sureness – Authentication authentication for RESTful APIs

A simple and efficient open-source jvm security framework that focus on the protection of restful api.

If the home pageusthe.com/surenessUnable to access, please use alternate website:su.usthe.com

Background

Many websites now have a front-end separation where the back-end provides the REST API and the front-end calls the interface for data rendering. Protecting the REST API provided by the back end in this architecture brings more attention. API protection can be considered as: authentication – whether the authentication information carried by the request has been verified, authentication – the user who has passed the authentication has the authority of the specified API to access this API. However, not only in this, what kind of authentication strategy, JWT, BASIC, Digest, OAuth or more support, permission configuration is written dead code or dynamic configuration, I want to dynamic empowerment how to do, cloud native more and more popular framework is Quarkus and other rookies not Spring ecology how to do, To be or not to be, this is a question.

At present
javaThe mainstream permission frameworks are
Shiro, spring securityThe following discussion of them is personal and subject to correction


shirofor
restful apiNative support is not very friendly and requires some code rewriting for a project 2 years ago
booshiroIs modified
shiro, so that it can match different in the filter chain
restRequest permission check, then give
shiro commitA few times
pr.
fixIts dangerous holes in the filter chain match, in general
shiroIt’s powerful but its origins are not oriented
webfor
restfulNot very friendly


spring securityVery powerful, with
springDeep integration, away
spring, such as
javalinAnd the one we used before
osgiThe framework
karafIt won’t work


If you don’t configure them with annotations, they all match in the chain, one by one, with the requested URL and the configured chain
antMatching (there will be caching in the matching process to improve performance), but it still consumes performance when there are too many matching chains (judging by the time complexity of the algorithm, it has not been tested and verified yet)


We want to be able to address that and provide one
In view of the restful API.
Frameless dependency, you can
Dynamic modification permission.
Multiple authentication policy.
Faster speed.
Easy to useThe authentication authentication framework of

Introduction

surenessWe use it
javaPermissions framework
shiroAfter that, learn its good design and some ideas to achieve a new certification certification project


In the face of
restful apiBased on
rbac(User-Role-Resources) focuses on the
restful apiThe safety protection of


No specific frame dependence (essence filter interception, existing springboot, quarkus, javalin, ktor demo etc.)


Support for dynamic modification of permission configuration (dynamically modify which APIs need to be authenticated and who can access them)


Support for major HTTP container servlets and JAX-RS


Support for multiple authentication policies,
jwt, basic auth. Extensible custom supported authentication methods


High performance based on improved dictionary matching tree


Good extension interface, demo and documentation


surenessLow configuration, extensibility, and decoupling from other frameworks enable developers to quickly and securely protect multiple scenarios of their projects

Framework Sample Support
  • spring sample-bootstrap
  • springboot sample-tom
  • quarkus sample-quarkus
  • javalin sample-javalin
  • ktor sample-ktor
  • spring webflux sample-spring-webflux
  • more samples todo

Quick start

Use the previous conventions
  • surenessAs simple as possible, based onrbac, there is only (role-resource) mapping, there is no (permission) action mapping, that is, user-role-resource
  • We will berestful apiThe request is treated as a resource in the format of:requestUri===httpMethodThat is, the path of the request plus how it was requested (post,get,put,delete...) as a whole is viewed as a resourceeg: /api/v2/book===get getWay to request/api/v2/bookThe interface data
  • Role resource mapping: the role the user belongs to — the role owns the resource — the user owns the resource (the user has access to this)api)
Add sureness to the project
  1. Projects usingmavenBuild, addmavencoordinates
< the dependency > < groupId > com. Usthe. Sureness < / groupId > < artifactId > sureness - core < / artifactId > < version > 0.1 < / version > </dependency>
  1. Projects usinggradleBuild,gradlecoordinates
Compile Group: 'com.usthe. Sureness ', name: 'sureness-core', version: '0.1'
  1. Project for general engineering, joinsureness-core.jarRely on
In mvnrepository download jar at https://mvnrepository.com/artifact/com.usthe.sureness/sureness-core
Add filter entry that intercepts all requests

The filter that intercepts all requests is the sureness security filter that is provided by the Spring Interceptor.

SurenessSecurityManager.getInstance().checkIn(servletRequest)
Implement relevant exception handling

Sureness uses the exception handling flow. We need to do custom handling of the exception thrown by checkIn, security filter, pass the authentication directly on success, throw a specific exception on failure, and catch the exception, as follows:

try { SubjectSum subject = SurenessSecurityManager.getInstance().checkIn(servletRequest); } the catch (ProcessorNotFoundException | UnknownAccountException | UnsupportedSubjectException e4) {/ / account creation related to abnormal} the catch (DisabledAccountException | ExcessiveAttemptsException e2) {/ / account disabled related to abnormal} the catch (IncorrectCredentialsException | ExpiredCredentialsException e3) {/ / authentication failure related to abnormal} the catch (UnauthorizedException e5) {/ / authentication failure related to abnormal} the catch (RuntimeException E) {// Other custom exceptions}
Load configuration data

Sureness authentication, of course, requires us to configure our own configuration data — account data, role permissions data, etc. This configuration data may come from text, relational databases, For non-relational databases we provide the configuration data interface surenessAccountProvider, PathTreeProvider, Users can implement this interface implementation custom configuration data source We also provide current default text form of realizing DocumentResourceDefaultProvider configuration data, The user can configure sureness.yml to configure the default text data source for the data. The sureness.yml configuration is detailed in the document Default Data Source. For the specific implementation of the default text data source, please refer to sureness-10 minutes to set up the permission project –sample-bootstrap. If the permission configuration data is from the database, please refer to sureness-30 minutes to set up the permission project –sample-tom

HAVE FUN

Welcome to participate in the project and contribute to help Sureness go further and better. If you have any questions or suggestions about the project code, please contact @tomsun28