Access to various pages or screens of a web application is usually controlled using roles and permissions, regardless of MVC technology.

Role

A Role controls access to a large module of functionality.

A user can have one or more roles that can be assigned to them, normally in LDAP by the security team.  An example of a role could be ROLE_TIMESHEET_INVOICE which is the ability to access invoices in the Timesheet application, or ROLE_TIMESHEET_ADMIN which is the ability to administer the Timesheet application.  It's usually assigning access to a particular module within the app.

Permission

A Permission gives more restricted access within a large module of functionality.

Within a role there can be permissions which give more specific access control to a user.  For example, just because a user has access to invoices, doesn't mean they can make changes to them. They might have PERMISSION_INVOICE_VIEW and PERMISSION_INVOICE_SEARCH access but not PERMISSION_INVOICE_EDIT.  They can't make changes.

The most fine-grained permission approach allows very specific access controls for each user, defining a permission for every action button on every screen, and another for access to the screen itself.  This is rarely used but can be valid for complex sites.

Permissions too a generally configured in LDAP.

Access Controls on Data (Data Privacy)  

Although a user has access to the application, they should not usually have access to other peoples' data.  So after the checks for Role and Permissions have been applied, there is a third Privacy check which is “is the user allowed to see the data they have requested?”.  For example, a user might only be allowed to see the Invoices for the sales jobs they were directly involved in.  Or, they might only be allowed to change their own Invoices.

It's a good idea to manage data privacy in one place in the code such as a SecurityService, which can be queried to check if a user has permission to do what they have asked to do.

blog comments powered by Disqus