Mobile SSO: “It works on PC” just isn’t good enough
Jon Towles explains how to make seamless SSO work on iOS and shares a few thoughts on his favorite identity platforms.
It’s truly amazing in 2019 how people set such a low bar. I can’t tell you how many times when I’ve broached the conversation about a mobile SSO strategy that people say, “well it works on PC.” Running on Internet Explorer is not working!
I’ve written extensively on my own blog about how the ideal user experience should be consistent across every platform. It doesn’t matter what you are using, it should just work. I’m here to tell you that you can create a seamless experience without entering in credentials into each application. It is achievable because I’m doing it already.
The reality is that single sign on for iOS is possible, if you made the right choices architecturally at your company. Some SSO platforms can achieve it, whereas others just can’t. We’ll talk briefly about a few things: (1) Did you choose the right SSO platform, (2) the authentication methods that most companies use today, and (3) how you can extend the right platform to mobile SSO.
Choosing the right platform
It’s no secret that most of us are buried beneath the Microsoft pyramid like Indiana Jones trying to find a chalice and not get skewered by arrows. From the outset, I’ll be clear, and I know it may be viewed poorly, but Microsoft will not give you what you need to achieve a true SSO platform. While they are committed to driving a great experience on the PC, it just isn’t happening on other platforms. It’s not a bug problem, it’s a focusing problem! You need to find a platform that is focusing on your types of devices.
A few examples of companies that got it right are Okta and VMware. You can read my article about achieving true SSO on iOS leveraging VMware Identity Manager, which they do brilliantly through a cloud Kerberos endpoint and certs. Okta Mobile Connect is another interesting spin on doing SSO. (I’d suggest reading Jack’s article about Okta’s mobile strategy for more.) Simply, make sure you choose a platform that gives you a to give people what they need. Some just won’t set you up for success.
How people authenticate in your company today
The ways people authenticate is essential to understanding how to achieve SSO on any platform. I’m skipping OpenID Connect/OAuth2 so people can understand this, and I don’t spend 12 hours explaining token-based authentication. Your can achieve authentication in a few general ways: (1) Kerberos, (2) NTLM (Windows Auth), (3) Forms-Based Authentication, and (4) SAML. I’ll explain each briefly.
Kerberos
PCs on your domain use Kerberos tickets to seamlessly sign into various things today. You log in and it gets a ticket from your Active Directory environment, which grants you access to all sorts of things like file shares, Windows-based sites using NTLM, LDAP directories (like your GAL in some ways), and certain web apps that have been setup for Kerberos.
NTLM
The best example of NTLM I usually think of is SharePoint on premises. A lot of inexperienced developers will just use NTLM for their application because it’s super easy to implement and they just aren’t used to using more complicated authentication mechanisms. You will notice a pop-up asking for your username and password. That’s NTLM!
Forms-based authentication
This one is pretty simple. You know OWA, right? That’s forms-based authentication which is any website you go to that has a login page. It’s going to be one of the bigger problems, once we get to the next section.
SAML
I’ve talked about SAML before. SAML is simply a token exchange that brings potentially seamless authentication, which you are likely familiar with in Office 365 using ADFS or other apps at your company using AD Federation today.
Authentication goes into two buckets
Once you understand the ways they authenticate, you will learn that you have: ways that mobile can authenticate and ways that mobile can’t authenticate. You need to start by making a list of all of your applications and their authentication mechanisms.
Did you do that yet? Great! Guess what? You can take every application that isn’t using Kerberos or SAML and put it onto a different tab on that spreadsheet because it won’t work on mobile. Anything else just isn’t SSO. If you type it into a form or get a prompt, then you have already failed!
Developing a transition plan for NTLM/forms-based authentication
The good news is most apps that exist—especially cloud and SaaS apps—can support SAML. Most people don’t realize it, but this includes virtually all Microsoft apps. Maybe it’s not always out of the box, but with effort you can create an amazing experience.
If you can use SAML, mobile SSO is very easy to achieve. You will need to work with your teams and set expectations because most modern authentication is Kerberos, SAML, and tokens now. Anything else is antiquated, legacy, and insecure.
Enabling iOS apps on managed devices for SSO
So, you have an SSO platform that will work on mobile and you have a bunch of SAML apps. How do you get started, you ask? iOS SSO is simple and comprises a few basic things:
- iOS Kerberos SSO MDM Profile
- Client Authentication Certificate/SSO Platform that has a proper workflow for SSO
- Properly deployed mobile apps
You can see by the screenshots below that a Kerberos SSO profile focuses on a Kerberos Realm, your AD username, what identity endpoints can use Kerberos, and what apps it can be passed to. In this example, luckily VMware Identity Manager has its own cloud-hosted KDC, but the great thing is that you can achieve iOS SSO with your internal Kerberos environment in the same way. It does require you to have Port 88 open to your environment (hopefully only VPN). I would urge people to find the right platform that helps them avoid that.
The Kerberos profile will use your identity to authenticate to a KDC and renew that session with a device certificate. Once it has authenticated you, it will authorize you to that SAML application without a prompt—that’s a win!
The biggest challenge in deploying iOS SSO via Kerberos is integrating your CA properly and building certificates that match requirements. To reference my own article on this:
On the MDM side, these are the requirements:
- Create the Subject Name with your NTID
- Create SANs for the following:
- UPN with the user’s UPN as the value
- Email with the user’s email as the value
- Optionally create a DNS field for UID if you are doing device compliance (i.e. DNS Name UID= (Whatever the UID of the device is)
- Make sure the certificate can be used for signing and encryption
- Make sure the template you provide on the iOS side matches the template name (NOT THE TEMPLATE DISPLAY NAME) from your CA
Okta also does mobile SSO by leveraging a native mobile app and OAuth tokens to delegate authentication to your suite of apps. As I said earlier, it comes down to choosing a platform that helps you deliver a special experience to your users.
Now you too can do mobile SSO
In closing, achieving true SSO on iOS is far from child’s play. You might need help and that is where I come in. If you need help, just ask. I have substantial experience in delivering iOS and Android SSO. When you do it right, you build fans and loyalists, which we can never have enough of in the mobility space.
