SCIM Error Responses Not Compliant with RFC 7644 Section 3.12

[J-Bu]

Summary

Error responses returned by the Wire SCIM server are wrapped in an extra layer of JSON that does not conform to the SCIM protocol specification. The server returns {code, label, message: <SCIM-Error-JSON>} instead of the standard SCIM Error object defined in RFC 7644.

We use python-scim for communication with the SCIM server, which by default is very strict and validates all data against the schemas.

Expected behavior

Per RFC 7644 Section 3.12, error responses MUST be returned directly in the following JSON format using the schema URI urn:ietf:params:scim:api:messages:2.0:Error:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "detail": "Human-readable error message",
  "status": "400"
}

The RFC defines exactly three attributes for error responses:

• status (REQUIRED): The HTTP status code as a JSON string
• scimType (OPTIONAL): A SCIM detail error keyword
• detail (OPTIONAL): A detailed human-readable message

Actual behavior

The Wire SCIM server wraps the SCIM error response in an additional JSON object:

{
  "code": 400,
  "label": "scim-error",
  "message": "{\"detail\":\"Could not process externalId. Please check: (1) does the scim user contain a valid email address? (2) did you associate your scim token with a SAML IdP in wire?\",\"schemas\":[\"urn:ietf:params:scim:api:messages:2.0:Error\"],\"scimType\":\"invalidValue\",\"status\":\"400\"}"
}

Key issues:

1. The response uses code instead of status, message instead of detail
2. An extraneous label field is included
3. The actual SCIM Error object is double-encoded as a JSON string in the message field
4. The schemas attribute is at the wrong level

Screenshots

N/A

Additional context

• SCIM client library: python-scim, which enforces RFC-compliant response validation by default
• RFC 7644 Section 3.12: HTTP Status and Error Response Handling
• RFC 7644 Section 3.7: Response and Error Handling

[fisx]

thanks for reporting, we'll look into it!

[fisx]

#5419

The fix was easy, now I just need to ponder the consequences of changing the API in a backwards-incompatible way. I am somewhat hopeful it may get merged this week and released in the next couple of weeks.

Thanks again for reporting! I'd be curious to learn about your use case, if you want to chat let me know.