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

Creating a Global Image of all Your Identities

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

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:

  1. You move your local AD user accounts—or more likely, a sculpted subset of that user data—to populate accounts on WAAD.
  2. 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

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:

  1. The synchronization of identity from the local AD to WAAD, after some level of remapping.
  2. 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 →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

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

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 →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Michel PromptWe’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 →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Explore our New Federated Identity Service at RSA

I’m looking forward to RSA this year, where we’ll announce a major breakthrough in the way companies manage their identity in this increasingly web and cloud-centric world. I’m also proud to see that RSA is integrating our solution into its excellent IdM stack.

I’ll tell you all about it below, but first, I’d like to address a topic that’s been burning up the blogosphere lately.

The Virtual Directory is Dead. Long Live the Virtual Directory!

We all know that it’s not enough to innovate; the success of a new technology is also measured by its degree of integration within the existing ecosystem. I’ve been reflecting on that challenge lately, after reading this piece on Ping Federate’s new authentication chaining capability, which suggests the virtual directory is no longer necessary. Hmm, we know our good friends at Ping Identity are not that radical—just check out the slides from their latest webinar—but I guess you know the old joke: Groucho was a Marxist and Lenin was a Beatle. I will leave it to Nishant Kaushik’s excellent response to explain why authentication chaining is only a very small part of the answer.

Mostly, I’m struck by the fact that the virtual directory—technology my friend Claude and I invented back in the dark ages of last decade—is now such an accepted part of today’s identity infrastructure that people feel free to proclaim its demise. After years of trying to explain what a virtual directory was, that feels like a victory! 🙂

Okay, now let me share some news I’m really excited about.

From Virtual Directory to a Federated Identity Service Powered by Virtualization

Over the years, we’ve advanced virtual directory technology from a proxy-driven routing and remapping engine to a model-driven virtualization solution, which enables you to design the exact identity views required by your applications. Now we’ve taken it a step further, delivering a federated identity service based on virtualization that’s key to the deployment of any secure web application or identity provider (IdP) in a federation—all without disrupting your existing systems. This service hides the heterogeneity of your existing identity sources, and exposes a logical, coherent, secure, and application-friendly view of your users to both internal and external applications. And it drives any business initiative where a global view of identity is essential, including web access management, portal, and cloud integration.

Sounds like a great solution, right? But first, let’s take a look at the problem we’re solving.

Applications, Security Protocols, and Identity Sources—Oh, My!

In any sizeable modern organization, there are many links tying applications, via disparate security and access protocols, to all the different identity sources. I call this the “Star Wars” effect:

Identity Sources

For such companies, many internal, external, web, and cloud-based applications (A) must talk to many identity sources (I) using different security protocols (S), with every factor representing some number (N) of links—and every link costing lots of money ($$$) to develop, manage, and maintain.

When you do the math—A x I x S = N links (x $$$)—it’s basically a shoot-out at the Not-OK Corral, where you’re left with a brittle network of links, protocols, and identity representations that require a whole IT team to maintain. And whether your company is revamping its portal, adding a critical cloud-based application, or acquiring a partner, any changes put incredible (and incredibly expensive!) demands on a critical infrastructure.

An Identity Hub to Reduce Complexity and Rationalize your Infrastructure

Fortunately, there is a well-established pattern for solving the problem of too many links. By creating an intermediate layer—a hub—you can reduce the complexity of M x N interactions to more manageable and linear M + N connections. After all, this is why the airlines fly you through Denver or Charlotte or Chicago, instead of offering the chaos of thousands of direct flights between destinations.

Our federated identity service acts as a virtual identity hub, anchoring your identity infrastructure and enabling you to interconnect all the identities across the enterprise, no matter where or how they’re stored, for smarter security, better authentication, and more finely-grained authorization.

Federated Identity Service
Now, this idea of an identity hub is not new—in fact, identity vendors have been trying to develop (or reinvent) some form of an identity hub for years, from the over-centralization of the ”enterprise directory,” to the efficient but inflexible meta-directory, and more recently the flexible but limited “classical” virtual directory based on simple mapping, routing, and proxy. After many years of experience with customer integrations, we know you need to combine the strengths of all these different approaches, and add a little special sauce on top, so let’s take a quick look at the technologies and processes underlying our solution.


read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail