Schema extension URIs inside patch operation fail validation

[tacerus]

Hi,

it appears extension attributes are not fully supported in PATCH requests.

Consider this example payload:

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "value": {
        "name": {
          "givenName": "Foo",
          "familyName": "Bar",
          "formatted": "Foo Bar"
        },
        "active": false,
        "title": "Engineer",
        "externalId": "uid=test,ou=people,dc=example,dc=com",
        "addresses": [
          {
            "streetAddress": "Dreamland 1",
            "locality": "Dreamland",
            "postalCode": "123456",
            "region": "Bavaria",
            "country": "DE"
          }
        ],
        "phoneNumbers": [
          {
            "type": "mobile",
            "value": "+1 234"
          },
          {
            "type": "work",
            "value": "+1 456"
          }
        ],
        "emails": [
          {
            "primary": false,
            "type": "work",
            "value": "secondary@example.com"
          },
          {
            "primary": true,
            "type": "work",
            "value": "primary@example.com"
          }
        ],
        "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
          "organization": "SUSE"
        },
        "urn:ietf:params:scim:schemas:extension:suse:2.0:User": {
          "sshPublicKey": "ssh-ed25519 abc"
        },
        "userName": "test"
      }
    }
  ]
}

Here extension attributes are provided as a map, which should be a valid way to provide them in resources: https://datatracker.ietf.org/doc/html/rfc7643#section-3.

Yet, the validation for the urn: keys fails for the example above. The problem appears to be around getRefAttribute(), where attrPath.URI() strips the last element after the colon, and then compares the incomplete URN with the map of schemas. The stripping makes sense for the path attribute in the patch operation, where the full URN to an attribute is to be provided, but it seems to break the map based format inside the patch values.

Unfortunately, I could not yet figure out how to fully solve this myself: looking up attrPath.String() will yield the schema, but something is needed to process the value as a complex attribute.

A workaround is to provide the attributes as full references without the map based format (i.e. the same way they would be provided in path), but this appears to not be the common syntax.

[q-uint]

Thanks a lot @tacerus! Opened a PR with the bug fix.

Will let it sit for a day or two so I can review it with some fresh eyes.

[tacerus]

Thank you very much, @q-uint.