By Tessa Holland 9 January 2020 Techies
An overview of how security works in SpringBot
The security of SpringBot is a combination of Spring Security and client-side route guards. All data is protected server-side through a strict implementation of role based access control.
All security related configuration files can be found in
Each entity with the User Behaviour has a registration endpoint created for them that takes the form of
auth/account/register/<userType> where the
userType is the camel case form of the entity name in question.
Hibernate Envers is used to ensure that all CRUD (Create, Read, Update, Delete) operations are recorded in an audit log. Each entity in the database also has two associated audit tables that records all the previously mentioned operations.
The audit tables come in the form of,
<snake_case_entity_name>_audit_log- stores all Created, Update and Delete operations.
<snake_case_entity_name>_read_audit- stores all read requests.
This audit data is also partially accessible through the History feature that is available as part of the CRUD tile.
Key files that are used to configure the audit logs are found in
serverside/src/main/java/<projectName>/entities/<entityName>Audit.java - These allow the audit log for individual entities to be customised or otherwise adjusted.
Authentication is achieved using JSON web tokens (JWT). These tokens are created using a secret that can be found in
src/main/resources/application-default.properties under the
security.jwt-secret property. These tokens are returned and expected as bearer tokens.
By default, tokens have a an expiry of 1 hour.
More detail can be found in
Roles and access are configured and set within the Security Diagram. What this means is that while the application itself does not enforce the least privilege approach, if care is taken when configuring your security diagram, your application can be setup in such a way that it does.
While the roles a user has can be cumulative, they cannot currently be setup in this way.