Identity Management in a SaaS Based World

As more and more businesses are outsourcing local intranet resources to SaaS providers such as Office 365, it is becoming ever more important to evaluate and understand the authentication options available. A significant question for the local IT admin is how to enable these new services in a safe and secure way without unduly burdening the local IT staff, or the end users. There are a lot of variables involved in choosing how to manage the configuration and impact of using these new tools and services. In this article we will discuss the options available and the potential impact to the business.

The first step is to understand what options are available. From there we can explore the benefits and impact of each option to the business.

Cloud identity– If you are a small business without an existing Active Directory, or need for centralized management of employee workstations, you will likely find that creating users directly in Office 365 to be the easiest route with very little overhead for users as well as IT staff. These accounts will live in AzureAD and provide access to O365 services as well and any other services that are currently federated with AzureAD.

The primary downsides of this method of authentication management are that your users will have a new login to yet another service, which will likely be different from their login to their workstation and any centralized corporate resources. It will also be another thing for the IT staff to manage. However, for unencumbered small businesses this will be plenty sufficient.

Synchronized identity– The minimum requirement for this is going to be a centralized Active Directory. The identities in Active Directory will be synchronized, along with their passwords, to AzureAD. This provides what is called “Same Sign-On”, meaning your users will use the same username and password that they currently use for all other corporate resources. The most noticeable difference is that they will not be automatically authenticated to O365 with their current logged on credentials. The primary benefits to this method are simplified IT management and infrastructure while somewhat minimizing end-user impact.

Downsides to this method are that the user’s passwords are copied across. This presents a couple of potential issues. From a security standpoint, having identities and passwords that are valid for your local network also stored somewhere not on your network, is probably not ideal for large enterprises. From an end-user experience perspective (which ultimately also impacts IT staff directly), O365 now maintains a separate, but linked, set of credentials. The ADConnect tool, by default, sets up a scheduled task that runs every 3 hours to synchronize identities across to O365, the length of which will be determined by the number of AD objects being synchronized. This means that any local password changes in Active Directory may not be reflected in O365 for potentially 3 hours or more.

Federated Identity– This method provides the best security while also providing what is called “Single Sign-On” access to O365. However, it also comes with a significant increase in up-front configuration and management by IT staff. This implementation is accomplished through the use of Active Directory Federation Services (known as ADFS), coupled with a form of the synchronized identity discussed earlier. A major difference here is that the passwords are not synchronized this time. Instead, a stub account is created in AzureAD automatically via the sync, which is then associated with the on-premises AD identity.

The stub account is used within O365 to assign permissions to various O365 services since O365 doesn’t have access to the on-premises AD. As users login to O365 they will get redirected to your on-premises ADFS server, or ADFS proxy, which does have access to the on-premises AD to validate the credentials. Once this validation occurs and the user’s browser obtains the valid identity token. The browser gets redirected back to O365, which will then verify with the on-premises ADFS that the token provided by the browser is valid.

See the image below for a visual representation of the federated identity authentication process.

Federated identity authentication process

0)      On-Premises DirSync server synchronizes from the On-Prem AD to AzureAD

1)      User browses to O365

3)      Browser is redirected to the On-Prem ADFS

4)      On-Prem ADFS takes the username and password and validates it against On-Prem AD

5)      The valid federated auth token is handed from the On-Prem ADFS back to the user’s browser

6)      The browser is redirected, and the token handed off, to the Azure ADFS Proxy

7)      Azure ADFS Proxy queries the On-Prem ADFS to ensure the token is valid

8)      The browser is then redirected to O365 and the user is granted access

If the user has already authenticated to the On-Prem ADFS for another service, then steps 1-5 are skipped and the user is automatically authenticated to O365 with the valid token, which gives the user the Single Sign-On experience.

Summary

Choosing the best method of authenticating to SaaS based services such as O365 must be driven from a business needs standpoint, and the impact on IT staff and end-users must be weighed against the complexity of configuration and management that will be needed. Hopefully the above information will provide a starting point for further investigations and discussions that will lead to a successful deployment of these services.