Profile processing for catalog code generation

[anweiss]

Support processing of profiles for parameter insertions and add, merge, modify, alter and remove to generate catalogs with profile data.

[anweiss]

Some of this is addressed by #11.

[anweiss]

@minhaj10p let's start digging into this one. That way we can begin to identify some of the challenges/gaps in nested profiles and figure out ways to deal with them.

[asadullah-yousuf-10p]

@anweiss @minhaj10p do we want to fill in parameters in generated control structs? I think we would want to do that for implementation as well.

[anweiss]

@asadullah-yousuf-10p yes, that would be ideal.

[anweiss]

@asadullah-yousuf-10p let me know your thoughts on this. I know this is not a complete solution, but I think it's one of the flows that we should be able to address.

I'll use the FedRAMP High profile as an example, and I'll use the phrase "root profile" to refer to the profile in context, which in this example is FedRAMP High. I'll also refer to the add, merge, modify, alter and remove elements as "manipulation" elements in this example.

1. Only the controls/subcontrols include'ed in the root profile need to be selected. If the import'ed profiles also import other profiles, disregard any of the nested controls/subcontrols that are not referenced by the root profile, since they are not in the context of the root profile.
2. The "manipulation" elements in the root profile and import'ed profiles should be processed, but only for the controls/subcontrols that have been identified per "Step 1" in this sequence. One should recursively search the import chain only for the controls/subcontrols that are referenced by the root profile. The highest-level profile's "manipulation" elements always override any "manipulation" elements when recursively searching the import chain.

[minhaj10p]

Hey @anweiss, I was able to play around with profile processing and here are some insights and personal opinions.

• We need to make sure that a particular import of a profile caters only one catalog. Another import is required to cater controls from another catalog. If not, we can have two different kinds of controls listed down under a single import section in a profile which makes things very difficult to parse.

• The modification sections are outside of the import (import identifies the catalog in the light of above point) which makes it difficult to identify what control/sub-controls belong to which catalog.
  ---- One way to do it is we pick up the first control in the import section, and find it in the modification tags so we know which catalog does this modification control/subcontrol belongs to, and then continue to process it. (taking this approach for starters)

• The parts listed in catalogs has ids but the Fedramp profiles do not. Should we process against class attribute or are we going to be pushing some changes to the fedramp parts so we can add more ids

• The parameters listed in set-param of a profile are upfront which makes it difficult to figure their relative catalog out or their position. My suggestion is we should make the parameters in the profile fall under a control hierarchy so that it will be easier to track it up against a catalog.

#52
This PR is based on above mentioned assumptions and is subjected to change. It adds the feature to identify the catalog in the import chain/tree + add attribute in alter section of the profile.

[minhaj10p]

@anweiss It would be highly appreciated if you could document what we discussed as part of this issue regarding the modification attributes. Thanks

[anweiss]

@minhaj10p sure thing

[anweiss]

For now, let's exclude the scenario where a profile may import multiple catalogs and just assume that the same catalog is being import'ed.

With that being said, here's a summary of the "manipulation" parsing discussion that we had:

• "manipulation" elements in profiles should always reference control/subcontrol id's that have been include'd in a profile. If they reference other id's that aren't included, than this is an error in the profile
• for as long as the same control/subcontrol id is included in an import chain, only the highest-level "manipulation" elements should be parsed ... for example:
  • if AC-1 is in both the root profile and all import'ed profiles in a chain, only parse the first set of "manipulation" elements that you find in the chain
  • if AC-1 is in the root profile, and the root profile also has "manipulation" elements for AC-1, only parse those "manipulation" elements
  • if AC-1 is in both the root profile and the import'ed profiles, but the root profile has no "manipulation" elements, then iterate through the import'ed profiles in the chain until you find the first set of "manipulation" elements, if any exist in the chain for AC-1