SSP Leveraged Authorization Entries

[brian-ruf]

Constraint Task

As a FedRAMP Reviewer, I need to ensure that any leveraged authorization entries have required content.

Intended Outcome

For each leveraged-authorization entry, check for the presence of:

• Exactly one authorization type
• Exactly one package identifier
• Exactly one impact level
• 1 or more authorized users (WARN if less than 1) (Remodeled. Constraint now fits better in SSP Leveraged Authorization Component Entries #898)
• Exactly 1 authentication

Syntax Type

This is optional core OSCAL syntax.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

target="//system-implementation/leveraged-authorization"

./prop[@name='authorization-type'][@ns='http://fedramp.gov/ns/oscal'] 
./prop[@name='leveraged-system-identifier'][@ns='http://fedramp.gov/ns/oscal'] 
./prop[@name='impact-level'][@ns='http://fedramp.gov/ns/oscal'] 

Removed from this issue (see #924):
./prop[@name='user-authentication'][@ns='http://fedramp.gov/ns/oscal']/remarks

Purpose of the OSCAL Content

The content provides information necessary for reviewers to properly evaluate leveraged authorizations. This information is consistent with the requirements of Table 6.1 of the FedRAMP Rev 5 SSP Template.

Dependencies

None.

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

The following constraint work appears to already cover pieces of this:

• has-leveraged-authorization-with-cloud-service-model
• FedRAMP-ATO-Identifier-exists

[brian-ruf]

NOTE: Removed ./prop[@name='user-uuid'][@ns='http://fedramp.gov/ns/oscal'] as this is being handled differently. New constraint grouped in #898

[Gabeblis]

@brian-ruf or @aj-stein-gsa what is the goal of Exactly 1 authentication : ./prop[@name='user-authentication'][@ns='http://fedramp.gov/ns/oscal']/remarks? I am not seeing where this comes from, and I'm not seeing it in the templates.

[brian-ruf]

The word template had a column that is labeled something like Authorized Users and Authentication Mechanism. It was one column with two pieces of information requested. I'm mobile at the moment and can't look it up. Can answer better in an hour or so.

[Gabeblis]

The word template had a column that is labeled something like Authorized Users and Authentication Mechanism. It was one column with two pieces of information requested. I'm mobile at the moment and can't look it up. Can answer better in an hour or so.

Ok, no worries. I was looking at the xml template and json template and I didn't see what that user-authentication content was supposed to look like. I saw remarks, but that's all.

[aj-stein-gsa]

Ok, no worries. I was looking at the xml template and json template and I didn't see what that user-authentication content was supposed to look like. I saw remarks, but that's all.

You might want to look at Brian's WIP branch he uses to look at how we analyze the Word/Excel attachment file requirements how they fit into required and OSCAL data fields.

[brian-ruf]

Actually, the user-authentication property/extension is being moved from //leveraged/authorization to component.
I noted this last week in #807, but see that I lost sight of the follow through.

The user authentication information is required in both 6.1 and 7.1, but 7.1 only uses components. To keep everything as clean and aligned as possible, the property should also be in the component for LA.

I am updating #893 dealing with the allowed values, and created #924 specifically for this constraint as the metapath target for this is unique.