Identities, the cloud, business needs and a modern approach to handle them

Microsoft, Amazon, Google, everyone talks about the cloud and their fancy new features.

And even though this opens new opportunities and possibilities, this is actually not new at all.

In the past enterprises were hosting services in their DMZ, offering them to partner, customers and employees.

Your partner never worried about how you run the service as to them this was all in “the cloud”. We simply didn’t call it like that back then and this “cloud” was part of your extranet.

Today we have more sophisticated solutions, massive computing power, larger storage, faster internet connections, but one fundamental problem stays the same: Who is accessing the service and what is he or she allowed to do?

A few years ago the answer was simple. Every user that needed access to a specific service got its own user account, mostly in an Active Directory.

This approach seems quite charming, you always know who is accessing your services and data, you know the accounts, you maintain them.

But on the other hand most of us also experienced the downside of this concept. Large numbers of external accounts, consuming a considerable amount of IT resources, creating measurable overhead in the communication between third parties, your business, the IT department, and so on.

This was already a not so ideal solution. And now we add the whole cloud scenario on top.

I want to use cloud services like Office365 in my company, how can I give my internal users seamless access to these applications? Without having to tell them that they now need a second account, LiveID, to access these services?

You develop your own solution in the cloud, how can you handle all those incoming identities?

Or you simply want to offer your service running in your own DMZ, but now with a modern approach to handle identities?

What if we would use all the identities already existing out there? Why not opening your solution to every user that has a LiveID account, or Google, or LinkedIn, or Facebook?

Or in a more business critical area, using the identity records of your partner? They most likely already operate an Active Directory with all their user accounts. Wouldn’t it be great to use them and give those partner users a SingleSignOn experience on top of it?

This is where the whole topic of Federation comes into play. Federation is the primer that brings services and identities together.

Instead of maintaining your own user database, your service relies on a Federation Server to provide it with necessary user information.

So how does this would look like? Let’s assume you operate your SharePoint collaboration platform within your DMZ. Now you want to open it to your partners, so they can work together with you on various projects.

Instead of telling your SharePoint to refer to your own AD for user information, we would implement a Federation services. This Federation service then accepts the request for identity from the SharePoint and forward it to a trusted user database for authentication. Usually this is the existing Active Directory. As soon as the user is authenticated his or her credentials might get enriched with additional information, so called claims, that the Federation service sends back to the SharePoint.

Now we add a second Federation service. This one however is operated by our partner, redirecting user requests to whatever user database they might use.

So instead of maintaining external partner identities, and therefore requiring our partners to remember another set of username and password, the SharePoint sends the request back to the partners own AD. By using technologies like Kerberos this will even create a SingleSignOn experience for this user as he gets seamlessly authenticated by its own AD.

But this would mean we have to constantly change our SharePoint to add or remove new Federation services. To avoid this you are able to use a so called Federation Proxy.

Your application simply needs to trust this Federation Proxy. This proxy will then route incoming requests to the specific Federation services in the back.

In more advanced scenarios you can also implement what is called claim transformation, taking incoming claims and modifying them so you always have the right user information for your application.

What about the rest of your visitors who don’t belong to any of your partners? Well, today almost everyone has a Facebook, Googlemail or Live account. So why don’t we use them?

This is possible by replacing the typical Federation Proxy with Microsofts Cloud service called Windows Azure Access Control Service, or simply Microsoft ACS.

What is ACS? Actually it is a Federation Proxy in the cloud that you can use for your service to use multiple identity providers. You might use ACS to redirect users to your very own on premise ADFS2.0 service, or to use Facebook or Googlemail.

As this service is in the cloud, and doesn’t store any sensitive personal information, you can access it from everywhere without worrying. Whether your application is hosted on Amazons cloud, you want to attach your external SharePoint or even internal applications.

You don’t want to host your own services? No problem, federation supports you even when you only want to consume cloud services.

For example Office365. With Windows 8, Office 2013, SharePoint 2013, etc. on the horizon you might want to benefit from their cloud sharing features.

But as you might now they require MS LiveIDs for authentication. Instead of giving your employees another set of credentials they have to remember and making it necessary to switch between them, use Federation. This will seamlessly authenticate your users against your AD and passes the claims to Office365 giving your users a perfect SingleSignOn experience.

These are just a few examples of how you can make advantage of these new technologies and services, without sacrificing on either your security or user experience.

And as we at Cambridge are not only talking about it, we created our very own "federation playground". This solution is 100% hosted in the cloud and features domain controllers, federation services, collaboration platform, identity self service, etc.

The picture below will give you a rough overview of this extensive setup:

 

You have a Googlemail account or a MS LiveID? So why dont you try it yourself?

Go to http://try.solutions-for-clouds.ch and have a look at our cloud hosted collaboration platform featuring public identities authentication services.

If you are interested to hear more about this or if you already have some specific questions, please don’t hesitate to contact us!