Uploaded image for project: 'Repose'
  1. REP-5632

Add YAML support to Attribute Mapping library


    • Type: Story
    • Status: Resolved (View workflow)
    • Priority: High
    • Resolution: Done
    • Affects versions: None
    • Fix versions:
    • Components: None
    • Labels:
    • Epic Link:
    • Sprint:
      Sprint 146, Sprint 147
    • Story Points:
    • Capitalizable:


      Attribute mapping is currently JSON/XML only. There's talk with product to support YAML rather than JSON. They are product managers (Goody) as JSON doesn't do comments that are allowed to be set by UIs.

      Validation should continue still work obviously.

      We would likely only support YAML - for simplicity sake, use a subset of YAML that supports the existing JSON format – so that it's a straight conversion.

      • Support YAML v1.1 spec.
        • YAML v1.2 is a proper superset of valid JSON (i.e. valid JSON is valid YAML), but we cannot locate a 1.2 parser. SnakeYAML is a YAML v1.1 parser, but YAML v1.1 is not a proper superset of JSON.
        • In YAML 1.2, there are rules such that a JSON file can be parsed as a YAML file including having better aligned data types (e.g. booleans).
      • Leave JSON support in the library

      Note: we can begin work on this but do need a mapper release to release these together.

      We pointed worst case scenario that we use YAML 1.1 parser

      Findings from the spike:
      SnakeYAML is no longer being maintained by its main developer. It officially provides YAML 1.1 support and unofficially provides YAML 1.2 support. Of note, RAML is using SnakeYAML 1.15 which indicates they're using YAML 1.1. Jorge re-iterated that it's fine to use YAML 1.1 and SnakeYAML.

      The scenario is:

      • The end-user will only ever send us YAML (content type: text/yaml).
        • We (Repose, Attribute Mapper) validate it.
      • Repose sends the original YAML content to the origin service.
      • Some time later...
      • For a request, the origin service will return that content with the text/yaml content type (no matter what it actually might be).

      Identity will also be using the library to migrate the existing policies to YAML. This work will be done in REP-5758 Resolved .

      Attempting to break down:
      Given we're using YAML 1.1 and SnakeYAML, use Jackson to convert YAML to JSON and JSON to YAML. The translation would be a strict JSON to YAML (i.e. don't use any fancy YAML features in this use case).

      We already have JSON to XML and XML to XSLT. The Attribute Mapping library supports JSON and XML, but only JSON is being used right now.


      • We're using Jackson
      • Converting incoming YAML to JSON (i.e. JsonNode)
      • This won't be a major impact on performance (the bottleneck is in the XML signing)
      • We will not be doing any converting from JSON to YAML in this story ( REP-5758 Resolved )
      • Library will take a StreamSource (or similar) (i.e. don't have to support something like a YamlNode assuming it even exists).

      Acceptance Criteria:

      • Attribute Mapper library supports validating and translating a YAML policy using the SnakeYAML library.
        • This implies support for the YAML 1.1 spec.
        • It does not necessarily support the YAML 1.2 spec.
      • Comments in the policy do not have to be preserved.
        • Repose will worry about this by sending the original policy to the origin service (with the comments preserved).
      • JSON support in the library will be left intact.


          Issue links



              • Assignee:
                wdschei Bill Scheidegger
                jorgew Jorge Williams
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: