Achieving Agility: ID Federation Services

Back in the day (I’m talking 2003 here, so way back in technology years) a lot of hopes and dreams for a more seamless identity management experience were high. That was when Security Assertion Markup Language (SAML) was first coming into vogue and began to see prominent use in identity provisioning, especially for implementing single sign-on (SSO) solutions.

The big concern back then was orphan accounts and simplifying password management. If you recall, this was the Age of Webification and SOA, when everything was being turned into a web application. It made sense, then, to employ a web-native standard to assist with identity management challenges.

Turns out it makes sense now, too.

Everything today, after all, is being “cloudified”. Which is really just a nice way of saying that all your webified apps are moving out there, in the “cloud”. The challenges with provisioning and management (and avoiding orphan accounts or unauthorized access) now focus not just on internal systems, but on externally hosted (cloud-based) systems, as well.

And that’s borne out by results in our 2016 State of Application Delivery survey. When we asked about the challenges respondents were facing with hybrid (multi) cloud environments the two top answers were a lack of analytics to help determine where to host a given application (29%) and not having identified a comprehensive identity management solution (29%). That may be why at the top of the services planned for deployment in 2016 was, drum roll please, identity federation (26%). 

Identity federation is really the maturation (or evolution) of the solutions designed to support automated provisioning, auditing, and management of identity within the enterprise to include systems external (off-premises, cloud). The solution relies on an “authoritative source of identity”, kind of like DNS, against which app-specific identities can be governed. That source is almost always on-premises, because it’s the corporate (authoritative) identity store.

Identity federation then takes advantage of SAML to serve as the go-between for applications outside the control of IT, like SaaS. The ID Federation service mediates between users and the apps they want to access and ensures that when Bob tries to access Office365 that his identity is still valid and authorized to access the application. If not, DENIED. Otherwise, you can be sure that another Power Point presentation will soon be on its way to your inbox.

According to Osterman Research, IT isn’t aware of the need to de-provision an account for 9 days after a user has left the organization. On average, they found, 5% of users in Active Directory are no longer employed by the organization. And don’t ignore the “authorized” part, either, as it’s a risky business given the same research found 19% of employees change their role or responsibilities each year, which may change their level of access.

ID Federation services can also provide SSO capabilities. For example, I can login to our (F5) remote portal, log in once, and then through the magic of ID federation services, automatically launch a number of different web applications – some of them on-premises and others SaaS. I log in once, and don’t have to worry about it again.

And neither does IT, because they’re verifying my role, access levels, and validity against the authoritative source. It’s always up to date – not 9 days later – because the changes don’t have to propagate through some manual or web-assisted process. That means productivity improvements for not just me but for the poor IT folk who would otherwise sit around all day verifying changes using an Excel spreadsheet that someone at SaaS-1 and SaaS-2 sent over via e-mail earlier that day. And yes, that’s actually the way it worked before SAML pretty much became the de facto standard for ID federation of corporate-class SaaS.

But don’t get hung up thinking SAML is just for “user” apps like DropBox and SFDC and Office365. It’s also a very valuable tool for governing the cloud-based systems IT have access to, as well. Consider, for example, that you’ve got folks managing instances and access and services in AWS. That happens (more often than not) through AWS management portal. A portal that can be governed via an ID federation service.

The same reasons you’d want to govern access to Office365 from a centralized, authoritative source is true for governing access to the systems that manage your cloud infrastructure. You don’t want folks who are no longer employed having access to that system, nor do you want to wait 9 days before access is terminated. Eliminating the risk and improving the provisioning workflow through integration and automation via SAML is like a BOGO (buy one get one) sale at your favorite store.

ID Federation services not only improve productivity and reduce risk, but can lower operating costs by eliminating the need to execute costly manual processes (that require oversight) whenever someone parts ways with the company or changes roles/responsibilities.

This capability ultimately improves agility, which means IT is better able to adapt and support and enable business initiatives. When IT is no longer tied by lengthy manual processes or customized integrations, it can change systems with greater ease and alacrity and ensure consistency in policy enforcement without having to jump through a lot of hoops. That means business can migrate, add, and remove systems and apps as needed without being impeded by the need for IT to manually “hook up” all the moving parts required to ensure compliance and access.

ID Federation services are increasingly valuable as a tool to not only make users lives easier with SSO and federated access, but to improve agility, reduce risk, and lower operating costs associated with managing the growing number of apps we need to use every day on-premises and in the cloud.

Feel like digging into the details of SAML? Check out this Lightboard lesson on SAML from our own John Wagnon.