Lessons learned on the digital workspace journey with Workspace ONE

When it comes to accessing API's and securing your digital workspace, we have options. When accessing Workspace ONE API's, we have options when securely interacting with them; like using base64 encoded credentials, or  OAuth  access tokens (versions 2001 and newer). In a previous blog post, we covered how to store sensitive credentials used to access Workspace ONE API's with a config.ini file. This approach works, and while ACL's can limit accounts that can read data at rest; organizations may still prefer to not store credentials in something like json or a old school ini file.  Today, we'll provide you with your daily dose of uplifting imagery from Hawaii, code to retrieve credentials at runtime, store base64 encoded credentials in memory during execution, and access Workspace ONE API's with the credentials. This way, you can simply hand your code off to operations, sit by the beach, hop on a trail, and enjoy your time in Hawaii. Waimea Canyon, the G

Organizations that use custom built tools to access API's can approach this in a variety of ways. It is not uncommon to find tools developed with sensitive data contained within the source code itself. PowerShell scripts are a great example of where we can find sensitive data leaking. These scripts come with the best of intentions, but can accidentally contain the keys to the kingdom. We’ll look at how I use a config.ini file to access a funny environment we’ll call https://Kauai.ryanpringnitz.com, but b efore we proceed, cue the mood boosting visuals... Storing sensitive data in code makes it difficult to commit code to a source version control system Bitbucket, GitHub, TFS, etc), as it would be insecure. It can even be against company policy to store sensitive data this way. By storing the sensitive information in a config.ini file; you can more easily present the code in a screen sharing session (maybe in a sprint demo), or commit your code to remote a repository.  Ex

There is a real and immediate need for every organization to be able to quickly react to zero-day vulnerabilities or new application releases with features requiring immediate and precise cut-overs. The threat landscape is wider than ever, while the frequency of new application builds in a world of CI/CD pipelines decreases from days to hours; and everything supporting the business has exacting requirements that need to be met.  Workspace ONE and the EUC product line-up is really well equipped to handle any digital workspace use case on any major platform. When you offer all that with API's to manage identity, access management and secure edge services; you have API's for everything to provide secure remote access to resources.  What has been interesting to watch over the years is the utility, broad-appeal, varied-price points and proven capabilities of the Android OS. As the OS has matured from the era of Jelly Bean, KitKat and Lollipop; the number of use cases supported b

Usage and adoption of REST API's continues to increase, as the need to integrate services over the web is greater than it has ever been. One of the most frequently used API endpoints in Workspace ONE UEM is  /API/mdm/devices. This API endpoint accepts a variety of parameters that help filter your result set to only include what is necessary, and reduce the payload size returned in the HTTP response. We will take a look at a quick example of how to perform this HTTP Request with Powershell and invoke-restmethod. Below is a simple Powershell script I was able to create for this example. Make sure to include base64 encoded credentials in a folder (c:\creds\b64.txt in the example), and to update the $apiKey object with an API key. When reviewing the results from the object with $getDevices.Devices, the following is stored in the variable: This API really gives you quite a bit to work with, and VMware is really good about offering developers an assortment of APIs to report