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
java
The mainstream permission frameworks are
Shiro, spring security
The following discussion of them is personal and subject to correction
shiro
for
restful api
Native 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
rest
Request permission check, then give
shiro commit
A few times
pr
.
fix
Its dangerous holes in the filter chain match, in general
shiro
It’s powerful but its origins are not oriented
web
for
restful
Not very friendly
spring security
Very powerful, with
spring
Deep integration, away
spring
, such as
javalin
And the one we used before
osgi
The framework
karaf
It 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
ant
Matching (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
sureness
We use it
java
Permissions framework
shiro
After that, learn its good design and some ideas to achieve a new certification certification project
In the face of
restful api
Based on
rbac
(User-Role-Resources) focuses on the
restful api
The 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
sureness
Low 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
sureness
As simple as possible, based onrbac
, there is only (role-resource) mapping, there is no (permission) action mapping, that is, user-role-resource- We will be
restful api
The request is treated as a resource in the format of:requestUri===httpMethod
That 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
get
Way to request/api/v2/book
The 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
- Projects using
maven
Build, addmaven
coordinates
< the dependency > < groupId > com. Usthe. Sureness < / groupId > < artifactId > sureness - core < / artifactId > < version > 0.1 < / version > </dependency>
- Projects using
gradle
Build,gradle
coordinates
Compile Group: 'com.usthe. Sureness ', name: 'sureness-core', version: '0.1'
- Project for general engineering, join
sureness-core.jar
Rely 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