I currently have an interesting issue:
I have defined an app user profile subschema type of Array per the Okta documentation. The custom profile attribute is
roles. They’re a bunch of strings and get sent across fine to my SCIM-enabled app. However, this app implements SCIM per the standard - namely a complex type consisting of value, display, type and primary sub attributes (search for the “roles” string in this section).
When the implementation tries to unmarshal the JSON request body, this fails as it’s expecting the complex type above. Interestingly, Okta manages to make this work for email. While the email attributes in Okta are separate in the profile (ie. primaryEmail, primaryEmailType), the request JSON produced by Okta actually conforms to the RFC schema, namely a multivalued complex type - Emails (including both primary and secondary emails, if defined).
The obvious solutions I see are:
- Renaming my attribute to something other than
rolesand add custom resource type that supports it.
- Lodge a product enhancement request that Okta support Complex types - is there an avenue for doing this?