Authorized Users for Leveraged Authorizations and External, Interconnected, and Unauthorized Systems

[Rene2mt]

Constraint Task

As a maintainer of a digital authorization package, I need to clearly document the in my SSP the authorized uses of any leveraged FedRAMP authorized services, so that agencies that use my service understand potential risk around the user types that can access data in the external system. Checking to ensure I have provided complete listing of authorized users will prevent pass back during review of my SSP.

Intended Outcome

Define a constraint to ensure that only valid / defined users are referenced when listing authorized users for a leveraged authorization. In other words, each //system-implementation/leveraged-authorization/prop[@name='user-uuid'][@ns='http://fedramp.gov/ns/oscal']/@value must reference a valid //system-implementation/user

The constraint should give an ERROR if the condition is not met.

Syntax Type

This is a FedRAMP constraint in the FedRAMP-specific namespace.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

Each appropriate component type (leveraged authorizations, interconnections, external services, etc.) has at least one responsible-role other than the "provider" role.

target = "//component[
   (@type='system' and ./prop[@name='leveraged-authorization-uuid'])
or
   (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and  ./prop[@name='implementation-point' and @value='external'])
or
   (@type='interconnection')
or 
   (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction'])
or
   (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction'])
]"

Constraint:

count(./responsible-role[not(@role-id='provider')]) >= 1

Each non-provider responsible role references at least one user/authorized-privilege/function-performed via the "privilege-uuid" property/extension.

target = "//component[
   (@type='system' and ./prop[@name='leveraged-authorization-uuid'])
or
   (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and  ./prop[@name='implementation-point' and @value='external'])
or
   (@type='interconnection')
or 
   (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction'])
or
   (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction'])
]  

/responsible-role[not(@role-id='provider')]
"

Constraint:

count(//system-implementation/user[@uuid=./prop[@name='privilege-uuid' and @ns='http://fedramp.gov/ns/oscal']/@value]/authorized-privilege/function-performed) >= 1

Purpose of the OSCAL Content

No response

Dependencies

Check to ensure that for each leveraged authorized system / service, the SSP clearly documents (what user types / roles) are authorized users.

Acceptance Criteria

• All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
  • Explanation is present and accurate
  • sample content is present and accurate
  • Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
• All constraints associated with the review task have been created
• The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
• The constraint conforms to the FedRAMP Constraint Style Guide.
  • All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
• Known good test content is created for unit testing.
• Known bad test content is created for unit testing.
• Unit testing is configured to run both known good and known bad test content examples.
• Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
• A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
• This issue is referenced in the PR.

Other information

No response

[brian-ruf]

This is being revised and expanded to cover both #807 and #808

[brian-ruf]

This was revised and is now ready for assignment. It was changed to align the handling of authorized users the same for both #807 and #808 above, and using the Variant 2 solution discussed in THIS COMMENT of issue #534.

[brian-ruf]

This issue uses the same target and data constructs as #937 . Consider having the same person work both together.