A colleague is covering for someone on holiday. Which cases may she view and work on? And when does that access end?
For me, questions like these show whether an approach to access permissions makes sense in everyday work.
Which task needs which access
Consider a hypothetical application for handling customer enquiries in public transport. One team receives and processes the enquiries. Another transport operator is involved when specialist input is needed. The team leader needs an overview of open cases.
Everyone is working on the same process. That does not mean everyone needs the same information and functions. Selected details from an assigned case may be enough to provide specialist input. An overview of the workload does not automatically require access to all personal details.
An access control model describes which access is permitted. A role such as “case handler” groups certain permissions together. That role only becomes understandable when it is clear which task it supports, which cases it covers and whether the person may view, edit or approve them.
A role alone therefore does not explain every access decision. When several organisations work together, for example, they also need to agree which assigned cases the permissions apply to. These boundaries belong in the application’s functional design.
Temporary cover needs an end date
Holiday cover illustrates why permissions need attention throughout day-to-day operation. The colleague must be able to perform the tasks she is covering. That means establishing which additional access she needs, who approves it and how long it should last.
Such access should have a clear justification, be limited in time and be revoked when that period ends. Both organisational procedures and technical controls need to ensure this happens reliably. A change of duties also calls for a review of existing permissions: do they still fit the new task?
Granted permissions should also be reviewed regularly. A clear description of each task helps people assess whether access is still necessary.
Agreeing how to support work while limiting access
Permissions that are too restrictive can obstruct case handling. Permissions that are too broad allow more access than the task requires. For me, this trade-off belongs in a conversation between the business team, development and operations.
The business team can explain which information and actions a workflow requires. Development needs to account for the agreed boundaries in the application design. During operation, there must be clear responsibilities for approving, implementing and reviewing permissions.
The specific task remains the basis for the decision. A restriction that makes necessary cover impossible needs to be discussed, as does access to cases unrelated to that cover.
The application must enforce the rules
An understandable access control model needs to be implemented technically. Hiding a button alone does not protect the function behind it. For every access request, the application must check whether the relevant action on the specific data is permitted.
For example, permission to work on an assigned case does not mean that a person may also open or edit every other case. The checks must reflect the agreed boundaries.
Access decisions need an explanation
My expectation is that the people involved can explain why access is necessary and where its limits lie. That turns a role name into a decision that makes sense in everyday work.
This supports usability and secure operation. An understandable access control model alone does not, however, guarantee a secure application. Effective technical implementation and ongoing maintenance of the permissions granted are also needed.
How do you make sure that temporary access ends when cover is no longer needed?
Technical background: OWASP Authorization Cheat Sheet on limiting permissions, reviewing them regularly and checking access requests.