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.

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 →

In my last blogpost (was it really more than two months ago—I plead CEO-overload!), we looked at how SQL and data integration are essential to the development of a truly useful customer profile. At the end, I promised to step through the process of nurturing relationships, where we guide prospects and customers through each stage, sharing and collecting information in a step-wise cadence. So here goes—and note that I’m using the vocabulary and categorizations from Salesforce, one of the main customer relationship management apps on the market:

  1. First, a set of information is collected from an interested party—also known as a lead—and further information is sent to match the needs of that lead.
  2. After that, the lead is qualified as a prospect, and the sales rep conducts further qualification discussions to move that prospect to the next stage of the pipeline.
  3. At this point, enough information is known on the needs of the prospect to determine if an opportunity for a sale exists. If yes, the sales rep takes the final qualification step by negotiating the terms of a deal.
  4. When (and if) a deal is struck, that opportunity becomes a customer.

What we can see in this nurturing process, as in most business processes or complex transactions, is that the whole operation is built around a series of steps, or a business workflow. At each step, specific information is gathered and you move to the next steps only when the information requirement of the current step is fulfilled, as we see below:


What I am describing here is obvious at the business level—or “conceptual level” in the parlance of the data-modeling world. However, when it comes to the details of low-level implementation at the data structure or database level, things are not so cleanly delineated and as a result, currently deployed solutions are far from optimal. So let’s revisit this pattern as it applies to the integration of a user profile at the level of SQL.

read more →

Last week, we took a look at the challenges faced by “traditional IAM” vendors as they try to move into the customer identity space. Such vendors offer web access management and federation packages that are optimized for LDAP/AD and aimed at employees. Now we should contrast that with the new players in this realm and explore how they’re shaping the debate—and growing the market.

Beyond Security with the New IAM Contenders: Leveraging Registration to Build a More Complete Customer Profile

So let’s review the value proposition of the two companies that have brought us this new focus on customer identity: Gigya and Janrain. For these newcomers, the value is not only about delivering security for access or a better user experience through registration. They’re also aimed at leveraging that registration process to collect data for a complete customer profile, moving from a narrow security focus to a broader marketing/sales focus—and this has some consequences for the identity infrastructure and services needed to support these kind of operations.

For these new contenders, security is a starting point to serve better customer knowledge, more complete profiles, and the entire marketing and sales lifecycle. So in their case it is not only about accessing or recording customer identities, it’s about integrating and interfacing this information into the rest of the marketing value chain, using applications such as Marketo and others to build a complete profile. So one of the key values here is about collecting and integrating customer identity data with the rest of the marketing/sales activities.

At the low level of storage and data integration, that means the best platform for accomplishing this would be SQL—or better yet, a higher-level “join” service that’s abstracted or virtual, as in the diagram below. It makes sense that you’d need some sort of glue engine to join identities with the multiple attributes that are siloed across the different processes of your organization. And we know that LDAP directories alone, without some sort of integration mechanism, are not equipped for that. In fact, Gigya, the more “pure play” in this space, doesn’t even use LDAP directories; instead, they store everything in a relational database because SQL is the engine for joining.

Abstraction Layer

So if we look at the customer identity market through this lens of SQL and the join operation, I see a couple of hard truths for the traditional IAM folks:

  1. First, if we’re talking about using current IAM packages in the security field for managing customer access, performance and scalability are an issue due to the “impedance” problem. Sure, your IAM package “supports” SQL but it’s optimized for LDAP, so unless you migrate—or virtualize—your customers’ identity from SQL to LDAP in the large volumes that are characteristic of this market, you’ll have problems with the scalability and stability of your solution. (And this does not begin to cover the need for flexibility or ease of integration with your existing applications and processes dealing with customers).
  2. And second, if you are looking at leveraging the customer registration process as a first step to build a complete profile, your challenge is more in data/service integration than anything else. In that case, I don’t see where there’s a play for “traditional WAM” or “federation” vendors that stick to an LDAP model, because no one except those equipped with an “unbound” imagination would use LDAP as an engine for integration and joining… 🙂

The Nature of Nurturing: An Object Lesson in Progressive, Contextual Disclosure

Before we give up all hope on directories (or at least on hierarchies, graphs, and LDAP), let’s step beyond the security world for a second and look at the marketing process of nurturing prospect and customer relationships. Within this discipline, a company deals with prospects and customers in a progressive way, guiding them through each stage of the process in a series of steps and disclosing the right amount of information within the right context. And of course, it’s natural that such a process could begin with the registration of a user.

We’ll step through this process in my next post, so be sure to check back for more on this topic…

Current Web Access Management Solutions Will Work for the Customer Identity Market—If We Solve the Integration Challenge

I find it ironic that within the realm of IAM/WAM, we’re only now discovering the world of customer identity, when the need for securing customer identity has existed since the first business transactions began happening on the Internet. After all, the e-commerce juggernauts from Amazon to eBay and beyond have figured out the nuances of customer registration, streamlined logons, secure transactions, and smart shopping carts which personalize the experience, remembering everything you’ve searched and shopped for, in order to serve up even more targeted options at the moment of purchase.

It reminds me of a parable from a classic book on investing*: Imagine a Wall Street insider at the Battery in New York, pointing out all the yachts that belong to notorious investment bankers, brokers, and hedge fund managers. After watching for a while, one lone voice pipes up and asks: “That’s great—but where are the customers’ yachts?

Could this new focus on “customer identity” be an attempt by IAM/packaged WAM vendors to push their solution toward what they believe is a new market? Let’s take a look at what would justify their bets in the growing customer identity space.

Customer Identity: The Case for the WAM Vendors

The move to digitization is unstoppable for many companies and sectors of the economy, opening opportunities for WAM vendors to go beyond the enterprise employee base. As traditional brick and mortar companies move to a new digitized distribution model based on ecommerce, they’re looking for ways to reach customers without pushing IT resources into areas where they have no expertise.

While there are many large ecommerce sites that have “grown their own” when it comes to security, a large part of this growing demand will not have the depth and experience of the larger Internet “properties.” So a packaged solution for security makes a lot of sense, with less expense and lower risks. And certainly, the experience of enterprise WAM/federation vendors, with multiple packaged solutions to address the identity lifecycle, could be transferred to this new market with success. However, such a transition will need to address a key challenge at the level of the identity infrastructure.

The Dilemma for WAM Vendors: Directory-Optimized Solutions in a World of SQL

As we know, the current IAM/WAM stack is tightly tied to LDAP and Active Directory—these largely employee-based data stores are bolted into the DNA of our discipline, and, in the case of AD, offer an authoritative list of employees that’s at the center of the local network. This becomes an issue when we look at where the bulk of customer identities and attributes are stored: in a SQL database.

So if SQL databases and APIs are the way to access customer identities, we should ask ourselves if the current stack of WAM/federation solutions, built on LDAP/AD to target employees, would work well as well with customers. Otherwise, we’re just selling new clothes to the emperor—and this new gear is just as invisible as those customers’ yachts.

Stay tuned over the next few weeks as I dive deeper into this topic—and suggest solutions that will help IAM vendors play in the increasingly vital world of customer identity data services.

*Check out “Where Are the Customers’ Yachts: or A Good Hard Look at Wall Street” by Fred Schwed. A great read—and it’s even funny!