Secure podcasting with ZPA

(Andy Logan) #1

Having worked at many different technology companies over my career, I always find it instructive to see how a technology is used by the company that developed it. I thought it might be interesting for our community to see one of the ways we are using ZPA to solve our own problems.

For me the issue came in the form of a secure podcast to our employees. Our sales teams spend significant amounts of time on planes and in their cars, as does our Silicon Valley HQ team when commuting to the office. Giving them an opportunity to catch up on news, product updates, customer stories, events, and other things that might get missed in a sea of email seemed like an easy win for our team.

When I was first asked to look into secure podcasting there didn’t really seem to be a good solution to the problem. As a heavy podcast listener, I have never authenticated to listen to podcasts. I simply hit the iTunes store, find my podcast, and subscribe. I knew paid and authenticated podcasts existed but hadn’t looked into the mechanics of how they work. It turns out what you need to do is embed a username and password into the URL of the podcast. Now this has a number of drawbacks as I’m sure you can imagine:

  • I would need to rotate the password on some regular basis as people leave the company, this means listeners have to re-subscribe again every time I do this. I’m guessing even with a really compelling podcast that happens one time before users get frustrated.
  • I could try to leverage user passwords, but there are two drawbacks. First of course is that we rotate passwords as well, causing the above issue to resurface. Second, my password has enough complexity that it broke the URL string and iTunes refused to accept it.

After I spent an evening reading, writing XML files, and trying to get things moving along without much success I started looking at paid services. Let’s just say the landscape for that is sadly lacking, and while it does exist, it also requires that users download yet another app. This to me is a problem we might be able to overcome via mandate, but it’s certainly not the most elegant of solutions. What I really want is for people to use the podcast app they already use so it would seamlessly integrate in with their other streams.

While contemplating laying a 3rd party system and another PO on my boss’s desk, it occurred to me there might be a another way. I was helping out with our beta programs and knew that ZPA had just gone to limited availability on iOS and was in Beta on Android. We had a stable client for both Mac and Windows machines, I use it daily on my Mac to access Jira for development tickets. I spoke with Patrick Foxhoven (@pfoxhoven), our CIO and VP of Emerging Technologies, about the use case. We both got excited as it seemed to solve my access problem and gave him a big new pool of beta users. By putting it on a corporate instance we would be able to automatically discover and enable the service.

A quick ticket to IT generated an AWS S3 bucket for my use with a host name in our corporate namespace and access limited to just ZPA. From there it was simply a matter of adding the podcast URL to my Mac and iPhone apps, and we were off and running. Our ZPA connector automatically discovered the service and added it to my available list. I don’t have to add another app or service, and if someone leaves the company their podcast access stops working when their account is shut down. It’s a simple and elegant solution to an otherwise tricky problem.