In Workspace ONE Access, you might have configured additional attributes and would like to populate those attributes from your source of truth such as Okta.
Perhaps its a single attribute:
Or maybe you have many attributes:
When these attributes are created in Workspace ONE Access, they are created in a custom schema. The schema is in the following format:
urn:scim:schemas:extension:workspace:tenant:TENANT:1.0
The TENANT will be replaced by your actual tenant name, such as “urn:scim:schemas:extension:workspace:tenant:dsas:1.0”.
If you are unsure, I recommend you use Postman to query the user using the GET API. ie. {{tenant_url}}/SAAS/jersey/manager/api/scim/Users?filter=userName%20eq%20%22steve%22
Here is a sample Postman that I’ll use as my guideline. Note – this step is not required but I will use it to demonstrate my approach.
Now that we know how attributes are stored in Workspace ONE Access, lets configure Okta to send these attributes
- Open the Workspace ONE Application in Okta
- Click on the Provisioning Tab
- Click on ” Go to Profile Editor”
- Click Add Attribute
- Enter the Display Name, Variable Name and External Name exactly how it is created in WS1 Access (ie. objectGUID).
- Enter the custom schema as we noted above. Make sure your tenant name is included correctly.
- Check the user personal checkbox under Scope
- Click Save
- Repeat this process for all the attributes you want to provision.
- Click on Mappings
- Click on the Okta User to VMware Workspace ONE Tab (Note: My image below is slightly different as I’ve renamed my application)
- Select the correct attribute to map. In my environment, I’m mapping the ExternalID to the objectGUID
- Click Save Mappings
- Click Apply Updates Now
Steve The Identity Guy 
Hey Steve,
When going through this guide, this does not appear to be the case with Okta.
For example I have already created the custom attributes within WS1 Access. When I then poll the API via Access to obtain the user schema and validate they are there, they do not show up. However – I also cannot add custom attributes into the Okta Identity Provider or the Otka Directory within WS1 Access. The button does not appear in the directory to choose custom attributes.
How were you able to modify / add custom attributes into the Okta Directory?
LikeLike
Andrew, if I’m understanding your issue correctly. You need to add the attributes in Identity & Access Management -> Setup -> User Attributes.
LikeLike
We already have the attributes created, and they are listed under
/SAAS/jersey/manager/api/connectormanagement/directoryconfigs/UUID/userattributedefinitions
but not populating into the user filter schema’s listed there.
In Okta we see the following error:
Errors reported by remote server: Resource ‘User’ is malformed: Attribute /saas/jersey/manager/api/connectormanagement/directoryconfigs/UUID/userattributedefinitions:manager is not defined for resource User
However when looking at the userattributedefinisions schema, I can see that listed here:
{
“extended”: false,
“permanent”: false,
“required”: false,
“storageType”: “STORAGE_PERSISTENT”,
“label”: “manager”,
“uuid”: “omit”,
“sensitive”: false,
“name”: “manager”,
“readOnly”: false,
“_links”: {
“self”: {
“href”: “/SAAS/jersey/manager/api/vidm/userattributedefinition/omit”
}
}
LikeLike
I realized I made a mistake in the above, but even specifying the tenant or the OrgID we are still receiving errors:
Errors reported by remote server: Resource ‘User’ is malformed: Attribute urn:scim:schemas:extension:workspace:tenant:OGID:1.0:manager is not defined for resource User
LikeLike
It should be the tenant name in lower case you as see in my screen shots above
LikeLike
Our WS1 Access tenant name is the same as our OGID of the cnXXXX root.
When pulling schemas we have:
“urn:scim:schemas:core:1.0”,
“urn:scim:schemas:extension:workspace:tenant:[name:[tenantletter][tenantnumbering]]:1.0”
“urn:scim:schemas:extension:workspace:1.0”,
“urn:scim:schemas:extension:enterprise:1.0”,
“urn:scim:schemas:extension:workspace:mfa:1.0”
So pulling that second line is what I am listing as OGID as the root of the OG for the CN instance is the same as the tenant name for the Access portal.
“urn:scim:schemas:extension:workspace:tenant:[name:[tenantletter][tenantnumbering]]:1.0”, (this is where OGID was mentioned above)
So we do have tenant name assuming what we are looking at is the same as what you are referring to. I don’t see anything in any schema that has a tenant name of only lettering or a more explicit name.
LikeLike
Andrew – Take a look at this blog and it will dump the whole output to the screen: https://theidentityguy.ca/2020/11/10/how-do-i-see-all-the-ws1-access-user-attributes/
LikeLike
Hey Steve,
These are the same results I was viewing via Postman.
Happy to send you the results via email or discuss more, but I can show you what I am talking about, but, ultimately… I am seeing the same thing – where even with a custom attribute added in Access, it doesn’t appear to be allowed or usable in an “Other” type of Directory listing:
{
“schemas”: [
“urn:scim:schemas:core:1.0”,
“urn:scim:schemas:extension:workspace:tenant:TENANTINSTANCE:1.0”,
“urn:scim:schemas:extension:workspace:1.0”,
“urn:scim:schemas:extension:enterprise:1.0”,
“urn:scim:schemas:extension:workspace:mfa:1.0”
],
“externalId”: “objectIdentifier”,
“active”: true,
“userName”: “andrew”,
“id”: “UID”,
“meta”: {
“created”: “2021-10-15T09:39:38.322Z”,
“lastModified”: “2021-10-21T18:18:24.554Z”,
“location”: “https://TENANTINSTANCE.vmwareidentity.de/SAAS/jersey/manager/api/scim/Users/UUID”,
“version”: “W/\”OMIT\””
},
“name”: {
“givenName”: “Andrew”,
“familyName”: “OMIT”
},
“emails”: [
{
“value”: “andrew@domain.com”
}
],
“groups”: [
{
“value”: “LOTS OF GROUP UUIDS”,
“type”: “direct”,
“display”: “LOTS OF GROUP NAMES”
},
],
“roles”: [
{
“value”: “ADMINUUID”,
“display”: “Administrator”
},
{
“value”: “USERUUID”,
“display”: “User”
}
],
“urn:scim:schemas:extension:workspace:1.0”: {
“internalUserType”: “PROVISIONED”,
“userStatus”: “1”,
“domain”: “domain.com”,
“userStoreUuid”: “UUID”,
“userPrincipalName”: “andrew@domain.com”
}
}
If I use TENANTINSTANCE (which as far as I can see is the equivalent of tenant name), I receive the above error I was describing:
Errors reported by remote server: Resource ‘User’ is malformed: Attribute urn:scim:schemas:extension:workspace:tenant:TENANTINSTANCE:1.0:manager is not defined for resource User
Even though we have both manager and managerEmail created as a custom attribute under “Identity & Access Management -> Setup -> User Attributes”.
LikeLike
To validate that from the schema / attributes (and only taking the relevant ones I am discussing here)
/SAAS/jersey/manager/api/connectormanagement/directoryconfigs/TenantUUID/userattributedefinitions
{
“items”: [
{
“extended”: false,
“permanent”: false,
“storageType”: “STORAGE_PERSISTENT”,
“label”: “manager”,
“required”: false,
“uuid”: “UUID1”,
“sensitive”: false,
“name”: “manager”,
“readOnly”: false,
“_links”: {
“self”: {
“href”: “/SAAS/jersey/manager/api/vidm/userattributedefinition/UUID1”
}
}
},
{
“extended”: false,
“permanent”: false,
“storageType”: “STORAGE_PERSISTENT”,
“label”: “managerEmail”,
“required”: false,
“uuid”: “UUID2”,
“sensitive”: false,
“name”: “managerEmail”,
“readOnly”: false,
“_links”: {
“self”: {
“href”: “/SAAS/jersey/manager/api/vidm/userattributedefinition/UUID2”
}
}
},
((( Base attributes )))
],
“_links”: {
“self”: {
“href”: “/SAAS/jersey/manager/api/connectormanagement/directoryconfigs/TenantUUID/userattributedefinitions”
}
}
}
LikeLike
I just tried it again in my environment. I used Postman to populate the attribute. Note the attribute will only show in postman if its populated:
“urn:scim:schemas:extension:workspace:tenant:dsas:1.0”: {
“awuser”: “stevedsa”,
“objectGUID”: “f474668800-4582-9bb7-07e223434a6817b”,
“managerDN”: “CN=Auston Mathhews,CN=Users,DC=1dsavm,DC=com”
},
LikeLike