Identity. Provide. ...to Office 365 & Beyond

Transcription

1 Provide Identity...to Office 365 & Beyond Sponsored by shops around the world are increasingly turning to Office 365 Microsoft s cloud-based offering for , instant messaging, and collaboration. A key part of making those applications work is providing the ability for those organizations to seamlessly use their existing identity systems (e.g., Active Directory AD) to authenticate to Office 365 and other Software as a Service (SaaS) applications. The single sign-on (SSO) experience to these 1

2 applications is expected to just work. However, identity integration can be complex. Key features, such as multi-factor authentication (MFA) and advanced authorization rules, require the right set of technologies and the right configuration to work correctly. In this whitepaper, we ll discuss the challenges around identity integration and talk about how products from both Microsoft and Ping Identity can add value to and simplify the identity experience in Office 365. Office 365 & Identity Integration Basics In most organizations, users want to log on to their PC or web browser only once to access , instant messaging, or Microsoft SharePoint sites. They are not interested in having to maintain separate user credentials for each application or enter a password each time they open Outlook or start an Outlook Web Access session. The applications should just work. A key part of making the applications just work is the integration of identity between an on-premises identity provider (IdP) such as AD and Microsoft s cloud-based identity infrastructure, which is called Microsoft Azure AD. Microsoft supports a variety of scenarios for providing this SSO experience. Each scenario requires two main components: 1. Directory Synchronization (DirSync) between the on-premises IdP and the Azure AD instance used for the Office 365 subscription. This is the identity provisioning piece of the puzzle. 2. Authentication of user credentials to the IdP. This is the federation piece of the puzzle. Note that Microsoft also supports synchronization of user passwords (or more precisely, password hashes) between an on-premises AD system and Azure AD. In this scenario, federation is not required because Azure AD acts as the authentication point for users. The on-premises AD system is simply the system of record for user accounts. It is not actively used to authenticate Office 365 users. This scenario is mostly used by smaller organizations that do not want to be in the business of managing and maintaining a federation infrastructure and do not mind using password hash synchronization. 2

3 Figure 1 shows the basic structure of this two-part identity integration with Office 365. Office 365 Azure AD Figure 1 Integrating an On-Premises AD System with Office 365 Direct Synchronization Federation Server Active Directory In this figure, the user attempts to authenticate to Office 365 (by means of a client like Outlook or Outlook Web Access) using his or her corporate credentials. Office 365 and Azure AD redirect the request to a federation server, such as a server running Microsoft s Active Directory Federation Services (ADFS) or Ping Identity s PingFederate or PingOne product. The federation server validates the user on behalf of the IdP (in this case, the on-premises AD system) and passes information about that validation back to Office 365. In terms of the protocols used for this federation handshake, both ADFS and PingFederate support the most common federation protocols, including Security Assertion Markup Language (SAML) 2.0, the WS-* set of standards (e.g., WS-Trust, WS-Federation), and OAuth 2.0. In this scenario, ADFS is an on-premises federation server, capable of providing authentication services to Office 365 users. PingFederate, Ping Identity s on-premises federation server, provides a similar set of services. PingOne is Ping Identity s cloud-based federation service that provides what is referred to as Identity as a 3

4 Service (IDaaS). Essentially, PingOne provides the basic authentication services that an on-premises federation server provides, but within the cloud, with all the availability and manageability advantages that the cloud provides. It is also worth noting that PingOne and PingFederate can work with ADFS if you already have that platform in place. In this situation, PingOne and PingFederate provide additional identity provisioning and federation services on top of what ADFS provides. Account Provisioning In addition to providing authentication services, an identity integration solution must synchronize user, group, and contact information between the on-premises AD system and Azure AD. This allows for the authorization piece of Office 365 access to be done by Azure AD. In addition, Office 365 applications such as Microsoft Exchange Server and Microsoft Lync leverage data held in Azure AD for their proper functioning. This data includes addresses and Session Initiation Protocol (SIP) addresses, which are typically held in AD attributes. There are numerous ways this synchronization, which is also known as provisioning, can be accomplished. Microsoft includes a basic provisioning capability called DirSync within Office 365. Upcoming provisioning technologies include Azure AD Sync (the eventual successor to DirSync) and the Azure AD Graph application programming interface (API). The Azure AD Graph API programmatically populates Azure AD objects. Third-party products, such as PingFederate, can also provide provisioning services. Each of the Microsoft provisioning solutions has a set of capabilities and limitations that must be considered. For example, DirSync has the following capabilities and limitations: Synchronizes users, groups, and contacts Provides only one-way synchronization (from the on-premises AD system to Azure AD) Supports synchronizing only a single on-premises AD forest Synchronizes 150 attributes with the on-premises AD forest (this number is not configurable) Requires Microsoft SQL Server 4

