On another note, I am not convinced that the Validator treats complex multiValued 'members' attribute for Groups correctly, if they are exposed in Schema.
Specifically, if I have Group.members[type ="User"] collection defined in Schema like shown below, then the Validator would attempt to generate a Patch request as shown on the screenshot with some bogus(?) value in the Replace operation for users. That bogus value such as "QQ7M8HRCRACN" looks like a display name for a group, rather than User ID that I would expect it to be.
Or am I missing SCIM spec completely here, and this Replace request has totally different semantics?
See image attached.
To compare, Add Member operation on Group looks fine, with proper User ID:
My schema for the group is as follows:
{
"name": "Group",
"description": "Group",
"meta": {
"resourceType": "Schema",
"created": "0001-01-01T00:00:00",
"lastModified": "0001-01-01T00:00:00"
},
"id": "urn:ietf:params:scim:schemas:core:2.0:Group",
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Schema"
],
"attributes": [
{
"caseExact": false,
"type": "string",
"description": "A human-readable name for the Group. REQUIRED.",
"mutability": "readWrite",
"name": "displayName",
"multiValued": false,
"required": true,
"returned": "default",
"uniqueness": "server"
},
{
"caseExact": false,
"type": "complex",
"description": "A list of members of the Group.",
"mutability": "readWrite",
"name": "members",
"multiValued": true,
"required": false,
"returned": "request",
"uniqueness": "none",
"subAttributes": [
{
"caseExact": false,
"type": "string",
"description": "The significant value for the attribute",
"mutability": "readWrite",
"name": "value",
"multiValued": false,
"required": false,
"returned": "default",
"uniqueness": "none"
},
{
"caseExact": false,
"type": "string",
"description": "A label indicating the attribute's function",
"mutability": "immutable",
"name": "type",
"multiValued": false,
"required": false,
"returned": "default",
"uniqueness": "none",
"canonicalValues": [
"Group",
"User"
]
}
]
}
]
}
`urn:ietf:params:scim:schemas:extension:companyName:2.0:User:authCodes[type eq "Card"].value`
When using customExtensions to support multi-valued complex attributes, this removes the URI prefix in the request body, I believe this may be a bug, is this problem isolated to the scim validator, or would the same problem occur with the producton provisioning service?
I mark some attributes as immutable but SCIM validator still send PATCH request with Patch Operation to `replace` those fields.
How can I get rid of it?
And the Validator reports some values missing in the Fetched Resource, but they do exist there.
Hi there,
I've been running the SCIM validator against my endpoint and have spotted something that I believe may be a bug, but would like to confirm on here.
I'm using the discover schema functionality, my schema gets discovered and in the mappings i'm shown the following:
With the JSON from my '/Schemas' endpoint returning the following for the 'primary' sub attribute on 'phoneNumbers':
When I run the SCIM validator, I can see that the validator is sending the following value for a 'phoneNumber' when adding a User through POST
{
"type": "work",
"value": "1-227-170-3259 x696",
"primary": "(882)058-8632 x34575"
}
As you can see, the primary property is a string. This doesn't appear to be the case for the 'primary' property in the 'emails' array in the same request
{
"type": "work",
"value": "email address removed for privacy reasons",
"primary": true
}
For a bit more detail, emails in the schema discovery mapping screen shows the following:
And my '/Schemas' endpoint returns the following for the 'primary' sub attribute for the emails array:
Any help would be greatly appreciated
I keep getting this failure in the validator if my Users schema exposes a groups attribute:
What it says just seems incorrect. Direct and indirect groups are part of the core spec in RFC7643 section 4.1.2 (page 24), described exactly as I've used them.
I was trying to use SCIM sdk library (https://github.com/Captain-P-Goldfish/SCIM-SDK) and they are adding common attributes (like "id") to the schema. According to specification, some providers MAY include the common attributes. https://datatracker.ietf.org/doc/html/rfc7643#section-3.1
For backward compatibility, some existing schema definitions MAY list
common attributes as part of the schema. The attribute
characteristics (see [Section 2.2](https://datatracker.ietf.org/doc/html/rfc7643#section-2.2)) listed here SHALL take precedence
over older definitions that may be included in existing schemas.Unfortunatelly, SCIM validator doesn't handle this case correctly.
Is there any chance that it could be fixed?
Thank you