Single Sign On (SSO)

Organizations are fast becoming mobile first and mobile devices are now the forefont for primary source of corporate productivity. With that comes the trouble of constant signing in to various apps and/or web services. In addition to that, there are other disadvantages as listed below:

• Passcode remembrance

First and foremost, each user needs to remember the passcode created in accordance with the organizational security standards. However, all of us at some point of time have forgot the passcode, primarily because it was made to complex, to adhere to the security compliance. Additionally, employees are forced to change their passcodes periodically, which makes remembrance a bigger issue.

• Passcode fatigue

Another disadvantage is the password fatigue experienced by employees, which is the need to remember multiple user name/passcode combinations to access several different services.

• Multiple credentials-based support tickets

This is the outcome of the previous two disadvantages, with IT administrators inundated with tickets on a frequent basis, requesting the passcodes to be reset.

• Repeated requests to provide credentials

Users are forced to re-enter their passcodes every time, even if accessing the same service.

The solution to these shortcomings is Single Sign On(SSO).

What is Single Sign On(SSO)?

Single Sign On(SSO) as the name suggests, requires the users to enter their credentials only once, after which the user can continue to access all the requisite web services and/or apps, without needing to repeatedly sign in. When the users provide their credentials for the first time, they granted a 'ticket'. Ticket, as the name suggests is the one that lets user access other web services/apps without signing in. A ticket is generated based on user credentials and the user can continue to access web services/apps without signing in, as long as the ticket is valid. Further, as the ticket is the one used for granting access, it ensures the passcode do not get transmitted over the network(Internet).

Single Sign On(SSO) with MDM

MDM leverages Kerberos, network authentication protocol for Single Sign On(SSO). Kerberos, the most commonly deployed SSO technology uses Data Encryption Standard(DES) to encrypt the user credentials. Organizations using directory services such as Active Directory(AD) etc., usually have a Kerberos system already established. SSO also has the following benefits:

• Supports conventional authentication methods such as AD-based authentication.
• Encrypts the passcode to ensure the password cannot be identified. In case you're using app accessing corporate data on a daily basis, SSO ensures the passcode doesn't get transmitted over the network every time.
• Additional security as the passcode is not provided directly to the actual service. Instead it is provided to the SSO server, implying the actual service cannot cache the passcode ensuring zero chance of phishing attacks.
• Enhanced user experience, as the employees can switch between various services without having to provide credentials every single time.

Additionally, you can use Certificate-Based Authentication(CBA) to ensure users are not required to sign in even once, effectively becoming No Sign On or Zero Sign on method. MDM supports certificate-based authentication using Simple Enrollment Certificate Protocol(SCEP). Enterprise Single Sign On(SSO) is supported for devices running iOS 7.0 or later versions.

Policy Description

PROFILE SETTINGS	DESCRIPTION
Account Display Name	Reference name for SSO
Kerberos Principal Name	Unique specification used to identify users and/or services. It is of the format primary/instance@realm. Primary here usually refers to the user name; instance is an optional parameter used to qualify primary. It is usually null in case of users; realm is the Kerberos Realm. EXAMPLE: Arsene/admin@ZYLKER.COM
Kerberos Realm	Storehouse for the Kerberos database(user credentials). It is usually your DNS domain name but fully capitalized. For example, if your domain is zylker.com, your Kerberos Realm is ZYLKER.COM
Identity Certificate	The certificate to be used for Certificate-Based Authentication(CBA). Specify the certificate added via SCEP.
Apps Allowed for Single Sign On	The apps which can leverage SSO. You can select any app present on the device and/or the App Repository.
Allowed URLs	The URLs of the web services, which can leverage SSO. Provide the HTTP and HTTPS versions of the web service as separate URLs. Wild-card characters in URLs is supported only for devices running iOS 9.0 or later versions.

Providing https://www.zylker.com as the URL, ensures SSO can be used for even for https://www.zylker.com/new/signup but not so in case of http://www.zylker.com or http://www.zylker.com:3618. Similarly, https://*.zylker.com ensures SSO can be used even for https://sub-domain.zylker.com.