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