Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

SCIM API

SCIM user attributes

search

SCIM user attributes

In SCIM, a resource is a collection of attributes identified by one or more schemas. The allowable contents of resources are defined by a set of schemas and a resource type, such as user or group. Each SCIM schema is a collection of attribute definitions that describe the contents of your user and group resources. The attribute definitions specify the attribute name and metadata, such as type (string, binary) and cardinality (singular, multi, complex).

Minimally, an attribute consists of the attribute name and at least one simple or complex value, either of which can be multi-valued. The SCIM schema defines the data type, plurality, and other distinguishing features of an attribute.

Unless otherwise specified, all attributes are modifiable by your users. Immutable (read-only) attributes are specified as read-only within the attribute definition.

Attribute data types

The OneWelcome Identity Platform applies the following validations:

  • validation on string for any string field
  • validation on boolean for any boolean field
  • validation on decimal for any decimal field
  • validation on integer for any integer field
  • validation on datetime for any datetime field
  • validation on binary for any binary field

For details about attribute types, see SCIM: Core Schema 1.1 - Attribute Data Types section.

Attribute values

The following table shows examples for cardinality and attribute values:

Simple Complex
Singular userName
displayName		 name
Multi-valued emails addresses

Simple, multi-valued attributes have a value sub-attribute, whereas complex multi-valued attributes don't.

Multi-valued attributes

The OneWelcome Identity Platform validates that the primary attribute value true appears no more than once.

For multi-valued attributes, the OneWelcome Identity Platform always returns a type for any of the values, and applies other as default for the type.

For details about multi-valued attributes, see SCIM: Core Schema 1.1 - Multi-valued Attributes section.

SCIM common attributes

SCIM includes common attributes that are defined for all resources. Common attributes are not defined in any particular schema.

For more information about the SCIM common attributes, see https://tools.ietf.org/html/rfc7643#section-3.1.

Every SCIM resource, such as a user, includes the common attributes:

  • ID: The ID attribute is a unique identifier for a SCIM resource, such as a user, that is defined by the OneWelcome Identity Platform.

  • externalId: SCIM clients can set any value and should use unique values. The OneWelcome Identity Platform does not validate the uniqueness of this attribute.

  • meta: The metadata that SCIM specifies applies to the user resource as a whole. The metadata attribute includes the follow sub-attributes:

    • created: The OneWelcome Identity Platform always returns this sub-attribute.

    • Format: A dateTime (such as 2008-01-23T04:56:220Z) as specified in section 3.2.7 of the XML Schema Datatypes Specification.

    • lastModified: The OneWelcome Identity Platform always returns this sub-attribute as a dateTime, such as 2008-01-23T04:56:220Z, as specified in section 3.2.7 of the XML Schema Datatypes Specification.

    • location: The OneWelcome Identity Platform always returns this sub-attribute.

    • version: The OneWelcome Identity Platform always returns this sub-attribute.

    • attributes

For details about the SCIM common attributes, see SCIM: Core Schema 1.1 - Common Schema Attributes section.

SCIM core and OneWelcome Identity Platform attributes

SCIM allows for various user attributes and fields to be submitted to the OneWelcome Identity Platform:

  • Attributes for which the OneWelcome Identity Platform has some kind of semantics.

  • Attributes for which the OneWelcome Identity Platform has no semantics at all. The OneWelcome Identity Platform only stores and makes those available through interfaces.

Personal details

Attribute Multiplicity Sub-attribute Semantics Validations Schema
name 1 The OneWelcome Identity Platform returns both formatted and other sub-attributes. none SCIM core 1.1
formatted The OneWelcome Identity Platform derives the value from other name sub-attributes. This enforces consistency between all name sub-attributes. Furthermore, it facilitates a consistent presentation of a user's name in SCIM client applications and OneWelcome Identity Platform applications, like SelfService and ServiceDesk.
If a SCIM client does not provide any name sub-attributes, the OneWelcome Identity Platform allows a SCIM client to submit only a formatted name. If familyName, giveName, or middleName is submitted as well as a formatted name, the formatted name is overwritten with the generated value.
The format of the generated formatted name is configurable per locale (for example, Smith, John or John Smith).		 none SCIM core 1.1
familyName none SCIM core 1.1
givenName none SCIM core 1.1
middleName none SCIM core 1.1
honorificPrefix none SCIM core 1.1
honorificSuffix none SCIM core 1.1
nickName 1 The nickName is not used as a user's login name, because many people can share the same nickname, such as Joe. none SCIM core 1.1
profileUrl 1 A fully qualified URL - not validated. SCIM core 1.1
title 1 none SCIM core 1.1
photos * The OneWelcome Identity Platform allows SCIM clients to submit and retrieve any reference to a photo.
The OneWelcome Identity Platform does not set or use the values of this field.		 No validations
Canonical values photo and thumbnail are not validated.		 SCIM core 1.1
birthdate 1 The user's date of birth. The birthDate must be formatted as `DD/MM/YYYY``.
Validations on meaningful values (between 1-1-1900 and the current date) are not applied.		 OneWelcome Identity Platform schema extension
gender 1 The user's gender. Values can be either Male or Female. OneWelcome Identity Platform schema extension
placeOfBirth 1 No validations. OneWelcome Identity Platform schema extension

