Friday, November 7, 2014

Single Sign-On With Office365 (Windows Azure) from Corporate Domains

Recently we'd given an Office365 introduction, as part of our customer migrating their Office2007 environments to Office365 subscription based model.

The most surprising part of the training, was

The demonstration of corporate users, directly login to Office365 (Hosted in Windows Azure Cloud) without entering any credentials from their Windows7 laptops.


Wow! That's quite amazing.

But how it could be? Typically an organization have it's own domain (Active Directory/Domain Forest) and domain controllers. Lets say it is an On-Premise active directory (eg. was.int.mycompany1.org). Usually it is a well defined boundary, within which users access and authorization has been defined and restricted.

Normally two separate domains, will have no security context in common, So that they are logically separated. One user in first domain has nothing to do with or have access to resources in other domain. (say between for eg: was.int.mycompany1.org and was.int.mycompany2.org). But if situation demands, you can set a common security context with the two independent private domains using 'Domain Trusts'. In that case we say

"One domain Trusts another domain, and security context have been set between the using Trusted Domain Objects"

Using "Trusts", user in one domain can be authenticated and authorized in another domain. But that will be happening for 'Private' domains/organizations.

But "Windows Azure" is a public cloud that hosts Office365. So it is not a private domain and have to support multiple independent organizations any way. So how this really works? How it really separate one organization context from another, while validating users?

The answer in the fact that,

"Windows Azure Active Directory is not a normal AD, but it is Multi-Tenant Active Directory"


So it support multiple organizations and keeps them separate from each other. But how 'Windows Azure Active Directory' knows about the corporate users identities, that's privately stored with in the Organization's On-Premise active directory, that is private to the organization?

The user objects get synchronized/copied between the corporate active directory and the Windows Azure active directory.

This is done using a software component called 'DirSync' and called as,

"Active Directory Federation Services (ADFS)"


The below figure will give you a better idea on this.

11


As you can see, the bottom oval represents your organization's domain (Active directory), and its being synched to 'Windows Azure Active Directory' using 'DirSync' component.

That means, once you logged into to your 'On Premises Domain Controller', you need not login again, to access your 'Office365' applications from the 'Windows Azure Cloud'. As now 'Windows Azure AD' have your details, it allows you to login instantly and is 'Zero Sign-On'.

This is called,

'Federated Identity' in Office365"

and is the most seamless identity scenarios. Organization's IT support team, don't have track two separate, user identities, but can have the same user identity that is used at the corporate domain. It give the easy and more fine grained control, as adding/removing a user from Office365 cloud, simply means add/remove the user object from the corporate active directory.

Apart from this, 'two more identity scenarios' are possible with Office365 subscription, not as seamless as 'Federated Identity'. They are listed below;


12


Cloud Identity:
You have a separate, User identity for each user, other than the one used to login to your corporate active directory. Simply you've left with two separate user identities, one is for login into the Office365 cloud and once for login to your corporate domain.

Directory & Password Synchronization:
Similar to 'Federated Identity', but synchronized in one way only (i.e From corporate AD to Windows Azure AD). Also the passwords are stored as hash values in 'Windows Azure AD'. User can use the same corporate credentials for their Office365 cloud as well. (But they have to re-enter it, each time they access Office365)

No comments:

Post a Comment