Update: Just a quick note prompted by a comment. These steps should still work in iOS 8 releases, although I have not updated the post to talk about any of the new capabilities related to certificates in SSO. iOS 9 Update: Things still seem to function largely the same in iOS 9 in my (admittedly limited) testing.
In case you missed it, Apple’s recent iOS 7 release added a bunch of new business/enterprise-friendly features. One of the fine gentlemen at MobileIron wrote a nice summary covering several of them. While per-app-VPN and some of the new MDM capabilities look pretty cool, the one I’m most interested in is the “Enterprise SSO” feature.
If you’ve ever tried to use an iOS device in an enterprise environment that takes Windows Authentication for granted, you’ve probably quickly grown frustrated at the shear number of times you see the lovely dialog box in Safari asking you for a username and password. That’s not really the worst of it, because at least Safari is smart enough to prompt you, where some apps just silently fail without ever giving you the option to authenticate. The SSO feature is intended to solve this.
Unsurprisingly, Apple has chosen to use Kerberos as the core of their SSO support iOS, just like they do in it’s older brother – Mac OS. I’m not going to cover how to make your web application support SPNEGO and Kerberos in this post, but it’s really not as hard as many people make it out to be, particularly if you are a Windows/Active Directory shop. Let’s look at how you can take advantage of it assuming you have it working.
The key to “enterprisifying” your iOS devices with things like app restrictions, VPN settings, and PKI certificates revolves around configuration profiles and SSO is no different. Unfortunately, at the time I’m writing this Apple hasn’t yet updated the iPhone Configuration Utility to know how to generate profiles for the new iOS 7 feature. So, we get to do this the hard way – hand-creating an XML file with the proper config profile syntax. Unless you are some kind of blog-reading robot for whom XML syntax is a native language, this might not be the easiest task in the world, so I’m going to help you out with the contents for a “sample” profile at the bottom of the post. You can just grab this text and paste it into a plain text file with a .mobileconfig extension (e.g. kerberos.mobileconfig).
There are a few parts you’ll want to pay attention to, and then hopefully you should be off and running.
- As with any example you grab from the web, unless you are referencing a “well-known” identifier for some kind of resources, you’ll want to make your own GUIDs and replace the ones you see in the example.
- Anywhere you see “com.mycompany”, you’ll probably want to use your own domain
- In the string value for the “Realm” key, you’ll want to put your own Kerberos realm. In the case of Active Directory, that’s usually going to be an AD domain
- The URLPrefixMatches section is key, because iOS is only going to try to get and use the Kerberos ticket for URLs that match one of these. Unfortunately there is currently no “suffix” option, so you can’t just do http:⁄ ⁄ *.mycompany.com. As the name implies, you can use a prefix, but doing a “blanket” prefix like http:⁄ ⁄ * seems like it would be a pretty bad idea.
- Eventually I assume there will be other apps that support Kerberos, and then you might list their bundle ids in the AppIdentifierMatches section, but for now using Safari is an interesting place to start
- Save the modified file and then deploy it to your device. Unless you also happen to be an MDM administrator who knows how to use your MDM product to deploy these files, the easiest way to do this is probably just to email yourself the .mobileconfig file and then open it is as an attachment on the device. You’ll get a couple of security warnings this way, but it works. When the profile is geting installed you should also be prompted to enter a “principal name” for the specified realm. Generally speaking this will be your login id/username.
Now that you have a SSO configuration profile on your iOS 7 device, you can try it out. If you open up Safari and go to one of the sites that matches an entry in your URLPrefixMatches section, you’ll see a login dialog that looks a bit different than the typical “popup” prompt you’d see for a site requesting Basic or Negotiate-based authentication. Once you’ve entered your password, it should let you into the site. The beautiful part is that when you go to the next site in your list of URLs, you won’t get prompted at all, and you should be able to go revisit these sites in Safari over and over (up to the ticket expiration time for your Kerberos environment) without re-entering your password. Single sign-on is a beautiful thing!
Don’t get discouraged if it doesn’t work right away. The diagnostic logs from your device can be very helpful in figuring out what’s going on. I know they pointed me in the right direction for fixing up the .mobileconfig file several times. I’d be remiss if I didn’t tip my hat to Craig Newell, a mobile tech guru at VMWare for being kind enough to post some similar sample info in the Apple Developer forums that was super helpful in getting this working.
PayloadContent PayloadType com.apple.sso PayloadVersion 1 PayloadIdentifier com.mycompany.sso.test.kerberos PayloadUUID 132013d0-faff-11e2-b778-0800200c9a66 PayloadDisplayName SSO profile for my enterprise PayloadDescription Configures Kerberos Single Sign On. PayloadOrganization Name Kerberos Config Kerberos Realm AD-DOMAIN.MYCOMPANY.COM URLPrefixMatches https://kerbenabledapp.mycompany.com http://nonstandardapp.mycompany.com:16089 http://commonhostnameprefix* AppIdentifierMatches com.apple.mobilesafari PayloadDescription Sets up Safari to use Kerberos SSO for certain URLs PayloadDisplayName KerberosConfigProfile PayloadIdentifier com.mycompany.ssoconfig PayloadOrganization MyCompany PayloadRemovalDisallowed PayloadType Configuration PayloadUUID B55B5378-6709-40EB-A380-76F59C3B7D86 PayloadVersion 1