Workspace ONE - Okta Integration Part 3: SCIM Provisioning

Workspace ONE - Okta Integration Part 3: SCIM Provisioning

For updates on this blog and other blogs: Follow @SteveIDM

This blog has been moved to

 

https://TheIdentityGuy.ca

Comments

You have noted that update users should not be selected. Does this mean the SCIM integration is not capable of updating changes to a user?

It will be supported at a future date.

Under Step 3, where does this go exactly? Which tab in Postman?  - there doesn't seem to be a place under "Headers"...
   

  1. "type":"OTHER_DIRECTORY",   
  2. "domains":["Okta.com"],   
  3. "name":"Okta Universal Directory"   
  4. }   

Click on Body.

You might have to hit raw to provide an input to enter the text.

Hi Steve,

Thanks much for your previous response. I have another question about the entire Postman section. Can you explain exactly what this piece is accomplishing & why it's necessary? Is it just to 'Create an "Other" Directory for your Okta Users'? Is the issue that this is something that is not possible via the Workspace ONE UI & only through API?

Also, have you heard any news on from Okta? I see that there is a Workspace ONE app in the OIN with SAML but it doesn't appear to have provisioning. I also reached out to my Okta rep to see if he has any further info.

Thanks again,

Eric

Correct. Its just not available through the UI yet so we have to use the API for the initial setup. Eventually, it will all be done via the UI.

As far as provisioning in the Okta application, that is coming.

The current VMware Workspace One integration in Okta does not have provisioning support. Has this functionality been removed?

The functionality is there in preview. There are some cases where the provisioning label is not there but the functionality is definitely there in Preview.

Is it possible to map additional attributes from Okta to WS1 access, and what are the steps? There doesn't seem to be schema integration between the Okta app and WS1 Access when trying to add additional attributes to the profile editor in Okta for the WS1 app. I am not clear if it is supported and what are the correct values for the external namespace in WS1 access.

Another question. what is the impact of username (email address) changes in Okta since the update feature is not supported in the SCIM integration.

Its possible to map additional attributes. Depending if its a core SCIM 1.1 attribute vs a custom schema attribute. I do plan on writing another blog on adding more attributes.

Update is now supported with the SCIM app.

Is it possible to provide an example how I can query the list of all WS1 attributes and extract the external name and external namespace that is used in the Okta when adding additional attributes

The easiest way would be to query the user in Postman to grab the attribute names and namespace.

Where did the Workspace ONE Access externalID attribute come from when provisioning with SCIM from Okta?

When synchronizing Okta with Active Directory, how do I add a custom attribute to provision the Active Directory ObjectGUID attribute from Okta to the externalID attribute in Workspace ONE Access?

Ultimately, I'm thinking about provisioning from the AirWatch Provisioning app to UEM and linking it to the ImmutableID attribute of the AzureAD integration with UEM's directory service.

The ExternalID is automatically pre-populated by Okta using their internal identifier. I do like your thinking here. One of the challenges is that Okta does not allow you to sync the ObjectGUID is its native format. It will always sync the hash of the objectGUID (which works for Office 365).  I don't see any value in use the hashed value of the ObjectGUID as the external id (assuming its possible to override the value which I don't believe I tried).

StevenDSa

Thank you for answering.

I'm Looking forward to your blog about on adding more attributes too.

Great post, Steve!
After following it and making sure that every user has a GUID attached to it, I get a rather unhelpful "Internal Server Error" after each attempt.

The "Audit Events" report inside WS1 Access doesn't bring that much new information either.

Would you know where I could find more details about what I did wrong with my integration?

Agreed that is not a helpful error. Did you follow my other blog on configuring the A/W Provisioning adapter? Workspace ONE - AirWatch Provisioning App

Thanks Steve! I did, and, in hindsight, should have probably posted my comment on that post rather than this one Smiley Happy

In our case, our WS1 Access and WS1UEM still have some settings left from previous integration attempts through native integration.​ Can you confirm that this kind of integration isn't needed to get the A/W Provisioning adapter working?

In WS1UEM > Settings > System > Entreprise Integration > Directory Services > User tab, do those settings matter? (default settings have been replaced during previous attempts, in our case)

Thanks in advance,

Martin

You are correct that in order to provision users from WS1 Access to UEM you don't need to complete those steps, however they are important for other aspects not related to the provisioning.

Here are some key things, make sure under Directory Services in UEM that NONE is selected for the directory (at the top OG) and SAML is configured.

Also under Devices and Users -> General -> Enrollment, make sure the Directory authentication mode is enabled.

Version history
Revision #:
2 of 2
Last update:
‎06-15-2021 07:30 AM
Updated by:
 
Contributors