Friday 31 May 2013

Managing Enterprise Identities in the Cloud.. using an Excel sheet


Last month I travelled to Munich, Germany, to demonstrate a visionary concept at a prestigious IT trade show: the European Identity and Cloud 2013 conference organised by Kuppingercole.

Specifically, we were invited by Craig Burton (Distinguished Analyst at Kuppingercole) who had spotted an opportunity. Craig’s vision was that datownia’s ability to create Cloud-hosted APIs from spreadsheets could be combined with Microsoft’s Azure Active Directory and Graph Store services to drive federated single-sign-on to a mobile web app using an Excel sheet (as the employee register) and Social networks (as Identity verification service). 

If you are in the identity management business, and you know about Kuppingcole’s “Computing Troika”, then you will know this concept is a big deal: the frictionless management of employee identities at the epicentre of the three seismic shifts which are impacting businesses today: cloud computing, mobile computing and social computing. 

For the rest of us it means “making it very very easy to administer secure employee access to a cloud-hosted Enterprise mobile app using their Facebook/Google/Yahoo login”. 

So why is this so important?

Metaphorically speaking “Enterprise IT” is under incredible tension right now because its being stretched by unstoppable forces (cloud, mobile and social computing). One of the biggest points of tension is “identity management” which is a subset of “security”. ‘Security’ is the single biggest obstacle thrown up by any and every IT team when their business teams want to use their own devices for work or access amazing features in new cloud apps or just work remotely. 

Identity management is the answer to the question “Who in my organisation (or from other organisations) is allowed to access something (like a cloud SaaS product), and when they get access to that something then what can they do with it (what level of authority to they have)?” The big boys (the global corporates) can afford to spend $250K on a Enterprise Identity Management solution. They can also afford to employ staff to operate that system. The trouble is that 96% of the world’s businesses are SMEs. Those SMEs are exactly the type of businesses which are rapidly adopting cloud, mobile and social technologies. They are exactly the type of business which now has an identity management problem.

Identity management in the cloud/mobile/social world is a real headache for every business. Its a headache because its difficult to technically sort out and it’s difficult to administrate. Identity Management is not a core expertise of most businesses. Yet as soon as an Enterprise ‘extends’ itself beyond its office premises (and the safety of its physical networks, routers and firewalls) Identify Management becomes an issue. Solve the Identify Management problem and you are a long way down the road of helping every business in the world operate securely. And that’s exactly what we did (guided by Craig at Kuppingercole and enabled by Microsoft’s Azure Active Directory and Graph Store services).

Our demo is very simple. It has 2 actors: 
  1. a company identity management “administrator” (could be an HR person, or a CEO) and 
  2. someone else (could be an employee or a business partner). 
The administrator wants to grant the employee access to password-protected content a cloud mobile app. In our example the cloud mobile app is actually a “conference agenda app” for the EIC 13 conference. The administrator facilitates access to the app by adding the employee’s name, email address and the chosen access level to an Excel sheet stored on their computer. The employee then opens a browser, surfs to the mobile app’s URL and logs-in with the same email address. The identity of the employee is verified by a single sign-on via a social network (either Google Gmail, Facebook, or Yahoo). Once authenticated the user can access the cloud mobile web app but only to the correct degree of authorisation (as specified by membership to the appropriate user group as detailed in the Excel document). End of demo.


High level architecture of WAAD Manager, showing the integration between a cloud app (EIC conference app), social networks (Gmail, Facebook), Azure Active Directory/Graph Store & user data stored in an Excel doc
Behind the scenes things are a little more sophisticated, but not much. Lets walk through it step by step.
  1. The Excel sheet is turned into a cloud-hosted API by datownia
  2. A simple app called “data pump” synchronises the contents of the Excel sheet with Azure Active Directory (for Identity Management) and Azure Graph Store (to store the content to be displayed in the mobile web app)
  3. The employee logs into the web-app, which instantly polls Azure Active Directory to make sure it recognises the employee’s email address and then re-directs the employee to their chosen social network. For example Gmail.
  4. The employee logs into Gmail, and thereafter is automatically returned to the mobile web-app which recognises the employee as an authenticated bonafide user. 
  5. The mobile web-app only displays content or functions which are appropriate to the access level of the user (as stored in Azure Active Directory).
In this way we have made the secure identity management of employees in the cloud as simple as typing data in Excel: something which is within the capability of any business no matter how small. 

Footnote: 
The credit for this concept belongs entirely to Craig Burton who spotted the opportunity to combine datownia’s data sharing APIs with Microsoft’s Azure services. It was his vision and his encouragement that brought it all together on stage at EIC 13.

