Lessons learned on the digital workspace journey with Workspace ONE

Applications often have secrets that should not be hardcoded in the source code. This poses a challenge for developers, as ProGuard can change classes and method names, it won't help with secrets. Examples of secrets that can be removed from application source code include an API key or a OAuth refresh token. Another capability is for the MDM to dynamically deliver values to the application, such as the current logged in user, device serial number, or organization group. Google has made it more challenging to access non-resettable device identifiers like the serial number in recent years, and this remains a viable solution to provide non-resettable device identifiers (and other values) to applications running on the device. So how do we do it? Workspace ONE UEM can deliver profiles to devices. Profiles can configure a number of settings, in addition to delivering key/value pairs to your applications.  Google refers to these key/value pairs as Managed Configurations, aka application

Digital workspace solutions often require consuming other services. When doing so, you may work with things like; REST API endpoints, Webhooks, gRPC, GraphQL - the list goes on. You can interact with these in a number of ways, but one way I've come to appreciate is with Java. It has been especially helpful when I've wanted to work with libraries like Appium, Selenium, OKHttp, or the Workspace ONE UEM SDK in a workflow. With that, I thought it would be helpful to share how to work with Workspace ONE UEM API's using Java. In this blog post, we will cover; Basics of JetBrain's IntelliJ IDE, touching on Apache Maven Using  Square's OkHttp   library  to call Workspace ONE UEM API's Why Java? Java is used by many and supported by most (Docker, Kubernetes, static code analysis tools, cloud service providers, Android, Windows, macOS, Tanzu Application Service, etc). Many languages compile to j ava

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

A use case I am involved in required remotely delivering Zimperium zIPS, a mobile threat detection and response security product, to Android Enterprise devices with Workspace ONE UEM. Zimperium is an incredible mobile security product, which I will discuss more in upcoming blog posts. The way Workspace ONE and Zimperium compliment each other is ideal for securing devices running (Android and iOS supported). First we need to deliver zIPS; and this will cover the delivery and activation of zIPS on an Android Work Managed device with Workspace ONE UEM Product Provisioning. For zIPS to secure a device, report threats back to Zimperium's zConsole and eventually Workspace ONE Intelligence; zIPS requires activation on each device. It sounds daunting, especially because it isn't just delivering an apk file and managed configuration. If you have a fleet of 15,000 or 150,000 devices; you wouldn't want to visit each point-of-sale kiosk, in-flight entertainment system, medical devic