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.

Your Guide to a Federated Identity Service

For many major enterprises, the existing identity system is more ocean and less 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.

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

What’s in a Name? Everything…

Some years ago, we put together a fun little map that shows some of the dangers our customers face in the treacherous waters of Identity Management. But now, after meeting with our customer advisory board during the recent Gartner IAM event in Las Vegas, we’ve had to expand the map to include the cloudy skies of “Azuria” and “Amazonia.”

Your Guide to a Federated Identity Service

Many of our largest customers—including Fortune 100 companies—are looking to shutter their data centers and move all operations, including identity, to the cloud. Luckily, Radiant will be right by their side, helping our customers streamline operations and secure their application portfolios. One of the main reasons we can be so helpful is that we’ve evolved the virtual directory technology we pioneered way back in 2000, moving from a proxy-driven tool for aggregating across disparate data stores—which was a huge innovation at the time and still useful in many situations—to a federated identity service based on advanced virtualization, or what we call “FID.”

(Virtualize, Transform, Store) + Sync = FID

This federated identity service gives you complete identity integration from end to end. And it’s more than just an acronym change. Moving from VDS to FID signifies the evolution of identity integration from a lightweight tactical solution to a strategic identity service. The challenges of identity management have only gotten more complex over the years, with the rise of digitization, mobile services, and the cloud. Given the new constraints and challenges facing today’s identity management, we’ve evolved and modified this architecture over the years—in a dramatic way.

The result is an advanced identity service combining real-time synchronization, identity correlation, and directory storage, and leveraging our patented identity virtualization technology. The main challenge of modern identity systems is to address two conflicting trends:

  • The multiplicity, heterogeneity (AD, LDAP, SQL, APIs), and distribution of authoritative identity sources.
  • The need to present a common global view of identity to applications, no matter where they are—on premises, on the web, or in the cloud.

As an entirely new “identity service” architecture, RadiantOne combines identity information from local sources, then normalizes and generalizes it into a global service. This is what enables companies to authenticate and authorize users across a diverse array of applications, no matter where they’re hosted—and it’s what will enable our customers to take the next major step, shipping their identity into the cloud.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

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