Contact Details

Attribute Multiplicity Sub-attribute Semantics Validations Schema
addresses * The canonical type values are work, home, and other.
The OneWelcome Identity Platform also supports the values invoice and shipping.		 Validations on canonical type values are not applied.
formatted The value is derived from individual address sub-attributes from the OneWelcome Identity Platform schema extensions. The format of the formatted address is configurable per locale. If the SCIM client doesn't submit sub-attributes, the SCIM client can submit a formatted address. If a the SCIM client provides one or multiple address sub-attributes, the OneWelcome Identity Platform overwrites the formatted address with the generated value. SCIM core 1.1
streetAddress The full street address can include the house number, street name, P.O. box, and multi-line extended street address information. This attribute can contain newlines.
In the OneWelcome Identity Platform implementation, the value can contain '\n', which is used as a separator between individual data within the streetAddress. In this case, the OneWelcome Identity Platform parses the field using the following logic:
{street}\n{streetnumber}\n{region}\n{postal_code}\n{city}
The OneWelcome Identity Platform does not copy the values of region, postal_code, and city as result of such parsing into the sub-attributes. The parsed values are shown as individual fields in the self-service interface (if configured).		 SCIM core 1.1
locality SCIM core 1.1
region SCIM core 1.1
postalCode No validation on whether the postal code actually exists, and on the consistency of the postalCode with the streetAddress. SCIM core 1.1
country No validation against ISO 3166-1 alpha 2 'short' code format. SCIM core 1.1
emails OneWelcome Identity Platform uses the primary value of this multi-valued attribute to send emails (such as with authenticating links, OTP, and so on).
The primary email addresses (by default) are used as the user identifier.
The OneWelcome Identity Platform does not canonicalize the values, which means that it does not convert them to lowercase. Email addresses should be submitted in lowercase.		 The 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](mailto:XXX@YYY.ZZZ)". It must contain one at symbol '@' and a period '.'.
Primary email addresses must be unique across all users within a tenant, because they're used as the identifier.
Email addresses within a single user must be unique, regardless of their type and whether they're primary.
By default, a primary email is configured as a mandatory attribute. With this default OneWelcome Identity Platform configuration, no identities can exist without a primary value for the emails attribute.		 SCIM core 1.1
phoneNumbers * The OneWelcome Identity Platform does not canonicalize to format as per RFC3966. It is a best practice to submit values that are compliant (such as, start with '+'), which allows mobile phone numbers to be used for sending SMS text messages for two-factor authentication (2FA) purposes.
Phone number is a multi-valued attribute in the SCIM interface. If the type is mobile and it is marked as primary, the OneWelcome Identity Platform can use the phone number to send an OTP as an SMS text message.
Phone numbers can be used as user identifiers if their type is mobile.		 The canonical type values of work, home, mobile, fax, and pager are validated. SCIM core 1.1
ims * No validation on type, because canonical values are not specified. SCIM core 1.1

Authentication and security attributes

