Lessons learned on the digital workspace journey with Workspace ONE

Workspace ONE allows you to present the exact user experience your use case requires. One of the things that Workspace ONE UEM does a great job with is interacting with various API's across all the major operating systems. There can be times when you might wish to interact with those API's directly. Some examples of the types of API's that could be helpful would include: Google's  Play EMM API  or the  Android Management API . A scenario where this could be useful is when you want to retrieve a set of data that isn't currently captured by Workspace ONE UEM. If there is something you wish Workspace ONE captured, don't hesitate to submit a  Feature Request  on the crowdsourced portal. In the meantime, this blog will cover how to update the access token used with Android Enterprise, and how to retrieve the access token with Fiddler.  Configure on-premise environment to proxy traffic: Open Fiddler, and make sure it is capturing traffic. For reference on how to confi

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

Mobile threat detection and response is an area of ever-growing importance, as the world finds themselves accessing sensitive resources on devices everywhere. Application, identity or device management only offers so many protections to the assortment of threats users are faced with.  Digital Workspace products like Workspace ONE and Zimperium's zIPS compliment each other, and offer an additional level of compensating controls, specifically for mobile threats. These capabilities allow your organization to detect threats you might not have had visibility of, let alone the ability to mitigate. Zimperium focuses on being best-in-breed in MTD, and it shows. In 2019; Zimperium would be the first MTD to be FedRAMP authorized, partner with the VMware to join the Trust Network, and selected by Google to join the App Defense Alliance.  To make this integration possible, you must first, thank your CISO, and then integrate Zimperium's zConsole with Workspace ONE UEM. In this post

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