Operator defines policy for a specific resource, system enforces it
|Is Used By|
|Is Extended By|
|In Acceptance Scenarios||AS.R2.01B Define Marine Observatory Policies, AS.R2.02C Instrument Life Cycle Support, AS.R2.04A Data Product Leads Drive Core Data Product Creation, AS.R2.04B Curate Data Products, AS.R2.04C Instrument Experts Drive Core Instrument Operations|
|Technical Notes||Principals can be individuals or Orgs, but if individuals, they must be able to have 'Org roles'. So this use case depends heavily on the Org representations in ION.|
|Primary Service||Identity & Policy Management Services|
|UC Status||Mapped + Ready|
|UX Exposure||ONC, MNC|
This information summarizes the Use Case functionality.
A Marine or Integrated Observatory Operator creates a policy by describing a Contract using Clauses (see Governance Model reference). The policy characterizes qualifications, privileges, and liabilities that may apply to a Principal, in this case the Principal that wants privileges with respect to the affected resource. The policy is made active. When the Principal attempts an operation requiring privileges for the given resource (for example, wants to see the resource, or wants to make it publicly visible), the Integrated Observatory applies the relevant policy to determine whether to grant the privilege.
- Possible rules have already been identified that can be used in policies.
- A service is a resource, and policies can be written against services as well as against general resources.
The Observatory Operator knows the target Resource type and the intended policy to be applied to it.
- The Observatory Operator identifies the Resource type to which the policy will be applied.
- The Observatory Operator describes the policy which applies to the target Resource type.
- The Observatory Operator should have a cafeteria view of possible rules to be applied (rather than generating their own); maybe not in a UI in R2 though.
- The policy is created by describing a Contract using Clauses (see Governance Model reference).
- The policy characterizes qualifications, privileges, and liabilities that may apply to a Principal.
- In this case the Principal is the individual that wants privileges with respect to the affected resource.
- The Observatory Operator makes the policy active.
- When the Principal attempts an operation requiring privileges for the given resource, the Integrated Observatory applies the relevant policy to determine whether to grant the privilege.
- For example, wants to see the resource, or wants to make it publicly visible
- Case 1: The privilege is granted, and the user access the target Resource.
- Case 2: The privilege is NOT granted, and the user is denied access to the targeted Resource.
- The reasons for the denial (the relevant policies and roles) should be presented.
The policy has been defined and used.
These comments provide additional context (usually quite technical) for editors of the use case.
It isn't clear how the new policies can be operationally tested in advance of their deployment. It is possible a poorly set policy can effectively stop system operations across the Integrated Observatory, and certainly lots of edge cases will be difficult to test in any realistic way. A test deployment system may be of some use.
People are assigned a role in a scope (Observatory Operator for a particular observatory), and that is not explicitly reflected in this use case. Ideally it should be, but in any case the implementation will have to deal with that detail.