Attribute Multiplicity Sub-attribute Semantics Validations Schema
userName 1 Username can be used for identification during login (if configured).
Username is case-sensitive.
The username value should not contain values that are copied from other identifying user attributes.
When the username is submitted through SCIM or chosen by the user during registration or activation, it gets the trustLevel verified and can be shown on self-service screens. In other situations, it has the same value as id and does not have the verified trustLevel.		 The OneWelcome Identity Platform validates the uniqueness and presence of this attribute.
When tenants are used, uniqueness is validated within the user's tenant.
id 1 - The OneWelcome Identity Platform generates the value, which is typically not known to the user.
The ID can be used for identification during login (if configured).
The ID value never changes during the lifecycle of the user's identity.		 none SCIM core 1.1
externalId 1 - The external system determines the format of a typical value. none SCIM core 1.1
segment 1 - A segment is a tenant, which is a subset of users that are contained within a OneWelcome Identity Platform environment. Users in a tenant can be managed independently of users in other tenants within the same OneWelcome Identity Platform environment. All user identifiers are unique within a tenant. There is often a one-on-one relationship between a tenant and a brand.
After a tenant is set for a particular user, it cannot be updated using a PUT or PATCH operation. You cannot transfer a user from one tenant to another.		 The OneWelcome Identity Platform pre-configures possible tenants (segment-values), and other values are rejected.
The OneWelcome Identity Platform validates a user's tenant against the list of configured tenant.		 OneWelcome Identity Platform user extension
active 1 - The value true indicates that the user can log in. The value is derived from the more granular state attribute. It is a read-only attribute. none, read-only SCIM core 1.1
state 1 - The state indicates the status of a user within the OneWelcome Identity Platform. It allows for a more granular identity lifecycle than implied by the SCIM-specified active attribute, which is a boolean value.
Possible values are ACTIVE, INACTIVE, BLOCKED, WITHDRAWN, or GRACE.
The value is accepted in uppercase ("state": "INACTIVE").
When a user is created with the INACTIVE status, the OneWelcome Identity Platform can initiate an activation process, depending on your configuration.
When a block is applied on a user that has the INACTIVE status, the new status is WITHDRAWN.		 none OneWelcome Identity Platform user extension
password 1 - Passwords can be provided via SCIM. When a user is created, typically a password is included, but this is not necessary.
When a user is updated with PUT without a password attribute, the password in the OneWelcome Identity Platform remains unchanged.
Securely hashed passwords can be submitted 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 is used for password validation.
When the authoritative source sets the password through SCIM, it might have communicated the password to the user, which is indicated by setting the trust level to validated. Passwords that don't have TrustLevel validated can be considered as unknown to the user and are essentially non-existent, since they are not used to log in. However, usage of this semantics is optional.		 Passwords are validated against password complexity rules. Updates with passwords that do not comply with password complexity rules are rejected. SCIM core 1.1
x509Certificates * - The OneWelcome Identity Platform does not use this attribute. It allows only storage and retrieval of values by SCIM clients. none SCIM core 1.1
lastSuccessfulLogin - Read-only field that indicates the date and time of the user's last successful login. Not applicable OneWelcome Identity Platform user extension
blocks Multiple blocks can be applied to a single user. When one or multiple blocks are placed on the user, that user cannot be active. Identities without blocks can be inactive or active. OneWelcome Identity Platform user extension
- userId This is the user ID of the Service Desk user that placed the block. No validations are applied, any userId value can be submitted. When the Service Desk application is used to block a user, the UUID of the Service Desk user's identity is submitted. OneWelcome Identity Platform user extension
- reason This sub-attribute indicates the reason for placing a block on the user. No validations are applied. OneWelcome Identity Platform user extension
- date The date on which the block was placed on the user. If no date is provided, the OneWelcome Identity Platform generates the value when the block is set. When a block is placed simultaneously with the creation of the user (as part of the POST operation), the date is the same as the create date of the user. OneWelcome Identity Platform user extension

User attributes

Attribute Multiplicity Sub-attribute Semantics Validations Schema
displayName 1 - The OneWelcome Identity Platform does not use this attribute. It allows only storage and retrieval of values by SCIM clients. none SCIM core v1.1
preferredLanguage 1 - A SCIM client can set this value, but users can also set the value through self-service.
If the OneWelcome Identity Platform updates the value, the value is compliant with the SCIM specification (such as en_US).		 No validations are applied. SCIM clients should submit values in compliance with SCIM specifications. SCIM core v1.1
locale 1 - The OneWelcome Identity Platform does not interpret or set this field. SCIM clients can set and retrieve values. No validations. SCIM clients should submit values in compliance with SCIM specifications. SCIM core v1.1
timezone 1 - The OneWelcome Identity Platform does not interpret or set this field. SCIM clients can set and retrieve values. No validations. SCIM clients should submit values in compliance with SCIM specifications. SCIM core v1.1

Authorization attributes

Attribute Multiplicity Sub-attribute Semantics Validations Schema
groups * - This attribute is not supported, and the Group endpoint is not supported. none
entitlements * - No semantics are applied. SCIM clients can set and retrieve any value. none SCIM core v1.1
roles * - No semantics are applied. SCIM clients can set and retrieve any value. none SCIM core v1.1
userType 1 - No semantics are applied. SCIM clients can set and retrieve any value. none SCIM core v1.1

Note

The full user representation example in SCIM: Core Schema 1.1 contains a few errors:

  • User attribute groups is not shown with the sub-attribute type (direct or indirect)
  • User attribute phonenumbers is not shown with the sub-attribute primary.

On this page