One of the projects I am currently working on involves Workspace One Access (formally VMware Identity Manager) and configuring a 3rd Party Identity Provider for Identity Federation. As with anything, using the UI for the first time to validate the workflow is perfectly fine for me but after that, I normally prefer to automate, especially as I was rebuilding this particular setup a few times. I saw that Workspace One Access (WSO Access) had a REST API but I was surprised that there were no APIs for actually managing the configurations.
I figured before giving up, I should see at least see how the UI was performing these operations as "some API" should exists and started up one of my favorite browser tools Chrome Developer Console to inspect the HTTP requests. I came to learn there were an additional set of "Jersey" APIs (no background on the Jersey name, but its part of the API URI) that might do exactly what I was looking for. After a bit of trial/error, I was able to fully automate the creation of both a WSO Access Directory as well as 3rd Party Identity Provider.
Initially, I was using the HZN and X-CSRF tokens found from my browser session which was not very user friendly. However, a few EUC folks found out I was looking into this and thanks to Sascha Warno, a Customer Success Architect over in EUC, I found out that I could simply create a new OAuth Client Credential from WSO Access and use that with these "Internal" APIs. Putting all this together, I created a small PowerShell Module VMware.WorkspaceOneAccess.psm1 that will enable others to easily automate these configurations with ease!
The module contains the following 8 functions which were developed to support my particular use case.
- Connect-WorkspaceOneAccess - Given Client ID and Client Secret, it returns Access Token which is then used by the other WSO Access functions
- Get-WSDirectory - Returns all WSO Access Directories
- Get-WSIdentityProvider - Returns all WSO Access Identity Providers
- Get-WSOrgNetwork - Returns all WSO Access Org Networks
- New-WS3rdPartyIdentityProvider - Creates a new 3rd Party Identity Provider
- New-WSJitDirectory - Creates a new Just-In-Time (Jit) Directory, which is not possible today via UI
- Remove-WS3rdPartyIdentityProvider - Removes a 3rd Party Identity Provider
- Remove-WSDirectory - Removes Directory
For other types of WSO Access configurations, folks can use a simliar technique to identity the specific API used. One bit of advice is to pay attention to the Accept and Content-Type headers, it looks like each API defines its own type which initially had threw me off. I hope our EUC team will consider making these additional WSO Access APIs available and public, which means they will be fully documented and supported.
Disclaimer: As these are Internal APIs, they are not officially supported by VMware and there are no guarantees these will continue to work from release to release. Please use at your own risk.
Step 1 - Create a new OAuth client credential in WSO Access by following the instructions found here. Make sure to save off your client app and secret during the creation as that will be required to exchange for an access token to connect to the WSO Access API
Step 2 - Import the WSO Access PowerShell Module
Import-Module ./VMware.WorkspaceOneAccess.psm1
Step 3 - Use the Connect-WorkspaceOneAccess function and provide the following information: Tenant (FQDN of the WSO Accesss Instance), ClientID and ClientSecret from Step 1. If everything was successful, you should see output like the following.
Step 4 - Next we need to create a Directory before we can associate that with a new 3rd Party Identity Provider. For my use, I need to have a Just-In-Time (Jit) Directory which is not possible when using the WSO Access UI. Luckily we can automate that and we will be using the New-WSJitDirectory function and provide both a name and domain as shown in the screenshot below.
In addition to the output to confirm the operation was successful, we can also head over to WSO Access UI to confirm our new Jit Directory.
Step 5 - Lastly, we will use the New-WS3rdPartyIdentityProvider function to create our Identity Provider. You will need to provide a Name, the Directory Name from Step 4, the Network Name (default is ALL RANGES) and path to the Federation Metadata file.
If everything completed successfully, you should now have a new 3rd Party Identity Provider created in WSO Access!
I seem to get the following error. I ensured the my client id and secret is correct and the Remote App is enabled:
{"error":"invalid_client","error_description":"Invalid client info associated with this client."}