Extend and Enhance AD FS

Extend and Enhance AD FS December 2013 Sponsored By

Contents Extend and Enhance AD FS By Sean Deuby Introduction...2 Web Service SSO Architecture...3 AD FS Overview...5 Ping Identity Solutions...7 Synergy of Combining AD FS + Ping Identity Solutions...8 Figures Figure 1: Major Internet SSO Components...3 Figure 2: AD FS Server Farm...6 Figure 3: AD FS + PingOne IDaaS Solution...8 Introduction Many enterprises have chosen to deploy and use Active Directory Federation Services (AD FS), a Windows Server role, to provide users with single sign-on (SSO) access and federation to a variety of Software as a Service (SaaS) applications. AD FS, a component of Microsoft s Active Directory family of services, extends Active Directory Domain Services (AD DS) in order to provide web services that AD DS does not support natively. Although AD FS is lacking some key features that would improve both its administrators and end users experiences, many enterprises have already made significant time and monetary investments in its deployment and operation. It is highly unlikely these organizations are willing to immediately rip out AD FS and begin anew with another SSO/federation solution. Working with AD FS in an environment where SaaS application use is growing dramatically often without the IT department s sanction or knowledge presents a strong set of challenges for enterprises. Scaling AD FS to provide SSO to hundreds or thousands of SaaS applications in a timely manner, with a good user experience, is simply beyond the capabilities of many already-overburdened IT departments. This situation is a major reason why Identity as a Service (IDaaS) solutions have arisen. They offload the SaaS connection burden from the on-premises IT department to a subscription cloud service. The good news is that organizations that have deployed AD FS do not have to start over. Enterprises can continue to use their existing AD FS solution as an identity bridge to 2

the Ping Identity SSO/federation IDaaS solution, PingOne. The marriage of these two best-of-breed solutions yields a variety of complementary benefits, including: A wider variety of open standards-based SaaS applications are supported. Onboarding new SaaS applications is easier for AD FS administrators, as is user provisioning, especially when there are many SaaS applications. Only one connection to PingOne is needed to handle all SaaS applications. Scalability requirements are handled on demand with PingOne rather than scaling up the on-premises AD FS solution. Connections are managed through PingOne s easy-to-use interface. An end user portal allows users access to all the applications they are authorized to use through a single, device-independent user interface. This white paper will review AD FS s history and capabilities as they have evolved, as well as some gaps in the product s current feature set. It will also outline the Ping Identity solutions and where they fit into an enterprise identity architecture. Finally, it will show how AD FS and Ping Identity solutions easily integrate with each other to provide your business with scalable, highly available, and user-friendly SSO access to SaaS applications. Web Service SSO Architecture It s important to understand the basic architecture of services that provide SSO to web services using credentials from a business s identity databases. As Figure 1 shows, there are six major components: web service, service provider (SP), identity provider (IdP), federation service, identity bridge, and provisioning service. In this example, the identity database that contains user credentials is Active Directory Domain Services (AD DS). Figure 1: Major Internet SSO Components 3

Web Service A web service is a browser-based (HTTP) application, provided at a network address over the web. Although web services provide a wide variety of capabilities (including both IdP and SP roles), the best known web services are SaaS applications. Service Provider (SP) The SP role is a web service that provides a business or consumer service (such as Microsoft Office 365, Salesforce.com, or Concur Travel) based on accounts it holds. An SP that supports federation standards (such as SAML 2.0) relies on identities, held at the IdP, to authoritatively authenticate these accounts. The SP is also referred to as the relying party because it relies on the IdP to authenticate its accounts. SPs that do not support federation require local, form-based authentication with a user ID and password. The term service provider is also used colloquially to describe the business providing the web service used as an application. Identity Provider (IdP) In a transaction between two web services, the IdP role negotiates with Active Directory (and possibly other corporate data stores) to: Authenticate the credentials provided by the user. Provide a set of claims about these credentials that can be authoritatively communicated back to the SP or to other web services that require identity information on behalf of the business. Colloquially, the term identity provider describes the business that provides the identities of the users who require the SSO capability. The identities can be stored in Active Directory, HR databases, or other miscellaneous data stores. Federation Service A federation service performs several functions. The most important functions are: Supporting federated trusts established between the IdP and SP. Performing security token translation between the Kerberos security protocol used in Active Directory and the SAML 2.0 claims model used in web services. This translation is performed by the Security Token Service (STS). Identity Bridge The on-premises services that connect your enterprise to cloud web services are collectively known as the identity bridge. An identity bridge can be one or more 4

