-
Notifications
You must be signed in to change notification settings - Fork 0
dft street manager odp 0018 authorisation
Street Manager will contain data for each statutory undertaker and each Local Highways Authority in England. Therefore, it will need some enforcement of authorisation policy. This ODP discusses the form of authorisation policies required for the various parties involved, and options for implementing the decision and enforcement of these policies.
This ODP does not address workflow: the division of labour for efficiency. "Must only deal with customer names beginning A-D" is very different from "I am working on names beginning A-D (today), while Fred works on E-M" or "I will step A, while Mary does step B".
Street Manager will be a kind of multi-tenant system, so we start with policies that apply to organisations, and move on to policies that apply to individuals.
Promoters and authorities are responsible for the integrity of their own data. No other organisations need to have write access other than the organsiations and their subcontractors.
The purpose of Street Manager is collaboration between promoters and authorities, so most data will be readable by both the promoter and an authority involved in that case. However, there will be some draft information that should be private.
There are other forms of legitimate read access:
- Promoters will share future plans of the time and location of works, so that they co-ordinate works possibly sharing lane or road closures.
- Authorities will inform promoters of works already agreed that impact their own requests to work.
- Authorities will co-ordinate with neighbouring authorities about nearby traffic impacts.
These policies are business rules specific to the service and are best addressed through application code.
Users within organisations or their subcontractors are trusted in varying ways by those organisations, and so organisations want to control access to what users and see and do in their information systems.
Here, we consider direct use of the Street Manager UI.
Where the user is using another tool that then calls Street Manager, we assume that the organisation will apply trust limitations in that first tool. In that case, SM does not need to decide or enforce user-level authentiction policies.
There is no one model of division of trust that suits all organisations, or even all local authorities. In practice, therefore, we have to look at providing a tool-kit for setting access policies, which is expressive enough to be acceptable to organisations.
It is conventional to think of authorisation policy as a matrix where columns are subjects, rows are objects and the entries are the actions allowed for that subject over that object.
We reviewed the most common ways of modelling authorisation policies in term of the access control matrix.
Low-level actions are grouped into "roles" and roles are granted to users. The user can do any action in any of their roles, uniformly over all objects. This is no more expressive than granting permissions individually, but is more manageable.
Granting rights is itself an action controlled by policy. Models differ in how fine-grained is their control of this.
Simple models use fixed roles. More complex models offer the ability to create roles from primitive permissions.
In a multi-tenant setting, this model can be applied within users and objects owned by an organisation (tenant).
This model is suitable for moderate-sized communities of users who work for the same organisation. Because users have uniform rights over objects it is not suitable for most subcontracting situations.
Access control list are familiar from file systems. Each object has an access control list that is a row of the access control matrix.
There is a permission called ownership. Owners have complete rights and complete control over the rights they grant to other users over the objects they own.
Two grouping mechanisms make this basic scheme more manageable. Objects are grouped into directories or folders whose contained objects inherit the access control policy of the container by default. Users are grouped into groups, and groups may be granted permissions in the ACLs of objects including folders.
Additionally, permissions can be grouped into roles as in simple RBAC.
This model is very flexible, but perhaps too complicated for many users to use effectively. Also, they may be unsuitable for long-running processes where people may leave or be dismissed, leaving no permissions for anybody else.
Capabilities are permissions on objects, and can be thought of as columns of the access control matrix.
The right to grant capabilities is itself a capability. Some capability models are very sophisticated in this regard, and more dynamically flexible than access control lists.
Objects and users can be grouped as in access control lists, and roles can be used to group permissions.
Capability schemes are often used between components of distributed systems, but rarely by end users, since they can be very hard to understand.
Composite model:
- At top level, apply restrictions between organisations. For example, future plans will be visible to other promoters but inspections will be visible only to the promoter and the authority.
- Within each organisation, offer simple RBAC. The admin role initially conferred on the lead user for each organisation will be able to confer roles, including admin, on users within their own organisation. These roles will grant rights to view and update objects associated with that organisation.
- Research the need for configurable RBAC. This would extend the simple model by allowing those with admin role to create roles from underlying permissions, for use within their own organisation.
- So long as Street Manager remains, we do not recommend ACLs or other object-level controls beyond the organisation-level controls described above.
Implementation comprises decision and enforcement. Decision differs from "just another business rule" in that its implementation is an important attack target. So it is often implemented in a trusted kernel that is harder to attack than most business rule implementations. Similarly, enforcement must address possible attempts to circumvent the decision logic.
Given the ID of their user (or caller) and given access to access control information such as role membership, which is often carried in a token from a directory, a service can implement decision and enforcement for itself. Much of the logic will be common to all service requests, so there is an opportunity for shared libraries. (Moreover, developers must be disciplined not to couple authorisation logic with unrelated aspects of business logic.) But finally, the implementation of authorisation policy is just as written with the same discipline as other kinds of business logic and so is roughly as vulnerable to attack.
Most application service frameworks offer an implementation of simple RBAC that is decoupled from bespoke service logic. It is also widely used and (one hopes) thoroughly tested. But they run in the same execution unit as the service logic itself, and so it is hard to argue that they are much less vulnerable to attack than custom authorisation logic.
Most API gateways can implement simple RBAC models. Owing to the techniques used to engineer them and their widespread use, it can be argued they are part of the "trusted kernel" and are less vulnerable to attack than the services they protect.
Reverse proxies may not implement RBAC by themselves, but allow developers to write plug-ins. Again, it is possible to argue that these implementations are less vulnerable to attack than code running in normal application services.
Access decision can be written as a separate service. This is called by whatever does enforcement, typically the called service itself, or a proxy. The access decision service can be written in general purpose languages, so any kind of policy can be implemented. Provided this service is written with more rigorous techniques and/or different tools from the other business logic in the solution, it is possible to make a "trusted kernel" argument that it reduces vulnerability.
A directory is a service that maintains user authentication credentials, plus attributes about the user. These details can often include role and group memberships. Directory services are often integrated with session token generation, so that session tokens can contain role memberships for that user. (Or in some cases, tokens are opaque but can be used to look up memberships.) A directory service can thus provide information that can be used in access decisions, but by itself it is not a complete solution for access decision, and cannot do access enforcement.
Enterprise DBMS support ACLs at table or even row level. To exploit this, you need to pass the ID of the user or caller all the way down to the DBMS. In most cases, this prevents DB connections from being (fully) pooled, which in turn impedes scalability and performance. Moreover, it creates a tension for the physical schema: modelling data in a way that allows ACLs to represent the authorisation policy you want, versus modelling for efficient access.
In practice, DB-level access control is almost never used by itself, but more often used as a back-stop enforcement of simple (coarse-grain) policies, in case controls further up the stack fail.
Recommendation predicated on using Authentication-as-a-Service, such as AWS Cognito, and a reverse proxy such as ngingx managed by Kubernetes.
- Manage user attributes in Directory, include organisation membership (single) and role membership.
- Between Authentication Service and Reverse Proxy, arrange for user ID, organisation and role to be in the HTTP header.
- Use logic inside individual services to decide and enforce access.