Add Support for custom attributes

[Avinash-Kamath]

Issue

IDP like OKTA, Azure support custom attributes along with scim attributes. Today Resource type validations will drop all non-scim compliant attributes during validation

Solution

Adding a flag to allow non-SCIM compliant attributes, updating the validation logic to include these attributes

Support for custom attributes:

• resource_type.go: Added AllowNonScimKeys flag to ResourceType to allow non-SCIM compliant attributes. Updated the validate method to include these attributes in the resource type. [1] [2]

Testing enhancements:

• handlers_test.go: Added the AllowNonScimKeys flag to the newTestServer function and created a new test TestServerResourceHandlerWithCustomAttributes to verify the handling of custom attributes. [1] [2]
• utils_test.go: Added a helper function assertEqualMaps to compare maps in tests.

[q-uint]

Thanks for the contribution! I understand the need: IdPs like Okta and Azure do send custom attributes outside the standard SCIM schema, and that's a real pain point.

However, I can't merge this as-is for a few reasons:

SCIM compliance. RFC 7643 defines that resource attributes must be described by schemas. The SCIM-compliant way to handle custom/non-standard attributes is through schema extensions (urn:ietf:params:scim:schemas:extension:...). Passing through arbitrary unvalidated keys bypasses that mechanism.

Unvalidated input passthrough. The current implementation copies any unrecognized key from the raw JSON into the attributes map without validation. This could allow clients to inject keys like schemas, id, or meta that are present in the raw map but stripped before validation — the attributes[k] guard doesn't account for those.

Test side effects. Setting AllowNonScimKeys: true in the shared newTestServer helper changes behavior for all existing tests, not just the new ones.

A few smaller things:

• ExpectedCustomAttribute is exported while the other test struct fields aren't — should be expectedCustomAttribute.
• assertEqualMaps is redundant — reflect.DeepEqual already handles map comparison including length.

Next steps: Could you open an issue describing the use case and the IdP behaviors you're working around? That way we can discuss the right approach, likely improving the ergonomics of SchemaExtensions to make it easier to handle IdP-specific attributes in a SCIM-compliant way. We can revisit a PR once we've aligned on the design.