services running on separate servers or on a single instance. This bridge may act alone and connect directly to an SP, or in conjunction with a cloud-based federation service (IDaaS), which acts as an IdP and connects to the SP. Provisioning Service For federated SSO to function, the SP must have its user accounts authenticated by the IdP and have those accounts populated with user data provided by the IdP. How is this user data replicated to the SP? A variety of methods are currently popular, including proprietary directory synchronization services and standards-based provisioning protocols. Some methods handle the complete provisioning lifecycle (i.e., CRUD create, read, update, delete), whereas others do not. The System for Crossdomain Identity Management (SCIM) is an emerging provisioning standard that supports the entire provisioning lifecycle. The provisioning service can be incorporated into the federation server (e.g., PingOne s AD Connect uses SCIM for its provisioning capability) or run as a standalone service. AD FS Overview AD FS first made its appearance as a downloadable addition to Windows Server 2003 R2. It was later incorporated into Windows Server 2008 and Windows Server 2008 R2. In Windows Server 2012, AD FS 2.1 is an installable server role, and Windows Server 2012 R2 continues this configuration with AD FS 2.2. AD FS s feature set and supported protocols have grown as the product has matured. AD FS was initially built around the core WS-* set of standards (such as WS-Federation, WSDL, SOAP, and UDDI) for web services. A key capability upgrade occurred in AD FS 2.0, as it added support for SAML 2.0, the most widely used identity federation standard. AD FS 2.2 added support for a rapidly growing identity and authorization framework, OAuth 2.0. Typical Enterprise Deployment Architecture In a typical high availability architecture (see Figure 2), AD FS is configured as a server farm of two or more AD FS servers in a Network Load Balancing (NLB) cluster behind one or more federation server proxies (or Web Application Proxies in Windows Server 2012 R2). For enterprises with fewer than 100 trust relationships to relying parties, the built-in Windows internal database on each AD FS server can be used to store configuration data. For larger AD FS deployments, a SQL Server database should be used. A robust, fault tolerant AD FS farm requires at least four servers (two AD FS servers and two proxy servers) in addition to the NLB servers. 5

Figure 2: AD FS Server Farm SOURCE: MICROSOFT TECHNET AD FS Strengths AD FS has several strengths, including: High availability. As a mission critical service, AD FS can be configured for high availability, as illustrated in Figure 2. Federation services. AD FS provides token translation through its STS. In addition, it queries AD DS to add user and group attributes to claims to be used by web services. Provisioning service. Microsoft s Directory Synchronization (DirSync) will synchronize all users in a single forest to Windows Azure Active Directory (Azure AD) in support of Microsoft s online services such as Office 365. AD FS Weaknesses Despite its evolution, AD FS still has some gaps in its feature set, including gaps in its provisioning support and standards support. Minimal provisioning support. AD FS has no provisioning support beyond its DirSync service to provision AD DS accounts to Azure AD, the Microsoft SP data store. Non-Microsoft SPs must provide their own provisioning, which leads to complexity, scalability, and support issues. If the non-microsoft SPs do not have an automated provisioning method, the enterprise must manually manage every account, which can result in an unmanageable overhead and security issues. 6

Minimal standards support. AD FS does not support SAML 1.0, OpenID, SCIM, or the FIDO Alliance (which is driving the effort to develop standards for strong authentication). It also does not support OpenID Connect. This new and popular identity specification is based on OAuth 2.0, which is recognized as the successor to SAML 2.0. Other gaps in AD FS s feature set include: AD FS has no built-in reporting capabilities. AD FS does not have a built-in end user portal to external web services. Users must remember or bookmark the web services they are subscribed to. AD FS has no support for web services that do not support identity standards such as SAML. AD FS does not have built-in multi-factor authentication capabilities. AD FS Summary AD FS is a built-in capability of Windows Server, but it is not without its own substantial deployment and operating costs. It also requires specialized expertise to manage the service and to configure and maintain multiple relationships with web service providers a problem whose seriousness increases for every new web service you trust. Ping Identity Solutions Ping Identity offers two major products in the identity and access management (IAM) market: PingFederate and PingOne. PingFederate is a lightweight and powerful identity bridge that delivers a comprehensive identity management solution for federated access to applications using existing identity infrastructure. PingOne is an IDaaS solution that delivers cloud SSO for your workforce. With one username and one password for users to manage, PingOne offloads the IT department s burden of collecting, configuring and maintaining connections from the on-premises identity bridge to the PingOne cloud service. The one-to-many relationship between enterprise IdP and cloud SPs is hosted in the cloud. The enterprise only needs to maintain an identity bridge with one connection to PingOne, as shown in Figure 3. PingOne is itself a cloud service and is configured to be highly available worldwide. The connection from the IdP to PingOne can be made with the Ping Identity s AD Connect for simple implementations or PingFederate for more complex scenarios. Users gain access to SaaS applications through the PingOne CloudDesktop web portal, which has both desktop and mobile-optimized versions. 7

Figure 3: AD FS + PingOne IDaaS Solution Synergy of Combining AD FS + Ping Identity Solutions Ping Identity products are standards-based, so you are not limited to AD Connect or PingFederate as your identity bridge to the PingOne cloud service. You can use any SAML-enabled identity management platform. AD FS is such a platform, and PingOne fully supports it. This means you can use your existing AD FS solution as your connection to PingOne and gain SSO access to the many SaaS applications on PingOne s CloudDesktop. Setting up a federated trust between AD FS and PingOne is simply a matter of adding PingOne to AD FS as you would add any other SaaS application. On the PingOne side of the trust, a simple guided setup process will enable the connection. After you have configured the PingOne CloudDesktop to provide users access to the SaaS applications they formerly accessed directly, you can remove the now-redundant trusts from AD FS and leave the single trust to PingOne. To provide provisioning capability, you can install AD Connect on any domainjoined IIS server running Windows Server 2008 or greater, with external connectivity over port 443. AD Connect is installed using a simple guided procedure that 8

is part of the PingOne configuration process. It usually takes less than 30 minutes to install. AD Connect is lightweight. Instead of using a heavyweight full synchronization engine, it uses the efficient SCIM provisioning standard to get user identity data from Active Directory to PingOne. In an AD FS + PingOne configuration, the AD Connect federation service will be disabled, as this is being provided by AD FS. Unlike AD FS, AD Connect also works across multiple domains, trees and forests if the trust relationship is configured and established among these differing domains. An AD FS + PingOne Internet SSO architecture has a number of advantages over a standalone AD FS implementation: Your AD DS/AD FS architecture has not changed. Your identities remain in AD DS. Implementation is simplified because you only need one federated trust to PingOne. Because you have essentially outsourced the heavy lifting of SaaS federation to the PingOne service, there is no longer a question of how many SaaS connections your company can effectively use. If a SaaS application is available in the Cloud- Desktop portal and you have established a subscription with the application, you can have SSO access to it. PingOne provides SSO access to SaaS applications that support SAML by extending an enterprise user s identity data to the cloud service provider without providing a password. However, a large number of SaaS applications do not yet support federation. They require that a user ID and password be provided at logon time (known as form-based authentication). Ping Identity recognizes this is the less-than-perfect state that cloud identity is in today. To provide SSO access to these applications, PingOne uses a password vaulting capability that will securely store a user ID and password (which has no requirement to match the user s enterprise credentials) for a given form-based SaaS application and automatically fill in the logon information. Although not a federation solution, providing SSO access to non-saml-enabled SaaS applications is another PingOne capability that AD FS does not provide. Another advantage of an AD FS + PingOne architecture is in the area of reporting and auditing. PingOne provides reporting on SaaS application usage to provide IT dashboard feedback; AD FS by itself has no reporting capability. And should you consider eliminating the cost of maintaining an AD FS server farm, the Ping Identity suite of products provides you several options. If you only need to connect Active Directory to PingOne, the lightweight AD Connect identity bridge installs in minutes on an IIS server, scales to high capacity, and is fully compliant with secure Internet 9

identity standards. If your on-premises identity landscape is more complicated, consider PingOne Enterprise. It gives you PingFederate as an identity bridge to handle a wide variety of configurations, including multi-factor authentication and integration with existing enterprise reporting and monitoring tools like Splunk, HP OpenView, or HP ArcSight. PingOne gives you the ability to dip your toe into the water of IDaaS in the most painless way possible. Without altering your existing AD FS connections, you can set up a connection to PingOne and use PingOne for Groups for free with up to 50 users and 5 applications to see if it meets your requirements. If you move to PingOne for Business, its expanded capability of 1,000 or more users and the entire PingOne applications catalog will allow you to shift your SaaS usage away from AD FS, maintaining only the connection to PingOne. Finally, you can use PingOne for Enterprise, and use any combination of PingFederate, ADConnect, or AD FS to bridge your identities to the internet as you see fit. Integrating PingOne with your existing AD FS installation quickly gives you scalability and options you cannot get with AD FS by itself. You do not have to remove your existing AD FS installation but you can simplify it. The synergy of the two solutions brings web SSO to your users for both federated and non-federated SPs. You can have much more detailed reporting on SaaS activity and a friendly portal for your users, whether they are on-premises or outside your company. AD FS + PingOne quickly gives you a best-in-class, standards-based means to securely integrate your business with the capabilities of cloud services. 10