Single Sign On for Apps
SSO enhances user experience. Certificates are a good, but complex solution. You need a PKI. SSO token are the second best way. Users will be asked for credentials and tokens must be shared securly between Apps.
I am a mobile user. And when I don’t have my smartphone on me, I can become really nervous: Has a customer send me an email and is waiting for a reply? Do I need to approve a workflow? What am I missing on my Twitter stream?
There are times, however, when using my phone makes me really upset: Mostly that’s when apps require me to log in. For example, when I download a new app and need to enter credentials for the initial login, often with app specific policies. Or when the session for a social media app has expired, requiring me to log in with another set of credentials. But business apps, they are the worst: Not only do you have to login every time you use them, they also require these super secure business passwords, making it extra painful to enter them on a smartphone.
And don’t we all hate to enter user names and passwords on these tiny touchscreen keyboards?
My personal workaround is to use only a handful of different logins for the various apps. Unfortunately, I do not always remember which login I have chosen for which app.
What really would be helpful here is a Single Sign On paradigm for ALL of my apps! As an icing on the cake it would be nice if this SSO System could also handle different personalities (IDs when we want to talk techie), but this is maybe another blog post.
Single Sign On
Now – do you work for a company that has SUP deployed? Than you are in luck, as your app developers can come to your help!
Here’s how, let’s get our hands dirty and talk about the details of Single Sign On (SSO):
Often in discussions the term SSO is used for various techniques which play in the area of authentication and authorization. But people understand different things if you say SSO.
The topic “Single Sign On for App” – as we have discussed – is a way to enrich the User Experience on mobile devices by prevent annoying log in screens. In another Single Sign On scenario you have two distinct backend systems that your App needs access to, but of course you only want to login once. Let’s call this “Single Sign On for Back-ends“.
In a discussion about SSO – make sure all participants are talking about the same scenario.
The “easiest” way for the end user to achieve SSO for Apps and SSO for back-ends with one technology is using X.509 certificates. You can use the identity provided by a certificate in all installed apps (limits apply) and pass that identity to your back-ends, which are also enabled to use that “format”.
BUT, in order to use certificates you would use a PKI – a Public Key Infrastructure. This PKI is responsible for provisioning certificates, establish trust between users and systems, apps and backend systems, let you revoke certificates and so on. The effort to plan, create and maintain a PKI can be substantial.
From a user perspective the Certificate Authentication is the easiest way: The user does not even have to provide his credentials – log on is working seamlessly in the background. On application start the app is retrieving the certificate from the secure store (normally the keychain) and passes it to the mobile middleware. The SAP Mobile Platform will then use the provided certificate information to pass it to the various, certificate enabled back-ends (SAP and others).
SAP is offering solutions for X.509 certificate authentication in its mobile offerings. SUP for example supports User Authentication via X.509, and these can be distributed to devices using Afaria.
Since this “Certificate” thing is complex to implement and maintain it is not always the best choice for mid-size and smaller companies and partners. So what are the alternatives? What about Single Sign On via tokens?
In a Single Sign On with Token scenario the user logs in with his authentication credentials – yes we need that, at least once every here and then.
With these provided credentials the app can request a resource from the SMP. Since this request does not contain a token, SMP will ask a configured token provider with the users credentials for a new token. The token provider verifies the credentials and returns the user token.
Typically the token is just a large, more or less random string in the http header. Sometimes the token provider resides on the network edge – meaning that the request has not to be issued against on premise systems – this prevents DOS kind of attacks against the internal infrastructure.
SMP will now use the token to impersonate the user against the back-end and will also send it back to the app. The app now stores the token securely on the device and resubmit it with every subsequent request. After a while those tokens are invalidated and the process starts all over again – starting with asking the user for his credentials.
In this scenario we don’t have to store the credentials on the device, which is truly a security advantage. Stored tokens typically can be invalidated manually if compromised, so this scenario gives us a good user experience and a more secure system.
For now this token scenario allows an App to validate against multiple back-ends, but does not allow to be used by multiple Apps on the device. In order to do so we have to share the token between devices. Since Apps are today running in isolated environments (sandboxes) it is not easy to share that information. Typically you can do using URL Schema to pass information between Apps – but this only works unencrypted, and malicious Apps could also register for your URL Scheme. For now the only option we have is to store in the keychain – if available for your platform.
As an example of who SSO Tokens can be configured read the attached How-To Guide. It gives a good overview which steps are necessary to configure SUP (up from 2.0.1) for the use of an SAP token provider and use it in an MBO based App.
Want to read more: