Integrating the New Identity While Evolving Your Existing Identity
Right at the beginning of the year, I introduced you to Radiant’s Great Migration map, our vision for the identity landscape of today and tomorrow. I’d like to follow up that discussion with a series of posts about the importance of integrating IDaaS cloud services and directories with your existing IAM infrastructure and LDAP applications. After all, unless your company is digital native or you’re starting from scratch with a greenfield deployment, you probably have an identity infrastructure that looks a little something like the lower two-thirds of the map—even as you reach for the cloud.
In any case, IDaaS or “identity-as-a-service” is a very promising direction for a field that’s been stuck in the datacenter for a very long time. The value proposition is especially exciting for larger enterprises, like most of our customers. For one, federation makes it easier to offer SSO and a more user-friendly portal, which is great news whether you’re extending access to new employees and partners after a merger or enabling customers to manage accounts across a world of different services, each one brought online at a different time. A directory on the cloud also abstracts location dependency for applications, which is key for mobility, as well as for multi-national companies with sites across the globe.
Can All Your Apps Speak Federation Standards or IDaaS APIs?
Yet at the level of access/authentication and directory information, these benefits are available only to applications that can leverage federation standards such as SAML and OpenID Connect and/or specific APIs supported by individual IDaaS vendors. Unfortunately, most enterprise LDAP-based applications and traditional WAM portals can’t do either, which means they cannot authenticate through SAML or a cloud directory because that would require calling an API that is not LDAP. While a directory on the cloud is great for new initiatives and applications, to all your WAM and LDAP apps, that cloud directory just looks like another silo. And that means that all these benefits are confined to the new part of the stack—even though they’d be especially helpful for adding agility to the existing stack. So how does a large company with extensive investments in yesterday’s tech take full advantage of tomorrow’s identity and access solutions? (Hint: it involves virtualization and integration with RadiantOne FID…)
Stay tuned for my next post, where we’ll dive a little deeper into the infrastructure—and soar a little higher into the cloud—as we look at how to empower IDaaS with a federated identity service.
Welcome to my third post about the recently announced Windows Azure Active Directory (AKA the hilariously-acronymed “WAAD”), and how to make WAAD work with your infrastructure. In the first post, we looked at Microsoft’s entry into the IDaaS market, and in the second post we explored the issues around deploying WAAD in a Microsoft-only environment—chiefly, the fact that in order to create a flat view of a single forest to send to WAAD, you must first normalize the data contained within all those domains. (And let’s be honest, who among us has followed Microsoft’s direction to centralize this data in a global enterprise domain???)
It should come as no surprise that I proposed a solution to this scenario: using a federated identity service to build a global, normalized list of all your users. Such a service integrates all those often overlapping identities into a clean list with no duplicates, packaging them up along with all the attributes that WAAD expects (usually a subset of all the attributes within your domains). Once done, you can use DirSync to upload this carefully cleaned and crafted identity to the cloud—and whenever there’s a change to any of those underlying identities, the update is synchronized across all relevant sources and handed off to DirSync for propagation to WAAD. Such an infrastructure is flexible, extensible, and fully cloud-enabled (more on that later…). Sounds great, right? But what about environments where there are multiple forests—or even diverse data types, such as SQL and LDAP?
Bless this Mess: A Federated Solution for Cleaning Up ALL Your Identity
So far, we’ve talked about normalizing identities coming from different domains in a given forest, but the same virtualization layer that allow us to easily query and reverse-engineer existing data, then remap it to meet the needs of a new target, such as WAAD, is not limited to a single forest and its domains. This same process also allows you to reorganize many domains belonging to many different forests. In fact, this approach would be a great way to meet that elusive target of creating a global enterprise domain out of your current fragmentation.
But while you’re federating and normalizing your AD layer, why stop there? Why not extend SaaS access via WAAD to the parts of your identity that are not stored within AD? What about all those contractors, consultants, and partners stored in your aging Sun/Oracle directories? Or those identities trapped in legacy Novell or mainframe systems? And what about essential user attributes that might be captured in one of these non-AD sources?
As you can see below, all these identities and their attributes can be virtualized, transformed, integrated, then shipped off to the cloud, giving every user easy and secure access to the web and SaaS apps they need.
Creating a Global Image of all Your Identities
Are you ready for more Microsoft? A couple weeks ago, I posted an overview of the recent Windows Azure AD (WAAD) and Access Panel announcement that heralded Microsoft’s entry into the IDaaS market. In it, I looked at Sean Deuby’s excellent article on the WAAD news, as well as his analysis of Microsoft’s hybrid identity paradigm, which envisions a world where on-premises identity happily co-exists with—and empowers—identity in the cloud.
Now I want to take a deeper dive into how to make all this work, and why we here at Radiant believe you must normalize, aggregate, and remap your identity before shipping it off to the cloud. Today, we’ll look at making WAAD work in an environment made up of only Microsoft identity sources—your basic AD domains and forests. Of course, since even the most Microsoft-centric Fortune 1000 companies tend to have much more complicated environments (SQL and LDAP, oh my!), my next post will focus on enabling hybrid identity within the heterogeneous infrastructure.
But for today, let’s examine the deployment of a hybrid environment where WAAD functions as your service-based identity for the cloud, but your identity continues to be managed and originated on-premises at your enterprise.
WAAD is Your IDaaS, but AD is Still Your Co-Pilot
In this scenario, the most likely use case involves these steps:
- You move your local AD user accounts—or more likely, a sculpted subset of that user data—to populate accounts on WAAD.
- You point WAAD to an instance of ADFS that’s installed on-premises, so it can leverage your enterprise security means.
With these two steps, you’re using WAAD to identify a user by confirming that he/she exists in the WAAD global list, and then delegating ADFS to check the user’s credentials using your AD integrated authentication (Kerberos) and SAML to verify the user. We see this somewhat convoluted process play out here:
How Microsoft Would Authenticate Users for WAAD in a Federated Accounts Scenario
In the diagram above, we see that the operation can be divided into two main parts:
- The synchronization of identity from the local AD to WAAD, after some level of remapping.
- The delegation of authentication—credential checking—via ADFS back to your enterprise AD infrastructure using SAML and Kerberos.
For the first operation, DirSync works with WAAD and your on-premises forest and domains to synchronize your identity. On the surface, this seems pretty straightforward, beyond a little remapping to make the AD version of identity line up with the more specific federated version you’ve created for WAAD. But when you look at the real picture for most medium-to-large sizeable organizations, it’s not so simple.
read more →
At the Ping CIS conference last month, I met Sean Deuby, guru of all things Microsoft for Penton Media, and was impressed by his insightful view of MS world. We both agree that the enterprise’s evolution toward the cloud will go through a hybrid model, as he outlines in his recent article on Active Directory and Microsoft’s identity vision. This model suggests that on-premises and cloud-based identity will learn to work together harmoniously, a future we’re certainly banking on here at Radiant—in fact, we’re working hard to make it happen!
And we both understand that Microsoft’s entry into the IDaaS sector with Windows Azure Active Directory (WAAD) and its new Access Panel functionality will both validate and inescapably redefine this market. In fact, I’m taking to the blog for one of my occasional rants and rambles so I can consider the ideas he raises in both articles here, because I think they signal a sea change—one with plenty of room for vendor innovation, as well as opportunity for enterprises grappling with how to securely connect their unwieldy on-premises architectures to the ever-expanding cloud.
But that’s not all—we’re going all-Microsoft, all-the-time here at Radiant right now. Sean will be joining us for a webinar on September 19, where we’ll host a freewheeling conversation on how to extend your Microsoft environment to the cloud, exploring ways to make WAAD and ADFS work perfectly in this hybrid world.
Validation and Redefinition: Identity-as-a-Service Comes of Age
The IDaaS market began through the efforts of a cluster of start-ups, including some well-funded players who’ve managed to carve out some potential empires on the cloud. But now, with Microsoft bundling basic cloud SSO portal functionality for free with your Microsoft 365 subscription (although we all know that “free” is never really free—there are always implicit costs that come with deployment, just like every key piece of the identity infrastructure)—well, things are about to get interesting. This move will force realignments of everything from pricing to value props, because it’s tough to compete against “free” without offering some serious value-added differentiation.
Obviously, when Microsoft enters a market, that’s a clear signal that the market has traction. But such a behemoth also has mighty big feet, and its arrival is going to trample some grass. We’ll have to see how everything plays out, but I’m sure we’re all wondering what IDaaS will look like in 6 months, a year, and more. One thing I know for certain, though, is that this hybrid identity future will be federated—and your identity is going to need some serious housekeeping to really work the way the press releases and marketing materials will promise. And that’s where Radiant comes in.
Federating Identity: What You Need to Make the Hybrid World Work
You may have noticed, but we’ve been beating the drum about the need to federate your identity to support the cloud for a while now. For us, federation is about more than security access protocols, such as SAML, Open-ID Connect, or OAuth. You must federate your identity layer, as well—and doing it on-premises before shipping it off to the cloud makes sense.
We can see how this plays out by looking into the structure of an entry in Windows Azure AD. You’ll see that this structure is a lot simpler than the definition of a user inside the on-premises enterprise version of AD. And this makes sense, because Windows Azure AD is a normalized, aggregated view of your different local Active Directories—a federated view of your Microsoft identity. But here’s what they don’t mention in the press release: populating WAAD with this sort of common global view won’t happen unless you really massage the data from the different “Local ADs” before you integrate it into this cloud system.
How Microsoft Would Do It Without Radiant: One Forest at a Time
Now as we see above, DirSync is the pipe that connects your enterprise AD to WAAD. But while you can reach any AD domain inside a given forest using DirSync, simply making the connection will not give you the final image you want. You need to normalize and correlate your identity data to establish a valid global list.
read more →
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.”
read more →