SCIM - User attribute overview

OneWelcome allows SCIM clients to submit and retrieve any reference to a photo.

OneWelcome does not set or use the values of this field.

✖️ No validations at all.

Canonical values photo, thumbnail are not validated.

As per SCIM specifications this field can be used for "the full street address component, which may include house number, street name, P.O. box, and multi-line extended street address information. This attribute MAY contain newlines."

In `OneWelcome's implementation the value may contain '\n' which is used as a separator between individual data with the streetAddress. In this case OneWelcome will parse the field using the following logic:

{street}\n{streetnumber}\n{region}\n{postal_code}\n{city}

OneWelcome does not copy the values of region, postal_code and city as result of such parsing into the sub-attributes listed in this table. The parsed values will be shown as individual fields in the Self Service UI (if configured).

The primary value of this multi-valued attribute is used by OneWelcome to send emails (with authenticating links, OTP, ...).

Primary email addresses (by default) are used as user identifier.

🔆 OneWelcome does not canonicalise the values; i.e. does not convert to lowercase. Email addresses should be submitted in lowercase.

🔆 Canonical Type values of 'work' or 'home' are not validated.

An email address must have a valid value. Informally stated, it should look like "XXX@YYY.ZZZ"; it must contain one '@' and a '.'.

Primary email addresses must be unique over all identities within a segment; they're used as identifier. Email addresses within a single identity must be unique (regardless of their type and whether they're primary or not).

By default, a primary email is configured as a mandatory attribute; with this default OneWelcome configuration no identities can exist without a primary value for the emails attribute.

🔆 OneWelcome does not canonicalise to format as per RFC3966. It is recommended to submit values that are compliant (e.g. start with '+'), which will allow mobile phone numbers to be used in an automated way to send SMS text messages for 2FA purposes.

Phone number is a multi-valued attribute in the SCIM interface. If the type is 'mobile' and it is marked as 'primary', OneWelcome may use the phone number to send OTP per SMS Text message.

Phone numbers can be used as user identifier if their type is 'mobile'.

Username can be used for identification during login (if configured).

Username is case sensitive.

Username value should not contain copied values from other identifying user attributes.

When username was submitted through SCIM or chosen by end user during registration or activation, it will get trustLevel 'verified' and may be shown on Self Service screens. In other situations it will have same value as 'id' and will not have the 'verified' trustLevel.

✅ OneWelcome validates the uniqueness and presence of this attribute.

ℹ️ When OneWelcome's segmentation feature is used, uniqueness is validated within the identity's segment.

Value is generated by OneWelcome and typically not known to the end user.

ID can be used for identification during login (if configured).

Value of ID never changes during lifecycle of the user's identity.

Password can be provided via SCIM. When a user is created, typically a password it will be included, but this is not necessary.

When an identity is updated through SCIM User-PUT without a password-attribute, the password within OneWelcome remains unchanged.

OneWelcome supports the possibility to submit securely hashed passwords. Currently this feature is supported with the bcrypt, md5,and SSHA algorithms. If the value that is submitted starts with "{bcrypt}", "{md5} or "{ssha}", the remaining part of the value is interpreted as the hash value, which will be used for password validation.

When the Authoritative Source, sets the password through SCIM, it may have communicated the password to the user or not, which can be indicated by setting the Trust level (see here) to 'validated' or not. Passwords that don't have TrustLevel 'validated' could be considered not known to the user and may as well be considered as non-existing, since they will not be used to login. Usage of this semantics is optional, however.