If we consider a website that presents information from a database:
- The process that handles the request HTTP will not run as a user with admin rights
- The connection to the database will not involve a user with write access to the data
If the information is not intended to be freely available then access can be restricted to logged in users. If there is more than one level of access restriction then the users can be assigned to roles and the information can be restricted with role-based access control (RBAC).
Role-based access control in a web-based application typically involves specifying URL patterns and roles which should have access to any URLs matching the patterns. When a request arrives, if there are authentication credentials supplied which match with a specified role then the server will process it and produce a response.
Two common ways to define the pairing between URL patterns and roles are XML and annotations but sometimes making a code or configuration change on the server is too much hassle for the day to day administrators.
In the case of Spring Security, you can set up your own whitelisting by specifying your own AccessDecisionManager with a custom AccessDecisionVoter to allow a secondary check of permission.
Your own AccessDecisionMaker can lookup urls in a database, so there is no need to modify any code or configuration file within the deployed application.
Two common ways to define the pairing between URL patterns and roles are XML and annotations but sometimes making a code or configuration change on the server is too much hassle for the day to day administrators.
In the case of Spring Security, you can set up your own whitelisting by specifying your own AccessDecisionManager with a custom AccessDecisionVoter to allow a secondary check of permission.
Your own AccessDecisionMaker can lookup urls in a database, so there is no need to modify any code or configuration file within the deployed application.
