Extending the Workspace ONE Application in Okta for Additional Attributes

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

  1. Open the Workspace ONE Application in Okta
  2. Click on the Provisioning Tab
  3. Click on ” Go to Profile Editor”
  1. Click Add Attribute
  1. Enter the Display Name, Variable Name and External Name exactly how it is created in WS1 Access (ie. objectGUID).
  2. Enter the custom schema as we noted above. Make sure your tenant name is included correctly.
  3. Check the user personal checkbox under Scope
  1. Click Save
  2. Repeat this process for all the attributes you want to provision.
  3. Click on Mappings
  4. Click on the Okta User to VMware Workspace ONE Tab (Note: My image below is slightly different as I’ve renamed my application)
  1. Select the correct attribute to map. In my environment, I’m mapping the ExternalID to the objectGUID
  1. Click Save Mappings
  2. Click Apply Updates Now

13 thoughts on “Extending the Workspace ONE Application in Okta for Additional Attributes

  1. 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?

    Like

      1. 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”
        }
        }

        Like

  2. 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

    Like

      1. 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.

        Like

  3. 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”.

    Like

    1. 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”
      }
      }
      }

      Like

    2. 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”
      },

      Like

  4. Hi Steve,
    I followed the instructions into this article and it helped me to sync attributes from Okta into Workspace One Access. Nicely done. 🙂

    However, now that WK1 Access is aware of those new attributes, how can I sync them to Workspace One UEM (Airwatch). The Airwatch Provisining apps, doesn’t allow me to add custom attributes. There is a drop down list with pre-defined value, and those new attributes are not available from that list.
    Look like Workspace One UEM support only 5 custom attributes, I was hoping to be able to use one of those to sync the value I need that is now available in Workspace One Access.

    Any hints you can gave me to be able to sync those newly custom attributes to Workspace One UEM ?

    Like

      1. Thank Steve for this fast answer, I will keep looking and will report here if I found a solution to this.
        It is strange that Workspace One Access doesn’t have this capability to sync users attributes to one of their own apps Workspace One UEM. Custom attributes is sometime needed to create resources profiles or scripts.

        Like

Leave a comment