Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-12235

REST API for agent creation on Update requires full values.

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 14.1.1, 5.5.1
    • Fix Version/s: None
    • Component/s: rest
    • Labels:
    • Target Version/s:
    • Rank:
      1|hzuyrz:
    • Support Ticket IDs:

      Description

      Bug description

      This applies too on 6.0.0-SNAPSHOT. For the realm-config/agents/*Agent (be it Web/J2EE and others), the create and create_put (ie: using PUT) behaviour is like this:

      1) In 5.1.1,

      a) Case NEW entry: (PUT)

      when the agent id is not present, the entry is created and it pull in some "template" values and create the entries. This is fine

      b) Case entry exists: PUT

      When a PUT (with the existing id), the entries are updated. Old existing values if not defined in the requested Payload will not be touched. Only new values in the requested payload will be updated.

      c) If the Agent has inheritance set (done outside of the REST), updating the values will reset the inheritance of that attribute to OFF. for that agent id and the value updated

      In short the experience seems good

      2) Now move on to 5.5.1,

      1) NEW Entry (PUT)

      The schema changed (see OPENAM-12229) and so the format of the payload to 5.5.1 is different. Now, on creeation missing values will take the template values. This looks ok.

      2) Updating existing entry (PUT). Now updating the entries in 5.5.x and even 6.0-SNAPSHOT overwrites everything. (Does not use old values that's existing nor will there be template values). So a GET returns what is passed in essentially.

        "logoutEntryUri": {
        "key": {
          "": {
            "inherited": false,
            "value": ""
          }
        },
      
      Summary Issues:

      i) It is seen there is inherited values for the the AgentGroup but this itself does not work. (whatever values does not matter). 5.5.x seems does not work well for REST update (or at least it behaves like a create with all values passed in the PUT)

      ii) There is also no field data validation (anything goes) [sure the API descriptor never say this but if the agent config lack certain key values it's a broken config]

      iii) Using PUT on an existing id, will overwrite with things in the payload. The values in of the old one is not merged in. (so the point on data validation above also applies)

      iv) The schema has inherited but the schema does not provide the way to associate the agentGroup. (OAuth2 in 5.5.x is the only one having it).

      3) 6.0.0-SNAPSHOT-m2/m3

      It seems the schema now for Webagent/J2EEAgent changes with the inherited AgentGroup. However the issue on update on an existing entry is still the same.

      a) Case NEW entry: The entry created with template values for those items that's is not defined in request payload.

      b) Case PUT with existing id.

      For the request payload that's missing some entries for example like "advancedJ2EEAgentConfig" block, then the update UI will empty. (ie: showing that
      it does not use any other values) and all values needs to be passed in.

      How to reproduce the issue

      1. Setup the respective AM version
      2. Run API explorer for realm-config/agents/WebAgent/J2EEAgent
      3. Clear all agents
      4. Create a new Agent Agent1
      5. Observe and get the payload
      6. Modify some payload and and execute #create_put#update (existing)
        where only the esssential payload (say agentDebugLogLevel)
      7. Now do a GET to get the payload.
        (or check the UI). The extries may be all missing now
      Expected behaviour
      We need to have a more consistent behaviour with create  and update. The update does not have validation and suggest it is not an update over the config but may need to provide all the payload version.
      
      • It is desirable if we not have the template values set. (and maybe have data validation) and that user provided the required values.
      • Desirable if it behaves like a patch. (but surely an update should not take the template values)
      Current behaviour
      Creation of a new entry takes in the payload value and some "template" values
      Doing a PUT with payload on an existing entry overwrite the entry. (now this even works if the resulting config will be invalid)
      

      Work around

      Due to the schema resource version for all these is 1.0, currently it seems for each specific AM version we have to define a FULL request payload and treat create(new entry) and create(update) as the same and pass all the settings again.

      Code analysis

      Seems like 5.5.x is in unstable mode (with the inherited schema).

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                chee-weng.chea C-Weng C
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: