Identity Management for the Cloud Era – Part I: Challenges of User Access Management

Posted by on February 25th, 2014
January 9th, 2017

Many organizations struggle when it comes to proper user access management to applications, systems, and services. It was already challenging to properly provision, de-provision, and manage access to all internal applications, and when cloud applications came into play these tasks became resource consuming and associated risks increased. Forrester Research states that the average help desk labor cost for a single password reset is about $10 to $15 each, while improper access removal might be grave to the company or might pose significant fees for non-compliance, for example, with PCI DSS, Sarbanes-Oxley Act, HIPAA, FCC regulations and many other industry and regulatory standards. In many companies today employees have to remember more than two passwords. As a result, 81% of companies cite complex password policies as the single biggest user complaint about access.

Single user, multiple user accounts
Figure 1: Single user – multiple user accounts

Figure 1 illustrates a user accessing multiple applications with multiple accounts. Each account needs to be properly managed: created, deleted, passwords need to be securely reset.

Identity Centralization and Federation

Companies are looking to reduce the number of passwords that employees must remember by utilizing technologies such as Microsoft Active Directory identity management solution based on SAML or other directories, federated identity applications and protocols. Technologies to support this direction are quite mature and first implementations lead to year 2002, however adoption is somewhat behind and not many Software-as-a-Service (SaaS) providers support them today. For example, Amazon only recently announced support for SAML and many still fall behind and do not offer such functionality.

ThousandEyes recognizes importance of enterprise identity management and supports SAML natively from its 2013-07-10 release. Figure 2 demonstrates a user accessing multiple applications with the same account based on federated identity management and centralized directory.

Single user, single sign on account
Figure 2: Single user – single account

The main benefits of such scenario are decreased costs for password management, improved security (as long as SAML and underlying XML infrastructure itself is secure) and lower risk of being in non-compliance with internal security standards or external laws and regulations.

ThousandEyes with Microsoft Active Directory Federation Services

Previously we have explained how to configure ThousandEyes for federated Web SSO using Okta as identity provider. Now we’ll review configuration for Microsoft Active Directory Federation Services (AD FS) 2.0.

AD FS is a Microsoft implementation of federated identity services based on SAML protocol. AD FS was first released with Windows Server 2003 R2, all following releases of Windows Server also include this functionality.

How SAML works is described in a number of publications including “SAML Single Sign-On (SSO) Service for Google Apps by Google” For the purpose of this document I have created a virtual lab with one domain controller (addc.les.local), one AD FS server (adfs.les.local) running Windows Server 2012 R2, and one Windows 8.1 client computer.

In my Lab internal Web SSO service was assigned an address https://sso.les.local where user is presented a default AD FS web page (similar page might be hosted in perimeter network for access over internet using AD FS Proxy). Figure 3 below demonstrates the page after implementing configuration specific to ThousandEyes, which we’ll review in detail in Part 2 of this post.

federated web sso page
Figure 3: Federated Web SSO page

We will focus on implementation of the following scenario: The user from Les.Local logs into their Web SSO at https://sso.les.local (Les Local SSO) using integrated Windows authentication and clicks login into ThousandEyes. AD FS returns a SAML assertion to the browser of the user. The browser redirects to https://app.thousandeyes.com and submits SAML assertion. The user is logged into ThousandEyes.

Please keep in mind, currently user creation using SAML is not supported; all user accounts must be already registered within ThousandEyes application. By implementing this scenario we are replacing local ThousandEyes application authentication with corporate Active Directory-based authentication. We’ll be publishing detailed configuration instructions to the blog this week, but in the meantime, get started preparing your ThousandEyes application and SSO service from the ThousandEyes Customer Success Center.

Processing...