5 Does not support active failover of the on-premises DirSync server (requires downtime to failover to a cold standby) In the near future, Microsoft will be shipping a new subscription-based upgrade to Azure AD called Azure AD Premium. This new version will likely include Azure AD Sync, which provides a few more features beyond what DirSync offers. For example, Azure AD Sync: Provides the ability to control which attributes are synchronized with the onpremises AD forest Supports synchronizing multiple on-premises forests Supports attribute mapping rules Supports other on-premises directories, such as a Lightweight Directory Access Protocol (LDAP) directory, a SQL Server database, or a comma-separated value (CSV) directory There are certain scenarios where you might need to populate Azure AD from a source other than an on-premises AD instance. For example, many large organizations might have other authoritative sources containing identity information (e.g., another LDAP directory, an HR system backed by a database). Unfortunately, the current built-in DirSync capabilities only provide support for synchronization from AD (and currently a single AD forest, although that is changing with Azure AD Sync). In those scenarios, a product like PingFederate can replace and augment the native DirSync capability with support for more types of IdPs. When using Ping- Federate for directory synchronization, the basic identity-integration structure looks like that in Figure 2. As you can see, identity information can come from a variety of on-premises sources, providing more flexibility for the information that you synchronize with Azure AD. 5

6 Office 365 Azure AD Figure 2 Using PingFederate for Directory Synchronization Direct Synchronization PingFederate Active Directory LDAP Directory Database Now that we ve laid out the basic flow of identity integration with Office 365, let s look at some more interesting scenarios concerning authentication and authorization. Authentication and Authorization Scenarios Federation standards differentiate between the types of clients that users use to access an application. In the context of Office 365, this would be the difference between using Outlook Web Access (a web-based application that is referred to as a passive federation client) and Microsoft Outlook (a full-featured client application that is referred to as an active federation client). The reason for this differentiation is that there are different interaction requirements between the client application, the service provider (Office 365 and Azure AD), and the IdP, depending on the client type. The federation server must be able to provide SSO to both types of clients. Both ADFS and PingFederate support these two different client modes. Regardless of the client type, a key consideration for client authentication is the requirement to provide MFA to access Office 365 applications. Many organizations 6

7 require a second authentication factor either when the user is external to the organization or in all cases. Support for MFA is built into both Office 365 and PingFederate. Office 365 support is primarily focused around providing MFA to that platform. Within the Office 365 Admin Portal, it provides features such as: Ability to administratively enforce MFA for groups of users Use of mobile phone, phone call, or Short Message Service (SMS) text as a second factor Support for application passwords for non-browser clients (i.e., Outlook and Lync) Third-party identity integration solutions often provide options for MFA beyond Office 365. For example, PingFederate supports adaptors to such MFA providers as Google Authenticator s Time-based One-Time Password (TOTP), Microsoft Phone- Factor, RSA SecurID, and Symantec Validation and ID Protection Service (VIP). Authorization Rules Before we talk about authorization at the federation server, let s talk a bit more about how the IdP interacts with the application that the user is trying to access. First, explaining some terminology is in order. We talked about the federation server being the IdP. The SaaS application that a user is trying to access is called the relying party (RP), because it is relying on the IdP to authenticate the user s request to access it. Office 365 is an example of a RP. The IdP generates a claim to pass to the RP. The claim says, I stand by the user who is trying to access your application that person is who he or she claims to be. Those claims often contain information about the user. This information gets passed to the RP so that the RP can make its own authorization decisions about the user trying to access the application. As we increasingly move into a bring your own device (BYOD) world, where all sorts of devices located on all sorts of networks will be accessing corporate applications, it becomes increasingly important to have context around that access. Context means knowing who your users are, where they are coming from, and making authorization decisions based on that context. 7

