Who’s on first?

by Brian Katz on August 26, 2014 · 5 comments

I spend a lot of time talking about organizations enabling their employees through the use of mobile. It’s truly the only way to ‘win’ at this game. When you enable your users to be more flexible and agile they become more efficient and productive. What more could you ask for? The question always turns to how do you actually enable your people. You start with the FUN principle (Focus on the Users’ Needs) and you build apps that enable them to do what they need to do, when and where they need it. There are many issues with building apps and if you focus on their needs you get most of the way there. Yet, there is still the fundamental issue when building an app that someone can use anywhere and at anytime. How do you know who that somebody is?

whos_on_firstThis is one of the fundamental problems of mobile. You need to know who the person is using the app and you have to make sure it’s them when they are using it. While it sounds simple, it’s not like you can actually be there in person and watch them press the buttons. Hence the practice of identity and access management (IAM) is born.

One of your jobs as the keepers of mobile for your company is to protect their data assets. This used to be somewhat easy. People sat at their desks and were given IDs and Passwords to login to their machines. You knew who was accessing what data at any time since the computers were too heavy to move and so between their ID and password and what computer they were using you were all set. That became harder when laptops were rolled out but you enforced VPNs and gave out RSA tokens to make sure you had a second factor of authentication for your user.

This all went out the window when the iPhone came out. All the sudden you had devices that could go anywhere and at the same time could always be connected. Not only that, but in the beginning they didn’t even have the ability to connect via VPN. That didn’t stop people from wanting to get their email on these devices and then start to do real work on them. Information Security (Infosec) just wasn’t ready for this to happen. It immediately became a no that was overridden by every single person who had one of the devices (another example of shadow innovation). A solution had to be found.

Hence, you now hear the term identity and access management being thrown around. This isn’t a new concept but one that, to be honest, wasn’t ready for the user revolution that mobile brought into the work environment. The first response to mobile enablement was not to allow anything on the device, and the second response was to make people use a VPN to connect to work. It was following the same path of legacy thinking that led to MDM becoming popular. The only issue was that none of these ideas were really good solutions, mostly due the fact that they weren’t implemented well. These solutions didn’t sit well with users because they were using consumer apps and saving their data and keeping stuff confidential and it was easy. They didn’t need to know a different password for each app and enter it every time they opened the app. They just clicked on an app and did what they needed to do.

The question is though, how does Infosec solve this Abbot and Costello problem for most companies. Abbot saying who’s on first and Infosec responding, yeah, who’s on first? The whole point of Infosec is to protect the data and make sure only the right people (identity) are able to get to the right data (access). The problem, which has yet to be addressed in most companies, is how to do this while following the same FUN principle that we used to design app experiences. As any Infosec person will tell you, they want to enable two-factor authentication (independent means of identifying you) on your device and apps and yet they don’t really care about the experience (not all Infosec is this way). In order to get user buy-in, the experience of using work apps has to be transparent and easy, not something that gets in the way. Otherwise users will find another way/app to get their stuff done and that is guaranteed to be insecure.

The two pieces leading the way here are single sign on (SSO) that is integrated across all apps and a second simple form of authentication (2FA) besides your login. SSO means that once you sign into one work app that same credential is used for other work apps you may use in that same session. You no longer have to sign into each one individually as you switch between them. 2FA means that a second way to authenticate you, which may be a certificate on the actual device or biometrics like your fingerprint among others are used to assure you are you. These pieces need to be explained to your app developers and have to be easy for them to setup and use. Only when they are planned well and made simple to integrate into any app will they help to solve the IAM problem that all companies face. In the end, it means that you have to involve your Infosec folks when you are designing your apps to enable your users, not when you are done and want to deploy the apps. Infosec, at the same time, has to adopt design thinking and realize that it’s all about the user experience. When those two things happen, you are well on your way to securely enabling your users while protecting your data.

{ 3 comments… read them below or add one }

Amitabh Sinha August 26, 2014 at 2:51 pm

Great article. I agree SSO and “seamless” 2FA is key to “FUN”. Devil is in the details. Here are some observations from our experience at Workspot:

(1) Most companies don’t have a single “single sign-on” vendor. Its some combination of NTLM/Kerberos, CA Siteminder/Oracle iDP, and SAML 2.0. And most SSO vendors don’t support all three classes of apps – windows client server, old web apps, and newer SaaS apps. We ended up doing client-side integration to multiple SSO technologies to deliver a seamless user experience.

(2) I hear a lot about 2FA, but very few people are gung-ho on the old RSA token. This is one technology that neither users nor IT likes. It has a cumbersome user experience, and IT complains about the cost. Lots of options to re-invent 2FA with some combination of biometrics/SMS/certs. Doing it in a platform-independent manner is a challenge. Certs could be one option.


Brian Katz August 26, 2014 at 7:46 pm

I agree with both and have seen a lot of it done with certs as your second comment suggests.


Simon May August 26, 2014 at 8:13 pm

This is a complex space to be sure. Solutions need to become simpler (to use) and more automated. You are right that this should be pri0 for mobility engineers now – hopefully that will give it the focus it needs.

AD is the most singular source on the planet for corporate ID (almost everyone signs on to AD somewhere) but they also have disparate IDs on other systems and IT (InfoSec) have been chasing SSO for year… but not necessarily with any care of the FUN principle. Hopefully mobility will change that since messing around with multiple sign-ons on a small screen gets really old, really quick.

On the point of 2FA again mobility is a massive disruptor. We can now ditch keyfobs and use apps, SMS and phone calls to do this.

On app integration I’d posit that its as simple to integrate with SSO with a corporate STS as a Google, Facebook or any other ID provider. We should do a #mobilebiz chat on this subject.


Leave a Comment

{ 2 trackbacks }

Previous post:

Next post: