We’ve been banging the federated identity service drum for a while now. But no less than Salesforce CEO Marc Benioff has taken up the beat: Identity federation is the next big thing for one of the biggest players in the SaaS category. As Benioff announced, the new Salesforce identity service will “deliver a single, social, trusted identity service across all enterprise apps.”
And we say—welcome to the party! Ours is not the only voice echoing this cry. As our good friends at Ping Identity said: “If you didn’t get identity before, you better get it now.” Gartner weighed in, as well: “This changes the balance of the identity ecosystem,” analyst Ian Glazer said. “…the market may never be the same.”
Federated Identity System: A Central Clearinghouse, Not an Authoritative Store
I was especially pleased by the way Benioff defined the Salesforce identity service as a federated identity management system: “We don’t just use other directories,” he said. “We build a new, central identity management directory. The identity service imports identities from any LDAP directory, Microsoft Active Directory, or any other standards-based directory service and then serves as a central clearinghouse for a broad set of applications.”
And I will confess to feeling a little vindicated—and less alone in the federated identity wilderness (which should not be confused with federated security means, a far more populated place that’s all about SAML, OAUTH, and OpenID Connect. Don’t miss Dieter Schuller’s excellent presentation explaining the difference.) After all, since the full availability of our VDS 6.0 this summer, we’ve been talking about the idea that the central identity store—this directory which acts as a clearinghouse for all other authoritative identity sources—can be best achieved through a virtualization layer with advanced functionality such as identity union and join.
Now, some of you seasoned veterans out there could read “central identity management directory” and think it means that Salesforce is trying to build some super-duper centralized enterprise directory on the cloud, replicating the painful failure of a couple decades back. But if you read carefully, you’ll see that Benioff’s talking about importing identities (and their definitions)—aka pulling—from peripheral sources into a central clearinghouse, not imposing—or pushing—identities into a single authoritative store. And this is right in line with our mantra of the past few years…
Manage Globally and Act Locally: Not Just a Slogan, a Way of Life
Of course, when we look back, the task of creating such a logical centralized system, of aggregating, correlating, and integrating identity from a myriad of authoritative and sometimes contradictory sources, has been littered with many failed attempts. But we know it’s totally achievable—and our customers are a testament to our approach. So let’s take a look at the parameters of the problem—which is very tricky—and see why we believe that virtualization, along with a set of key functions, is needed to achieve this goal.
With all the new applications, devices, identity sources, and user populations companies are managing these days, federation is now a “best practice,” if not a must, and every sizeable company must deliver some form of Identity Provider. But delivering a “logically central” system of identity, one rationalized abstraction point where all your identity exists, is much easier said than done. While federation standards are very established from the security layer side, you also have a thicket of heterogeneous, distributed identity stores in your infrastructure. You’ve heard me talk about this identity mess before, but while these sources may be siloed, they’re also authoritative for many specific aspects of an identity, such as HR, marketing, or project management; each has a job to do.
You can’t just ignore those sources—and trying to recreate all this logic at the center is a nightmare, as our experience with the enterprise directory taught us. In a world where everything is everywhere—identities, apps, devices—you can’t just reinvent identity data into a hard-coded central system. To build your IdP, you must be able to publish, pull, and transform data, aggregating where needed, and integrating where it makes sense, while letting each local system capture the information it needs to do its job. You need a way to harness your distributed local identity sources, elevating the identity and attributes they contain so you can “manage globally,” while letting each specialized silo stay authoritative for what it does best, which is “act locally.”
Beyond Virtual Directory: A Federated Identity System Based on Virtualization
We believe you need virtualization to federate your identity stores, acting as a transformative, consistent, dynamic clearinghouse layer. But you need also a central point to store this complex image and deliver it to the myriad of applications that will consume it. And this is where the evolution of identity virtualization becomes very important. You need a system that can flexibly aggregate, reconcile, integrate, and synchronize all your data into this federated Identity store.
Now, we invented the virtual directory—an abstraction layer that protects your applications from the complexity of backend identity silos. This layer was designed to act as routing logic, forwarding calls to the right sources, and mapping back the results on the fly. And this what’s still delivered by all other “virtual directory” vendors. But we didn’t stop there. Over the years, with lots of feedback from our customers, we’ve evolved our virtualization solution way beyond the virtual directory as a “smart proxy.” We enhanced richness and robustness, adding more complex operations, including identity disambiguation, correlation, and advanced distributed join.
Of course, when you add volume, which is an inescapable reality these days—you have to be able to scale, as well, and this means you need to actually start storing the system. So we materialize this complex transformation in a common directory, with all the advantages of classic LDAP—easy replication, easy scale-out through partitioning—that can be easily accessed by any application. This directory contains a “federated image” of your system, which is kept up-to-date through smart synchronization. And what could be better that a plain classical directory as the end point, the IdP? This is proven technology, just pick your favorite flavor—it’s even been commoditized with excellent results through open source, which makes it way less expensive than the large-vendor solutions of yesterday.
Cloud SSO and a Complete Profile: Identity as a Competitive Advantage
With our model-driven virtualization, you can create a federated directory that captures data from each local store, remaps and rationalizes that data to overcome protocol differences and user collision, then transforms it with a keystroke to meet the needs of each consuming application. Such a system delivers a global list of users where every user is represented once to enable authentication and single sign-on, as well as a global profile of each user for richer, more finely-grained authorization.
And we’ll keep telling you about this federated identity service based on virtualization and why it’s so important for your identity infrastructure. But for now, let me just say that it’s great to have Salesforce validating our approach—and once the hype dies down and the dust settles, we believe we will be a key part of feeding the federated directory structure Benioff references, whether that’s on the cloud with Salesforce, or even Office 365, or on premise.
Welcome to your new identity: federated, virtualized, and fully flexible.