Trust and training wheels
Identity is one of the key pivot points for integrating different cloud based services into an overall business solution. Get it right and you give end users a seamless experience (and administrators much less work to do). Google have certainly got a lot right with their Apps marketplace, where the fusion of OpenID, OAuth and SPML allows 3rd party SaaS offerings to ride on the back of existing Google Apps identities. Most crucially email (or should that be gmail?) is the right identity anchor as it’s the application that most will start (and sign into) first.
There’s trouble in paradise though. A few weeks ago a colleague asked me to add a marketplace app to our domain. He’d been using it for a while standalone, and thought that if the whole company were using it then we’d get beneficial network effects. I started going through the signup process and stopped when I hit ‘this app is requesting access to your documents and contacts’. My choice was binary – I could approve that access or give up there. For me this felt too much live FaceBook, where trivial survey apps get to access your personal details, your social graph, your photos and all manner of other things. This was much worse though, this was asking for the keys to the kingdom. Our Google Contacts is synced to our Capsule CRM (another marketplace app, but one we were trusting and using before it integrated), and our Google Docs is used for various collaboration projects internal and external. That’s a LOT of proprietary data that I was being asked to hand over. What would happen if I answered yes? The optimist in me hopes that the app in question would access specific documents and specific contacts, under user control, for specific beneficial purposes. The infosec cynic in me however fears that the company behind the app (or anybody that succeeds in breaking their security) can now copy and utilise every piece of that proprietary data without me knowing anything about it (until the consequences become stare in the face obvious).
User control is the key piece here. I want to get useful functionality from the 3rd party, and to do that they need access to some of my data, but not all of it all at once. This is where the training wheels come in – in the early days I want to be clearly told what’s moving where, and asked for permission. As time goes by trust will build, and there will be generic access patterns that I’m happy to authorise – we take the training wheels off once confidence builds. This isn’t a new idea, we see this every time we use a new browser – those are you sure you want to do this dialogue boxes with the option not to be asked again. Windows UAC serves much the same purpose for software installs. So… trust needs to be progressive, and I fear that a lot more work is needed to put the right user experience in place.
Trust also needs to be verifiable. I need to be able to go back and see what happened. I need access to the audit trail. I have high hopes that CloudAudit will eventually deliver on this need, and hopefully Sam Johnston’s (and Chris Hoff’s) recent titanic efforts on getting v1.0 ready may make that sooner rather than later.
