How a Federated ID Hub Helps You Secure Your Data and Better Serve Your Customers

Welcome back to my series on bringing identity back to IAM. Today we’re going to take a brief look at what we’ve covered so far, then surf the future of our industry, as we move beyond access to the world of relationships, where “identity management” will help us not only secure but also know our users better—and meet their needs with context-driven services.

We began by looking at how the wave of cloud services adoption is leading to a push for federation—using SAML or OpenID Connect as the technology for delivering cloud SSO. But as I stressed in this post, for most medium-to large-enterprises, deploying SAML will require more than just federating access. By federating and delegating the authentication from the cloud provider to the enterprise, your organization must act as an Identity provider (IdP)—and that’s a formidable challenge for many companies dealing with a diverse array of distributed identity stores, from AD and legacy LDAP to SQL and web services.

It’s becoming clear that you must federate your identity layer, as well. Handling all these cloud service authentication requests in a heterogeneous and distributed environment means you’ll have to invest some effort into aggregating identities and rationalizing your identity infrastructure. Now you could always create some point solution for a narrow set of sources, building what our old friend Mark Diodati called an “identity bridge.” But how many how of these ad hoc bridges can you build without a systematic approach to federating your identity? Do you really want to add yet another brittle layer to an already fragmented identity infrastructure, simply for the sake of expediency? Or do you want to seriously rationalize your infrastructure instead, making it more fluid and less fragile? If so, think hub instead of bridge.

Beyond the Identity Bridge: A Federated Identity Hub for SSO and Authorization

This identity hub gives you a federated identity system where identity is normalized—and your existing infrastructure is respected. Such a system offers the efficiency of a “logical center” without the drawbacks of inflexible modeling and centralization that we saw with, say, the metadirectory. In my last post, we looked at how the normalization process requires require some form of identity correlation that can link global IDs to local IDs, tying everything together without having to modify existing identifiers in each source. Such a hub is key for SSO, authorization, and attribute provisioning. But that’s not all the hub gives you—it’s also way to get and stay ahead of the curve, evolving your identity to meet new challenges and opportunities.

The Future’s Built In: The Hub as Application Integration Point and Much More

Another huge advantage of federating your identity? Now that you can tie back the global ID to all those local representations, the hub can act as a key integration point for all your applications. Knowing who’s who across different applications allows you to bring together all the specific aspects of a person that have been collected by those applications. So while it begins as a tool for authentication, the hub can also aggregate attributes about a given person or entity from across applications. So yes, the first win beyond authentication is also in the security space: those rich attributes are key for fine-grained authorization. But security is not our only goal. I would contend that this federated identity system is also your master identity table—yes, read CDI and MDM—which is essential for application integration. And if you follow this track to its logical conclusion, you will move toward the promised land of context-aware applications and semantic representations. I’ve covered this topic extensively, so rather than repeat myself, I will point you to this series of posts I did last spring—think of it as Michel’s Little Red Book on Context… 😉

So the way we see it here at Radiant, the emergence of the hub puts you on the path toward better data management and down the road to the shining Eldorado of semantic integration, where your structured and unstructured data comes together to serve you better. But you don’t have to wait for that great day to realize a return—your investment starts to pay off right away as you secure your devices and cloud services.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Welcome back to part three in my latest blog series about bringing identity back to IAM. And when I say bringing identity back, I do not mean just to the periphery—at Radiant, we believe identity should be right at the center of your organization. That’s right, it’s time for the hub discussion. Now, we’ve had this talk a time or two (or ten), looking at the idea that the complexity in today’s infrastructures demands a sort of logical center, a place where identities can be federated, rationalized, and transformed according to the unique requirements of each service provider or application.

If you remember my last post, we looked at metadirectories as our last attempt to centralize identities—and we know how well that went. (It was the same story for the older ”enterprise directory,” as well.) But what if we could keep the idea of a central identity, while achieving this “logical” centralization in a more flexible way—one that respects the role of the silos as masters of their domain? A way that evokes the “meta” part of “metadirectory,” while providing a more agile “directory” part?

