Stephen Whitley (Schlumberger)| Sponsors | Core Team | Supported by |
|---|---|---|
| Johan Krebbers - Shell Stephen Whitley - Schlumberger |
Paco Hope - AWS/Shell Hrvoje Markovic - Schlumberger Kerry Blinston |
Ferris Argyle - Google Joe Nieten - AWS Dania Kodeih - MSFT |
Purpose
This topic focuses on the authorization mechanisms involved in granting access to data:
- Policies: Contextual grants of permission (often legal: contractual, residency, trade compliance) hese are captured in Entitlements User Stories
- Access Control: Explicit grants of permissions
- Identity: Consider related questions around Authentication
Scale of Problem
- For a single, large multi-national enterprise scale company
- Duration: 10's of years
- Users: 10,000's of users working within potentially 1,000's of organizational scopes
- Content: 100's of millions of business objects with new types being introduced in a continuous basis.
Approach
We will look at different approached and evaluating them using Trade-off Analysis.
Trade-off Points
- Granularity of authorization
- The end-user perspective (what the user wants)
- The system perspective (what the system inherently provides)
- Basic security concerns
- Does it require services with elevated privileges?
- Water-tightness of approach - how easy is it to circumvent?
- Does it satisfy common security requirements around basic operations like CRUD
- Performance
- How long to decide a given access request?
- Time it takes for a policy or an access control change to propagate through the system
- Scalability to thousands of users, thousands of groups, trillions of objects, thousands of policies
- Scalability/synchronizability across multiple installations in disparate geographic regions
- Usability
- Ability to manage permissions at scale
- Ability to understand / audit who actually has access under what conditions
- User-friendliness of the approach
- Susceptibility to user errors
- Technical feasibility and maintainability
- Can it be implemented
- Is it portable across cloud providers
- Is it portable across technologies
- Does it follow a known/existing standard?
- Are these existing technical solutions that we can leverage?
- How much leverages cloud native, established frameworks versus how much is purpose built by OSDU?
- Cost of Change
- Impact of migrating existing data currently in deployed instances
- Likelihood that approach would lead to future migrations of data
- Likelihood that the approach can be amended / adjusted without provoking substantial change in the future.
- Correctness
- Likelihood that the entitlement decision is "correct" at the moment it is made
- Ability to describe and enforce the majority of all business, legal, and regulatory requirements. Easy things are easy, exceptional things look exceptional.
First Step
The core team met during the week of Oct 21st to work through the above from the perspective of an OSDU data platform. Once mature enough to discuss, CSPs are helping to drill down into technical feasibility and portability.
Considered approaches
There are two broad classes of entitlements: precalculated and dynamically evaluated.
Precalculated entitlements are fast to evaluate and require the least context. A good example of a precalculated entitlement is assigning a role to an object and then matching a user's membership in that role. The attachment of the role to the object and the assignment of the user to the role happen in advance of determining access. So at the time of access, a simple matching process can determine with almost 100% accuracy, in more-or-less constant time whether the access should be granted or not. Speed and accuracy are the obvious advantages. The primary disadvantage is that the mechanism for determining who belongs in which group and why is left as an exercise for the operator. It is not obvious how an operator translates its needs for policy, compliance, business roles, or need-to-know into a set of roles/groups. The tools for organising users / groups / roles, etc. live outside OSDU.
Dynamic evaluations encode the rights of users in descriptive policies or rules. At the time of access, the relevant set of rules is determined and evaluated. This requires translating the operator's requirements for policy, compliance, business roles, need-to-know, etc. into a machine-readable policy language/set of rules. The primary advantage is the flexibility to describe access controls generally, even in advance of data loading. E.g., data with attribute X cannot be read by users with attribute Y. The primary disadvantage is that the more flexibility that is possible in the rules, the slower the system is likely to perform. The tools for writing rules that implement operators' needs will be inside OSDU, but such tools have to be created for OSDU.
The three proposals below generally differ by how much of these two approaches are used. To more deeply understand these three approaches, look at three worked entitlement examples.
Policies and ACLs
Many systems separate design and implementation between contextual grants and explicit access permissions. There are multiple reasons for this and they include: historical (requirements for contextual grants come later), different risk exposure, different performance vs freshness trade-offs, incompatible use cases, etc.
The policy/ACL approach is a hybrid approach applying precalculated access control assignments (e.g. owner, rights, permissions) with dynamically-calculated policy entitlements. Access decisions that can be decided purely by precalculated rights are decided that way. This means that in some situations, only ACLs are considered, whereas in other situations policy/compliance requirements and ACLs are considered.
Depending on the requirements, contextual grants can require dynamic rule evaluation or be implemented as separate consumption zones/patterns. There are different ways to determine whether policy/requirement rules are evaluated. It can be per service/API. E.g., calling service X, API Y requires policy evaluation, but calling service X API Z will succeed/fail based only on ACLs. Another mechanism is through consumption zones/patterns. E.g., when exporting the data to certain environments, (e.g., non-OSDU environments) policy evaluations might need to occur. Whereas exporting data to other environments (where OSDU entitlements are actively enforced) perhaps only ACLs are checked.
Everything as policy
With everything as policy all access decisions are dynamically evaluated. No distinction is made between contextual policies and the ones where the context is not important. Context is always considered in every access request. A uniform set of rules is evaluated at each time of access.
In this way policies can be implemented independent of specific data or specific users. The access control policies can resemble the original license terms, regulatory rules, or organizational policies that the operator adheres to.
Constrained policies
The constrained policy approach attempts to define a generic entitlements model that can express grants in form of rules, but make it usable in a big data space by limiting the impact on performance and cost. In this approach, rules are fundamentally dynamic, but the expressiveness of the rules / patterns / language for defining policies is constrained to a very small set. The goal is to achieve many of the benefits dynamic entitlement while limiting complexity. The limited complexity should allow a more performant system implementation.
Possible constraints:
- Whereas the everything-as-policy approach would regulate every service and every API one possible simplification would be to only entitle the service level. E.g., users can have all APIs on a service or none. Or, more likely, any regulation of what a user can do inside a service is left to the service itself to implement. This simplifies and speeds up the policy engine evaluation by pushing complex evaluations to individual OSDU services.
- Limited operations: define simply 3 levels of entitlement for all services: read, write, owner. Force all services to align their activities along these levels. Another similar set of operations would be CRUD. Force all OSDU services to entitle along those 4 operations.
- Lack of wildcards / patterns: some of the most time-consuming operations are string operations matching against patterns liks
*@example.comorurn:foo:bar:baz/*. One way to constrain policy would be to forbid patterns and force enumeration of exact user and resource names.
Trade-off Analysis
Note: The ranking of each solution with respect to the trade-offs is a straw-man position and the trade-off points themselves have not yet been ranked in terms of impact/value/priority. However, the framework itself will be useful in driving the conversation towards a decision.
| Sensitivity | Policies and ACLs | Rank | Everything as Policy | Rank | Constrained Policies | Rank |
|---|---|---|---|---|---|---|
| Granularity | ACLs and Policies have different granularities. App designers / operators must make choices about which applies to the data. | 2 | Granularity is proportional to number of policies. Fine-grained access requires higher number of policies. Coarse access can be implemented with a few broad policies. | 1 | Constraints on policy expressiveness probably limits the granularity of policies. | 3 |
| Basic security concerns | Dual approach can be seen as a defence-in-depth approach, where one layer serves as a backstop for the other. There can be gaps between ACLs and policies that are not obvious: situations where access is granted or prevented and shouldn't be. | 2 | Naive cases like "group X has access" might be more cumbersome to express as policy than traditional ACLs and file permissions. So user error may be a little higher in this category. | 3 | Constrained policies will act similar to policies, and may resemble ACLs or more basic file permissions. That might have the effect of reducing user error. | 1 |
| Performance | ACLs will run faster than policies and have the advantage of being implementable in cloud-native or storage-native mechanisms. Dynamic policies are applied only sometimes when required. If it turns out that policies are required pervasively, the performance gains of ACLs may be limited. But that advantage will be there as a possibility. | 1 | Complex policies, evaluated on all accesses, are likely to perform worst of the 3 options. | 3 | Constrained policies should perform faster than Everything as Policy but slower than ACL-only accesses in the Policy-and-ACL case. | 2 |
| Usability | 0 | 0 | 0 | |||
| Technical feasibility and maintainability | Two related subsystems have to be built and maintained—lifecycle management for ACLs and lifecycle management for policies. ACLs are straightforward and easy and are likely to be built mostly from existing capabilities (e.g., storage or cloud native) Policy engine has to be built same as the other two designs. | 3 | Technology for implementing policy exists. Maintainability comes in two flavours: maintaining the code and the operator's ability to maintain policies over time. Both require investment and effort from the operators. | 2 | Feasibility and maintainability for constrained policies is going to be similar to Everything as Policy. It is presumed to be somewhat easier because it is less feature rich and complex. | 1 |
| Cost of change | OpenDES is largely implemented in the Policy+ACLs approach, so existing OpenDES implementations have the lowest cost of change. | 1 | 3 | 2 | ||
| Correctness | ACLs alone are not expressive enough to capture all business and regulatory requirements. Policies fill that gap. Between the two, all requirements should be achievable. Some will be satisfied through ACLs alone, others will require policy+ACLs to achieve. | 2 | All requirements should be satisfiable in this mode because it can express (nearly) anything. | 1 | It's difficult to be sure whether all business requirements can be satisfied with constrained policies, but the implicit assumption is that—for performance reasons—some expensive policy constructs will not be possible. | 3 |
| Freshness | 3 | 2 | 1 | |||
| Accountability / Auditability | Having two somewhat indendent systems makes the ACL+Policy approach the most difficult to account for/audit. Actions allowed by one must be cross-referenced against the other, and both systems presumably log their decisions somewhat indendently. | 3 | A single, unified policy decision point makes policy decisions easier to log, audit, and understand. There will need to be purpose-built logging/auditing support alongside the policy engine. | 1 | Constrained policies will also have a single log of events, making them easier to audit. Because there is presumed to be some gap in coverage between business requirements and constrained policy language, there is presumed to be higher difficulty accounting/auditing accesses. | 2 |
| Nonrepudiation | 0 | 0 | 0 |
Scoring
This counts how many times a given approach ranked first, second or third. Presumably the technique which achieves most goals in first place (or fewest in last place) is the best choice.
| Policies and ACLs | Everything as Policy | Constrained Policies | |
|---|---|---|---|
| First ranks | 2 | 3 | 3 |
| Second ranks | 3 | 2 | 3 |
| Third ranks | 3 | 3 | 2 |