We’re also indebted to Kim Cameron (Chief Identify Architect at Microsoft) for spending half of his key note speech at EIC talking about this demo and telling the audience of CIOs it was the shape of things to come. And finally to James Baker, Technical Product Manager at Microsoft, and one of the brains behind “Graph Store”, for supporting our dev team as they put the demo together. 

Tech tips for working with Azure Graph Store


In April 2013 Release Mobile built a demo app using Windows Azure Graph Store. We put this tech blog together to share some tech tips on using GraphStore.


The project objectives:


We built the Windows Azure Active Directory "Manager" app in collaboration with Kuppingcole and Microsoft to demonstrate how single-sign-on access to a mobile web app (in this case a replica of the EIC13 conference all) can be governed, via Azure Active Directory, by information held in an Excel doc. The user identities are authenticated by Social networks such as Facebook, Google and Yahoo

The project had three aims:
1) Present a vision of the future in which access to Enterprise Cloud apps are securely managed by single-sign-on authentication facilitated by Social Networks.
2) Present a very low-friction method for Enterprises to manage their employee identities, using Azure Active Directory, Excel and the datownia.com API-as-a-Service app
3) Demonstrate how Azure Graph Store is a multi-function schema-less data management service that can be used to both extend Active Directory and to hold App data.


Resources:


What is Windows Azure Graph store?

A Graph store is a named data store, containing data tuples.  These are identified with a compound key (_Item1 & _Item2) and have a value property, capable of holding complex data types.
The Windows Azure Graph Store is an extension of the Windows Azure Active Directory Graph (https://graphstoreapp.windows.net/documentation.aspx).
The tuples are formatted in JSON.
It is managed by a RESTful API.


Pre-Requisites

In order to start using a Windows Azure Graph Store, you will need an Azure subscription and an Active Directory Tenant http://technet.microsoft.com/library/jj573650.aspx.
More details on pre-requisites can be found here: http://msdn.microsoft.com/en-us/library/windowsazure/hh974464.aspx


How to access a Graph Store

Consider this URL: https://graphstore.windows.net/myTenantDomain.onmicrosoft.com/myGraphStore/id1/id2
This is an example of  a URI to a tuple with item identifiers “id1” and “id2”, within the “myGraphStore” named graph store of my active directory tenant named “myTenantDomain.onmicrosoft.com”
The resulting object might be of the format:
{
"_Item1" : "first item",
"_Item2" : "second item",
"AttributeName" : AnyPrimitiveValue,
"ComplexAttribute" : {
"AttributeName" : "value",
"AttributeName2" : "value2"
},
"AttributeCollection" : [
{
"Attribute1" : 100,
"Attribute2" : true
},
{
"Attribute1" : 200,
"Attribute2" : false
}
]
}

Http operations to manage data:
Action HTTP Operation
Create POST
Update MERGE
Replace PUT
Delete DELETE
Posting a new tuple to a non-existent graph store will automatically create the store and tuple.
Permissions on a graph store are managed via a permissions document which can be found at https://graphstore.windows.net/{tenant}/{graphstore}/$permissions
The permissions document specifies the name of claims that must be present in a bearer token obtained from Windows Azure Access Control Service (ACS). For information about obtaining access tokens from ACS, see the following link; http://msdn.microsoft.com/en-us/library/gg429786.aspx. 
If anonymous access is permitted to a graph store via the permissions document for a given operation (AnonymousRead or AnonymousWrite are true), the REST request need not include an access token.


Extending Active Directory

Each AD Tenant has a specially named graph store called “graphextension” which is used to add properties to AD entities.
For example, to add a property named “programme” to an AD User entity, you can post the following:
{
"_Item1" : "users",
"_Item2" : "programme",
"OwningTenant" : " myTenantDomain.onmicrosoft.com",
"ValueFormat" : "{graphstore}/targetGraphName/{id}/programme"
}

Then, calling: https://graph.windows.net/ myTenantDomain.onmicrosoft.com/Users('joe@mytenant.com')/ myTenantDomain.onmicrosoft.com /programme
will return  the url:
https://graph.windows.net/ myTenantDomain.onmicrosoft.com/targetGraphName/joe@ myTenantDomain.com/programme
When this url is called, the joe@ myTenantDomain.com/programme tuple is returned, containing the extended data.


Querying the graph store

A data tuple is identified by a tuple id.  It is possible to use wildcards (*) in place of item1 or item2 in order to return a concatenated result set.

thanks Ovais Oozeer @ Release Mobile Ltd for providing the tech tips for this blog.