And that’s where virtualization comes in.

The Radiant Mantra: Manage Globally, Act Locally

Virtualization is the logical part of “logical center” I mentioned above, and it’s how we can create a smart hub that’s based on the cooperation of the periphery. This idea evokes the exact sense of the word “federation”—federate the work, giving each actor its own role to play.

At the center of such a system is a virtualization engine, busy pulling information from your heterogeneous backends and making that data ready to meet the needs of your applications or service providers, whether they’re in-house, on the web, or in the cloud.

The first step in this “active summarization” is to create a reference table of all identifiers, the “golden list” of all your identities out of many disparate data representations. Once the list is complete, your federated identity hub can produce the new—and many times different—views of identity that your applications need. That’s the “manage globally” part of the mantra.

Now when a request comes from any service provider—to check a user’s credentials at login, for instance—that task can also be delegated back to the correct authoritative local store, thanks to this global reference table. After all, we may complain about identity silos, but they’re not just silos, they’re application specialists, designed to do exactly what they do very well. So their “views” are essential to user authentication and need to be preserved—just think about the role of Active Directory in this food chain. This is the “act locally” part of the equation, and taken together, these actions give you an identity infrastructure that’s truly designed for federation.

But let’s take a closer look at how we got to this idea of “manage globally, act locally.”

The Rosetta Stone of ID: Global Integration Backed by Local Ownership

I’ve made a bold claim: that we need to respect both the global and local views, that it’s not enough to merely pull things into the center like the metadirectory, or to simply delegate and proxy back to the different stores like the most commonly sold form of the “classical” virtual directory. We really need a way to do both. We need to synthesize all user data into a reconciled global list of users but built on top of what already exists, and will continue to exist, because it covers some very specific aspects of identity that we need.

If we can agree on this, then the requirement for a dictionary of identifiers—a “Rosetta Stone” that maps a global identity into its specific application representation and makes it easy to look things up—becomes clear. Of course, life would be easier if we were all operating according to a set of predefined “generic” global identifiers, defined at the start of all processes. But the reality is that we’re dealing with different applications adopted at different times from different vendors—each speaking a different language and checking credentials in a different way. They don’t even agree on the basic building block of identity, the identifier!

But don’t feel bad, we’re all in the same boat—even Pyongyang probably has tons of diversity and duplication in its monolithic identity system, with no common global identifiers. So if you cannot impose a common identifier upon each application, then you have to establish this correlation after the fact. That’s what we call a “federated identity system.” And yes, we believe that the accelerated deployment of federation will require such a change at the level of the identity structure. If any sizeable enterprise wants to manage their users and access the cloud, then the structure of an IdP will require a federated identity system (whether it’s hosted in-house or on the cloud only matters in terms of your particular deployment). I believe that such a federated identity system, acting as a consolidated view of your identity, is the exact technical characterization of the function than eluded the so-called “meta”directory.

The Hook-Up on Look-Ups: Remapping Identifiers Inside the Hub

By mapping each identifier, each “global” identity in the Federated ID system has its corresponding translation in a specific silo. So when you look up that individual, you’re able to use the correct identifier of a user for each given application. So my global identifier might be “Michel,” but I am also known as:

Michel = Mike in A = Michael in B = MPrompt in C

That’s the first function of the hub, establishing that there’s an individual called “Michel” who’s common across systems, but also known by other names.

A Global List from Multiple Systems

A Global List from Multiple Systems

This correlation table is the start of being able to link all the information about a given individual—and it’s no mean feat to pull all this together. Even assuming you have no data quality issues in your system (and if so, I’d like to hire your data entry team!), what happens when you have name collision?

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Welcome back—let’s continue where we left off in my last post, looking at bringing identity back to IAM. I was comparing notes on use cases and best practices with Nick Nikols of Gartner recently and came to some conclusions that might appear quite paradoxical—heretical, even!

  1. Although federation divides the work between an identity provider (IdP) and a service provider/relying party (SP/RP), this decoupling has not eliminated the need for some form of identity syncing and remapping between the two. While it sounds counter-intuitive, the act of externalizing identity from applications to reduce dependencies still requires some form of coordination and identity management between an identity provider and its relying parties. To really deploy federation, you have to do some identity syncing and provisioning.
  2. Then, because this operation has to happen for each identity source and target, medium-to-large organizations acting as IdPs—or hosting their IdP functions as a service—are rediscovering a practical requirement: you need a complete identity hub to simplify the identity orchestration required by the different cloud services (including authentication and authorization, along with provisioning).

Beyond connectors and syncing capabilities, Nick and I were struck by the idea that this requirement for a common hub, this staging engine for identities, whether hosted on premise or in the cloud, reminded us of something…what could it be? You guessed it—it’s the second coming of the meta-directory, back from the (near) dead, or at least a similarly centralized structure that drives your cloud provisioning and access efforts. Now wait, before my wife, my mom, and my dog stops reading this blog, let me assure you: I have not been visited by the ghost of Elvis, even though Halloween was just last week. Before you call me crazy, take a look at this cloud apps slide from the gurus in Redmond, depicting a required architecture for the deployment of Microsoft Office 365.

Directory Synchronization - Windows Azure AD

See, it’s not just the nuts in Novato who see the need… 🙂

Federation Provisioning: Seed the Infrastructure, Keep it in Sync, and Remap on the Fly

Now, there’s a lot here to discuss, but let’s analyze each paradox in its turn, so these posts don’t become War and Peace (or its even longer sequel). For today’s post, we’ll take a look at the idea that federation doesn’t eliminate the need for identity management on the part of the service provider or relying party.

Basically, the IdP converts an internal identity representation into a token, then the SP converts that token and checks it against the internal identity representation. What we’re seeing in the authentication operation is the creation of a token through a remapping/conversion operation on the sender’s side and the finalizing of the authentication through a remapping /conversion operation on the receiver’s end. So a whole lot of remapping and conversion here, and even at the level of authentication, we start to see that the system only works if enough parts of the infrastructure have been seeded with some form of identity list, along with a way to look up identities and map them to the proper format.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

That’s right—we’re bringing identity back… 😉

There is no doubt that IT in general and IAM in particular are facing a sea of change. The disruption of the cloud, along with the emergence and explosion of new devices and form factors, is creating the kind of turbulent environment where major opportunities can be exploited—and major blunders can sink the best organizations. So who will get swept away and who will discover new lands? I’d like to take my next few posts to look at what’s happening in IAM these days and why we believe that federating the identity layer—not just the access layer—is essential for empowering today’s fragmented IAM infrastructures and driving business in a cloud and mobile world. And for a look at the choppy waters we’re all sailing in these days, don’t miss our map of Ye Olde Identity Infrastructure—just click to enlarge:

Ye Olde Identity Infrastructure

As the Chinese curse says, we are living through interesting times. When we look at current trends in IAM, the strongest wave is coming from the federation corner. Now, we can discuss at length which protocols will win the Federation Cup—will it be SAML 2.0 or Open-ID connect/Oauth 2.0? My guess is both—and, as usual, the answer will depend on the problem at hand. Are you focused on access for employees, contractors, and other “internal” users, or is your course set for customer and prospects? But there is common consensus that organizations will have to access services—likely in the cloud—as well as expose their own services to other organizations.

The Rise of Federation: Putting New Demands on Your IAM Infrastructure

Beyond the specifics details of protocols, the blueprint of federation is spreading across the whole IT landscape, and will become dominant over the next 3 to 5 years. The federation pattern divides the task of authenticating/authorizing between two main roles for the participating organization: a Service Provider (SP) (with the Relying Party (RP) in a supporting role) and an identity Provider or “IdP.” This division of work was originally designed for a traditional federation, a group or consortium of companies pooling together services/resources while delegating onboarding, registration, and single sign-on to selected members.

But thanks to the existence of the standards I mentioned above, this same framework is becoming the de-facto access method for SaaS or “cloud” applications. Acting as a Service Provider, the SaaS vendor can dedicate its best minds to delivering and supporting a high value, specialized service to its tenants. And when those tenants are themselves medium-to large-enterprises with thousands of employees or members, the only practical approach is delegating user management—in particular the authentication function—back to those same organizations. In short, turning them into IdPs.

Federation Only Routes Access to an IdP…

Let’s see what this process implies. From a SAAS application, or any external application that is based on the federation pattern, your organization is in charge of managing and authenticating your users. This is a smart way to do things: instead of having n applications trying to manage  users in n different ways, the protocols “federate” their request for authentication, delegating it to an agreed-upon “identity provider.”

Identity Provider

Identity ProviderSo if we analyze a protocol like SAML 2.0, we see that it gives all the details about how the authentication request and response will be made, and we also see that in the agreement between the service provider and the identity provider, the content of the token—the set of attributes that establishes the identity of a given user—can vary widely. No problem there, because different applications or services can require different level of identity insurance and so the protocols support that.

But at a minimum, this means that each of these external applications will require a set of specific attributes to be returned by the identity provider as a proof of authentication, along with additional attributes for authorization, personalization, and other initiatives. It’s like having a single user who needs to present a new boarding pass for every flight on their way to a destination. So as an IdP, you must identify and authenticate a user—we’ll take a closer look at that process in my next blogpost—and then remap the identity information you manage, translating it into the different specific token formats required by each application. This diagram shows how the process works:

The Challenge of IdP Implementation: Managing Different Security Domains

The Challenge of IdP Implementation: Managing Different Security Domains

But here we are just looking at the external aspect, the contract to be fulfilled by the service provider and the identity provider. According to this contract, the authentication request will be handed off to the IdP, which identifies the user, and then returns the proof of this authentication with the required attributes in the format of SAML2. Repeat for each application that talks to your IdP and you have the complete picture.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

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

Welcome to the sixth post of my series in response to Ian Glazer’s video on killing IAM in order to save it (AKA my Russian novel on identity, security, and context :)). We’ve looked at a lot of the issues surrounding identity today, and if you’ve been following along, my perspective on how to solve these issues is probably pretty clear by now (and if you haven’t, you can catch up here: one, two, three, four, and five). We at Radiant feel strongly that you need to federate your identity layer, just as we’ve all been busy federating access. But what does that look like? Here’s how the VDS, our RadiantOne virtualization engine, implements a federated identity service—we’ll be focusing on the highlighted part of this diagram today:

Single Access Point for All Applications

The common abstraction, data modeling, and mapping serve as the “backplane” for the whole system. As we see in the leftmost section of the diagram above, the system starts with the existing identity sources and transforms this identity data through three higher-level services built on top of the VDS virtualization layer.

First, the “aggregation” service regroups the different identity sources side by side. In directory talk, this is like “mounting” each different identity source into its own separated branch. Here, we don’t try to merge the different identities, we regroup them under a common virtual root, while keeping each namespace separated. Metaphorically, it’s like people putting different objects (identity sources) into a common bag (the “virtual directory”). The main advantage of this structure is that it allows you to send a global search, from the root to the top of the tree, to find an identity that can be defined in one (or more) aggregated identity sources.

Then, the “correlation” service determines if there are any commonalities across those different identity sources. Beyond the local/specific identifier for a given identity, the service discovers any correlation based on attributes and rules that can disambiguate an entity—a person or object—from across the different identity sources and representations. From a logical point of view, the correlation service is used to create a union of the different identity sources. The end result is a new identification scheme, where each entity in the system is uniquely—and uniformly—identified by a “global identifier” from across all identity silos. This global identifier does not exist in isolation; it’s also tethered back to each specific local identifier, so we always know where every piece of information lives. After the correlation stage, the entire set of existing identity sources is regrouped into a global namespace, where each identity is totally disambiguated.

Finally, the “integration” service links identities with their attributes for a complete global profile. For any given entity that exists in more than one data source (which we determined via the union operation described above), we can now take advantage of the common link—or global identifier—to “join” different attributes that are specific to each source. Through this join operation, we obtain a global profile out of each local description.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail