The first step in implementing SCIM for your app is to define a JSON schema that represents your user based on your app’s requirements. You’ll provide this schema to OneLogin as your SCIM JSON template. This template will tell the OneLogin SCIM provisioning service how to provision user values to your app. Where to start? Take a look at the SCIM-compliant OneLogin Core User Schema, which contains the minimum set of attributes required by the OneLogin provisioning service:
OneLogin Core User Schema
{
"schemas": [
"urn:scim:schemas:core:1.0"
],
"userName": "{$parameters.scimusername}",
"name": {
"givenName": "{$user.firstname}",
"familyName": "{$user.lastname}",
"formatted": "{$user.display_name}"
}
}A few things to note about this schema:
It is an abbreviated version of the standard SCIM User Schema.
Notice that the
userNamevalue is brought in using a parameter. For more info about parameters in the schema template, see Using Parameters in the Schema Template.OneLogin will set the
$user.display_namevalue as a concatenation of thefirstnameandlastnamevalues. If you need more than the minimum set of attributes, consider using the SCIM-compliant OneLogin Enterprise User Schema:
{
"schemas": [
"urn:scim:schemas:core:1.0",
"urn:scim:schemas:extension:enterprise:1.0"
],
"userName": "{$parameters.scimusername}",
"name": {
"familyName": "{$user.lastname}",
"givenName": "{$user.firstname}",
"formatted": "{$user.display_name}"
},
"emails": {
"value": "{$user.email}",
"type": "work",
"primary": true
},
"title": "{$parameters.title}",
"urn:scim:schemas:extension:enterprise:1.0": {
"department": "{$parameters.department}",
"manager": {
"managerId": "{$parameters.external_manager_id}",
"displayName": "{$user.manager_firstname} {$user.manager_lastname}"
}
}
}A few things to note about this schema:
It includes the OneLogin Core User Schema, plus the
emails,title,department, andmanagerattributes.The
managerattribute is brought in using the SCIM Enterprise User Schema Extension.The
managerIdis brought in using a parameter. For more info about parameters in the schema template, see Using Parameters in the Schema Template.
Attribute relationships
Integrations to other systems
Other logic that we'll build into your app's connector
- `"userName": "{$parameters.scimusername}"` in the OneLogin Core User Schema Once you contact OneLogin to publish your app, we will set up a parameter that will populate the `userName` value with the user's email value or another value of your choice. We recommend that you set this attribute in this way so that at least one of your schema values will be populated via a parameter. This will enable the OneLogin SCIM provisioning service to automatically update provisioned users going forward. For example, if the user's `familyName` value changes in OneLogin, the OneLogin SCIM provisioning service can automatically update the user's `familyName` value in your app.
- `"managerId": "{$parameters.external_manager_id}"` in the OneLogin Enterprise User Schema OneLogin will derive this value programmatically based on attribute relationships.
{
"schemas": [
"urn:scim:schemas:core:1.0",
"urn:scim:my:custom:schema"
],
"userName": "{$parameters.scimusername}",
"name": {
"familyName": "{$user.lastname}",
"givenName": "{$user.firstname}",
"formatted": "{$user.display_name}"
},
"urn:scim:my:custom:schema": {
"vi_or_emacs": "{$user.custom_fields.vi_or_emacs}"
"tabs_or_spaces": "{$user.custom_fields.tabs_or_spaces}"
}
}In the example above, the template includes urn:scim:my:custom:schema and $user.custom_fields.<value> to bring in custom SCIM values vi_or_emacs and tabs_or_spaces.
Note: Left as-is, this will not work unless your customer happens to have the exact same user attribute values in their user directory. Part of the work that OneLogin will do to turn your schema into a permanent connector in our catalog will be changing these custom fields into
parameters.<value>directives. This will ensure that customers can map values from their user directory into your application. If you do use custom fields in your SCIM implementation, please let OneLogin know. We’ll ask you to tell us about how you want them to be used so that we can accurately configure your connector to work with parameters. A few more important notes about custom attributes:
A OneLogin Developer account will enable you to create custom attributes.
When defining your custom attribute names, do not use spaces or dashes. Use underscores or camelcase instead to help with name readability.
Including custom attributes in your user schema requires that your app users belong to organizations that subscribe to the OneLogin Unlimited plan.
Consider the customer's ability to provide a value for a custom attribute. It may be useful to your app, but if you make it required, will it preclude customers from being able to uptake your app?
| SCIM User Schema Attribute | Proposed OneLogin $user Attribute | OneLogin Schema |
|---|---|---|
|
| Core, Enterprise |
|
| Core, Enterprise |
|
| Core, Enterprise |
|
| Core, Enterprise |
| Parameter: Groups | Core, Enterprise |
|
| Enterprise |
|
| Enterprise |
| Parameter: Manager | Enterprise |
|
| Enterprise |
| $parameters.department | Enterprise |
|
| Add, if needed |
|
| Add, if needed |
|
| Add, if needed |
|
| Add, if needed |
|
| Add, if needed |
|
| Add, if needed |
|
| Add, if needed |
Other Available $user Attributes
| Attribute | Description |
|---|---|
| Date and time at which the user's status was set to |
| Company that the user works for. |
| ID of the directory (Active Directory, LDAP, for example) from which the user was created. |
| Synchronized from Active Directory. |
| Number of sequential invalid login attempts the user has made that is less than or equal to the Maximum invalid login attempts value defined on the Session page in OneLogin. When this number reaches this value, the user account will be locked for the amount of time defined by the Lock effective period field on the Session page and this value will be reset to 0. |
| Date and time at which an invitation to OneLogin was sent to the user. |
| Date and time of the user's last login. |
| Date and time at which the user's account will be unlocked. |
| Synchronized from Active Directory. |
| OpenID URL that can be configured in other applications that accept OpenID for sign-in. |
| Date and time at which the user's password was last changed. |
| Synchronized from Active Directory. |
| Synchronized from Active Directory. |
Have a Question?
Found a problem or a bug? Submit a support ticket.
Looking for walkthroughs or how-to guides? Check out our Knowledge Base.
Have a product idea or request? Share it in our Ideas Portal.