- We will support a dynamic mostly approach to evaluating entitlement
- Reference implementation from OpenDES for R3 will be based on a hybrid approach with a new policy engine supporting the above
- Need to consolidate the security focus within OSDU (subcommittees, tiger team ...) and matching it to a consolidate approach on the implementation side (PMC)
- We need to communicate more about the concepts (and implementations) of Consumption zone to handle specialized requirements to avoid side-car access
- See Action Items
Implications to be considered by OSDU security collective
- We will have to maintain within OSDU a level of user information
- Need or requirement to write these rules and set them as policy
- Advisory group, outlined the use cases, and attributes within those rules
- Need constant curation around business use cases
- Recommend to create a security and compliance group within both OSDU and the PMC
- OSDU (subcommittees) to express business rules as a set of policies in a common policy expression language with the necessary set of APIs.
- Build priorities and acceptance criteria for technology selection (OSDU and Dev) including capability, performance and usability
- Using the above (policies) and acceptance criteria, evaluate technical and architectural solutions
- Dynamic approach to policy - will test that in February
Application specific entitlements are generally considered as part of the scope for entitlement solution.
Use cases such as JV, Production Sharing and Subscriptions/Brokerage/Data Rooms can be considered as similar use cases and can be grouped as the same. This may simplify the way the use cases are described.
The architecture should allow for the data to be delivered using the cloud-native methods, the entitlements will act as a layer to produce a token or access to this service. For example, a File Service can deliver a signed url once the user is authorized for access for a given object. Similar mechanisms may have to be devised for each kind of storage/service. Q. Is it possible to replicate a 'signed-url' type of scheme for all kinds of data storage. Signed URL works reliably for blobs and files.
High level decisions, summarized by Stephen:
- Prefer dynamic entitlements over static
- We rely on App mesh type of patterns where the services are absolved of doing entitlement related work. The entitlement code may be injected where the services need an ability to apply the entitlement within themselves - such as injecting filter into the get_data() query to storage/elastic search.
- Data Groups (ACLs) can be used tag the data which are then analyzed by the rules engine. Which implies that each data item has to be tagged so.
- There is a need to retain the cloud-native authorization and use it to write when the cloud SDKs/APIs are used. The authorization enforced by policy agent and entitlement engines will be different to this authorization. There is a desire to merge these two one layer - not sure if that will be feasible though.
Parking Lot Items
Kerry mentioned that OSDU has taken a decision to use OpenID Connect as the technology for authentication; it must be possible then to use the same technology as means to authorize against. There was a related discussion that spawn out to see if OpenID Connect is or will be absorbed in to R2.
Alan to share the Contract data model to wider group, starting with the DD and IS groups
To enable entitlements, OSDU will have to maintain the user, group & membership models? Or could we infer the roles & groups with an external system - such as Active Directory etc. User identity is expected to come from IDP that is OpenID compliant.
Can the data be grouped at a higher level such that each data item doesn't need to be tagged so. For example, consider a list of files in a given folder or bucket. The files don't carry an implicit tag but inherit permissions set at a parent level.
Google has used CEL for both application layer and also on the data layer, such that the IAM relies on CEL type of engines to evaluate a claim (entitlement) against typed sets such as ACL. There will need to be a consensus across the other cloud providers to adopt and invest in a similar model.
At the outset it appears that the data needs to be passed into CEL expression engine, this implies every set of data needs to evaluated all the time. We may have specialized translators for Elastic to make it run optimally (such as the expression is translated as a query to Elastic), we may need similar mechanism in other technologies as well. This also adds / complements to the point #5 (closed) above.
Keith suggested that group can focus on specifying how the policies should be specified - such as business rules which are expressed in CEL. The technical implementation should be left out to the cloud providers and is not a OSDU concern.
There is a need to consolidate the IS as Security & Compliance team, possibly merge it with Architecture.
Next step is to create a project and identify a project leader to
- specify the business rules and expressions.
- state the acceptance criteria
Target launch / kick-off in Feb. The specification will be followed by adding a set of implementors to start implementing the rules in the respective cloud technologies.
Hrvoje suggested that we do a spike on CEL taking a specific use case. The spike can also include an evaluation to see if a policy can be turned into an ACL. Alan suggested that SDU may already have the rules engine implemented, this can be shared for the spike. Mid Feb?
Example technical criteria
- The system should be able to evaluate each policy expression individually in less than 10 ms time.
- The system should be able to when given a user context, set of attributes and groups be able to run multiple policies in one decision endpoint call.
- This endpoint should be able to be evaluated in less than 1 second time per request.
- The system should be able to support custom functionality in the expressions so that the platform can extend its functionality.
- For example, being able to build a new function called isvalidlocation() and that should be able to run some custom native code to return true or false etc.
- The system should be able to support generic expression functionality (and, or, xor, union, if, else, any, all, none etc.)
- The system should be able to perform CRUD operations on policy rules and the relationship to groups or users.
- The system should be able to support “timed” policies, as in a policy is only valid for 5 years.
- The system should audit changes to policies and relationships to policy information.