Closed telosBA closed 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.
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.
Closing, if the comments by @GaryGapinski and @markXLIX could be clarified, please let us know.
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.
This is not the case, as it references a role with that exact same id expressed in multiple locations.