GSA / fedramp-automation

FedRAMP Automation
https://www.fedramp.gov/using-the-fedramp-oscal-resources-and-templates/
Other
256 stars 74 forks source link

UI Validator Error in identifying referenced role definitions #355

Closed telosBA closed 1 year ago

telosBA commented 1 year ago

Describe the bug

Validation test for “Each identified role must reference a role definition” is broken. The error claims that our tag within does not reference a role definition. image This is not the case, as it references a role with that exact same id expressed in multiple locations.

tag: ![image](https://user-images.githubusercontent.com/104856767/199774761-79dcfbd4-23e3-4957-b2c5-65bc971dd37c.png) Definition: ![image](https://user-images.githubusercontent.com/104856767/199774816-6e07aec9-33b9-4bcf-ba67-0e78c4376da9.png) Responsible Party: ![image](https://user-images.githubusercontent.com/104856767/199774889-db1cb6f0-15cc-4c11-b8e8-d1f7993ab1bf.png) We tested this with multiple allowed values and it still failed. The same error is thrown for the template. # Who is the bug affecting? Telos # Is this report specifically related to [the Word or Excel files from fedramp.gov?](fedramp.gov/documents-templates/) # What version of OSCAL are you using? (Check our info on [supported OSCAL versions](https://github.com/GSA/fedramp-automation/blob/master/README.md#support-and-oscal-deprecation-strategy)) 1.0.4 # What is affected by this bug? Validation with UI Validator {Describe the impact the bug is having.} # When does this occur? During validation of SSP. {Describe the conditions under which the bug is occurring.} # How do we replicate the issue? {What are the steps to reproduce the behavior?} 1. Create an SSP including `` `` and an associated role id definition. 2. Run SSP through UI Validator. 3. Note Errors {If applicable, add screenshots to help explain your problem.} # Expected behavior (i.e. solution) No error when user role-id has an associated role id definition. # Other Comments {Add any other context about the problem here.}
markXLIX commented 1 year ago

This is not testing responsible-party/@role-id. It is testing the role-id element value against the role/@id value.

The role-id element should look like this: <role-id>asset-administrator</role-id>. Any whitespace within role-id is not allowed by OSCAL schema.

GaryGapinski commented 1 year ago

An additional observation to add to to Mark's.

The following instance document illustrates the problem:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://github.com/usnistgov/OSCAL/raw/v1.0.4/xml/schema/oscal_complete_schema.xsd" schematypens="http://www.w3.org/2001/XMLSchema" title="OSCAL complete schema"?>
<system-security-plan
    uuid="8c000726-ba93-480d-a221-8cb60df10c24"
    xmlns="http://csrc.nist.gov/ns/oscal/1.0">
    <metadata >
        <title></title>
        <last-modified>2022-11-04T08:15:25Z</last-modified>
        <version>0</version>
        <oscal-version>1.0.4</oscal-version>
        <role id="x">
            <title>x</title>
        </role>
    </metadata>
    <system-implementation>
        <user
            uuid="42120127-42d1-4486-a710-7b4bb15d8bda" >
            <role-id>
                x
            </role-id>
        </user>
    </system-implementation>
</system-security-plan>

role-id in that example fails OSCAL XML Schema validation because of the whitespace in the element text content. It also causes the related Schematron assertion to fail. (The example has other unrelated failings wrt OSCAL XML Schema.)

<role-id>x</role-id> allows the Schematron assertion to pass.

Note that the UI does not apply XML Schema validation to the instance document. This is due to the absence of a freely available Javascript-accessible XML Schema validation implementation. OSCAL instance documents should be validated (for XML Schema compliance) using https://github.com/usnistgov/oscal-cli or other suitable XML Schema validating parser (e.g., Apache Xerces, xmllint).

Worthy of note: the OSCAL definition of /system-security-plan/system-implementation/user is "System User: A type of user that interacts with the system based on an associated role." (emphasis mine). It is not an instance of an entity (human or otherwise). The choice of term is unfortunate. It is not synonymous with /system-security-plan/metadata/party ("Responsible party: A reference to a set of organizations or persons that have responsibility for performing a referenced role in the context of the containing object." which is also unfortunately a stretch definition past party conjoining responsibility and thus complicating party as well as user. party would have best been left as just an entity definition with responsibility separately defined in isolation by responsible-party.). user is essentially a (metadata) role doppelgänger describing privileges associated with role (though parties might have neither responsibility nor privilege). Also unfortunate: there is no requirement that a metadata role have privileges via user — there is a weak implication that a user/role-id is grounded in a metadata/role (see also Guide to OSCAL-based FedRAMP System Security Plans §4.18) since 'user' is essentially 'role' with privilege adornments. I will stop here until someone requests additional dissatisfactions.

danielnaab commented 1 year ago

Closing, if the comments by @GaryGapinski and @markXLIX could be clarified, please let us know.