8 What does this mean in practice? Here is a scenario that might be common to everyone. Let s say you have a SharePoint site residing in Office 365 that contains confidential documents about your company s future plans. Marcia, who works in the marketing department, has access to these documents from her PC at work by virtue of her AD account and the security groups to which she belongs. But let s say Marcia is working from home and wants to access, download, and work on those documents from her Apple ipad. That may or may not be a good thing, depending on your company s policy about such documents leaving the four walls of the organization. You might want to provide conditional authorization to those documents. For example, this authorization might be based on the IP address of the device that is authenticating to Azure AD or the client operating system from which the authentication is being performed (e.g., ios is off limits, but Windows and Mac OS are fine). Contextual authorization for SaaS applications in general and Office 365 in particular can be implemented at the point of authentication. In this scenario, it can be implemented at the federation server. Both ADFS and PingFederate support contextual authorization and claim rules, each with its own capabilities. ADFS supports the ability to create claim rules that transform, allow, or deny access to an application based on specified criteria. The criteria are usually defined using AD-based attributes on the user object. PingFederate supports a variety of additional rules for IP addresses, client types, and more. Thus, you can create rules that, for example, prevent users from getting access to Office 365 if they are on a mobile device or coming from a particular IP address range. These capabilities give you additional flexibility in controlling access to Office 365 and other SaaS applications, depending on the user s context. At the end of the day, in a BYOD world, a user s identity (i.e., a user s AD credentials or something similar) is the only piece of information you can hang your hat on. Being able to create additional rules that control the user s access to an application based on his or her context that is, based on where the person is and the device from which he or she is accessing the application is also incredibly valuable. Moving Beyond Office 365 So far in this whitepaper, we have covered how to integrate an on-premises AD system with Office 365 and Azure AD. Let s take a step back and look at the wider world of identity federation within the typical organization. 8

9 Office 365 is but one application to which users need SSO access within a typical organization. If you extend the picture to internal web applications running on heterogeneous platforms, you quickly find value in having a solution that allows SSO to all of these applications, regardless of their native identity model. This is where products like PingFederate can shine. PingFederate provides a set of adapters and libraries that allow you to integrate (through code or plugins) SSO features into your on-premises applications, just as you would integrate SaaS applications in the cloud. These adapters include support for: LDAP v3 directories Custom.NET, Java, and Hypertext Preprocessor (PHP) applications Existing web access management applications such as Oracle Access Manager, CA SiteMinder, and IBM Tivoli Access Manager X.509 certificates Social cloud identities such as Google, Twitter, and LinkedIn Incoming partner IdPs In these scenarios, PingFederate acts as the IdP. Thus, you get all the MFA and authorization rule benefits mentioned previously when providing SSO to internal applications. PingFederate also provides a connector that allows social identities to provide authentication for internally developed applications, making it easier for external users to access those applications. For example, you can integrate Google social identities into an Internet-facing corporate application, as shown in Figure 3. Figure 3 Integrating Google social identity into Internet-facing corporate applications PingFederate Corporate Application 9

10 In addition, PingFederate can add value to your corporate applications by allowing them to accept open, standards-based identity protocols (e.g., OpenID, OAuth, OpenID Connect) to be used as IdPs for your applications. So, users or businesses that leverage social identities like those from Facebook, Google, or Microsoft can be granted access to your corporate applications through PingFederate. This opens up a lot of options for exposing your applications to much wider audiences than before, without having to be in the business of being an identity provider for those users. Essentially, you are trusting those social identity providers to maintain the user s identity (and its integrity) and you are allowing them access to your applications based on that trust. Although this pattern is just beginning to take hold in the typical enterprise application world, it is flourishing in the online social world. Some social applications don t keep any user identity information at all. Instead, they rely on these open standards and public IdPs to do the heavy lifting of managing user identities. Summary Office 365 is often the first experience organizations have with cloud identity integration. Microsoft provides a number of options DirSync, password hash synchronization, and federation to integrate on-premises AD identities with Azure AD and Office running in the cloud. Although these solutions are often a good starting point, they might not be able to accommodate moderately complex integration scenarios. Ping Identity products give you more options for integrating with Office 365 because they embrace open standards (e.g., SAML) and allow multiple application and directory platforms. As an organization s identity federation needs grow beyond just Office 365 access, it becomes increasingly important to plan a cloud identity strategy that is flexible to the heterogeneous application world in which we live. Products such as PingFederate and PingOne give you many options when it is time to expand your cloud identity world beyond Office 365. They can provide you with a flexible set of technologies for accommodating applications and standards such as OpenID, OAuth, and OpenID Connect. 10