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.
