Skip to end of metadata
Go to start of metadata

Overview of "Define Resource Policy" Use Case

Operator defines policy for a specific resource, system enforces it


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Observatory Operator
References Governance Model
Uses  
Is Used By  
Extends  
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.
Lead Team COI
Primary Service Identity & Policy Management Services
Version 1.6
UC Priority 4
UC Status Mapped + Ready
UX Exposure ONC, MNC

Summary

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.

Assumptions

  • 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.

Initial State

The Observatory Operator knows the target Resource type and the intended policy to be applied to it.

Scenario for "Define Resource Policy" Use Case

  1. The Observatory Operator identifies the Resource type to which the policy will be applied.
  2. The Observatory Operator describes the policy which applies to the target Resource type.
    1. 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.
    2. The policy is created by describing a Contract using Clauses (see Governance Model reference).
    3. The policy characterizes qualifications, privileges, and liabilities that may apply to a Principal.
    4. In this case the Principal is the individual that wants privileges with respect to the affected resource.
  3. The Observatory Operator makes the policy active.
  4. 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.
    1. For example, wants to see the resource, or wants to make it publicly visible
  5. Case 1: The privilege is granted, and the user access the target Resource.
  6. Case 2: The privilege is NOT granted, and the user is denied access to the targeted Resource.
    1. The reasons for the denial (the relevant policies and roles) should be presented.

Final State

The policy has been defined and used.

Comments

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.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.