Identity Management for On-Premise Applications
Our industry today has some very proven technologies for providing a single set of login credentials to applications installed on-premise. Most commonly, companies use a central Identity Management system (e.g. Microsoft Active Directory/Oracle Internet Directory/IBM Tivoli), and these systems implement an LDAP interface that 3rd party applications can call to validate user credentials.
This allows end users to login to their internal HR portal, SharePoint site, or local Documentum Webtop with the same credentials they used to gain entrance into their Windows Desktop, and is termed SSO (Single Sign-On). This has dramatically improved the end user experience, as well as improved the ability of IT to mange the risk and policies surrounding identity management.
New hires, promotions, and role changes means that the central identity system is continually updated. Transparent to end users, third party applications query the Identity Management system periodically to find new users, change authorization based on group membership, and deactivate users when they no longer require access.
Federated Identity Management for Cloud
Fast forward a few years, and applications that at one time seemed anchored to the local datacenter because of data security concerns are now being transferred to the Cloud at a generous pace. IT groups are being forced to consider how to provide Identity Management not just to a few established SaaS applications, but to an ever growing number of critical external business applications.
What companies need is a way to establish a trust relationship and contract between themselves (the Identity Provider), and external applications/services (Service Provider). This is where the concept of Federated Identity Management finds its purpose. The Service Provider (EMC OnDemand) is told that it can absolutely trust a certain host on the Identity Provider side (e.g. your Active Directory FS) to vouch for a user’s validity. So when the IdP says the user is “johnsmith”, the Service Provider takes that as truth and allows this user into the web application as “johnsmith”, no questions asked.
That’s a lot of trust. How is that established?
The first thing to understand is that FIM (Federated Identity Management) is more than just a technical exercise. As mentioned above, trust is a key component on both sides and the traditional vetting done in any business relationship is still required: industry reputation, age of business, phone meetings, email validation, etc… Additionally, certifications such as SSAE SOC and PCI can help organizations determine a Service Providers’ compliance level with respect to data policy, privacy, and auditing.
On the technical side, FIM requires the exchange of certificates so that a Circle of Trust is established and the IdP and SP can securely exchange messages and validate identity. There are several standards for federated logon, but SAML (Security Assertion Markup Language) is one of the most common in the enterprise. This standard defines how an end user is directed through the process of providing credentials, and then redirected back to the target application.
EMC OnDemand Implements Federated Identity and SSO
EMC Documentum products like Webtop have always offered Single Sign-On capability for local on-premise installs. The EMC OnDemand team wanted to raise the bar and deliver not only the basic SSO experience, but silent SSO, where end users do not ever have to enter credentials – they simply go to the application URL, and are sent straight to the main application screen.
Using the SAML 2.0 Web Browser SSO Profile, along with an Identity Provider configured to use Kerberos, silent SSO is now an option for EMC OnDemand users. The IdP uses Kerberos solely on the IdP side for authentication and then sends a SAML Assertion to the Service Provider where it is consumed and validated. Using this flow, the OnDemand team has implemented Silent SSO for the following applications:
- Webtop 6.7 SPx
- EPFM 1.x
- xCP 2.x
- D2 4.x
Note that authentication using LDAP or SiteMinder over our encrypted site-to-site VPN connection is still a perfectly legitimate option for customers wishing to leverage their current infrastructure. However, protocols like Kerberos and NTLM will not work across the VPN because they cross domains.
User Provisioning and Synchronization
Once you solve federated login, it’s tempting to stop and call it a day, but there is still the issue of user provisioning, roles, and synchronization. Employees will change roles, leave the company, get married and change their name, or move offices and all these might affect their access in Documentum applications. The SAML assertion only sends critical metadata, and isn’t enough to keep the dm_user objects valid.
There are two ways to do this. The first is to simply call the out-of-the-box LDAP Synchronization job available from Documentum for traditionally local deployments. Based on querying your LDAP enabled Identity Server, it can automatically create new users, mark users inactive, rename users, and change their groups. This requires that you allow LDAP communication over the VPN connection between OnDemand and the on-premise datacenter. This channel is very secure, and there is no external internet access from your OnDemand vCube to the public internet.
The second way is to capture every critical event in your Identity Management system (new user, updated user, move user, etc.), and you then send it to the repository via a DQL statement (update user or alter group statements with DFC/DFS). This would be too labor intensive and error prone to do manually, and you would most likely write a small utility to capture these Identity Server events and push changes to the repository. But this approach does not make much sense when the out-of-the-box LDAP Synch from Documentum already has more than a decade of development and troubleshooting behind it.
There are emerging standards such as SPML and the even more promising SCIM, that may lead to a non-proprietary synchronization interface, but adoption has not started yet and the other big providers like Salesforce, Google, and Webex still rely on proprietary solutions. So we strongly suggest LDAP Synch at the moment, with a long term view toward the emerging industry standards.