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.”
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:
- 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.
- 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.
- 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.
- 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.
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:
- 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).
- 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!
In my last few blogposts (here, here, and here), we’ve been talking about the best—and easiest!—way to upgrade to ABAC (attribute-based access control), using more flexible group definitions to create smarter authorization policies. And I told you that it’s possible to build these richer groups by leveraging more attributes. So that leaves one essential question—how do we round up all those attributes to build better groups that can drive finer-grained policies? (You will not be surprised to learn that it has to do with federating identities from across diverse sources—but read on, and I’ll explain how all this works…).
As we know, in most organizations, our definition of an identity is stored in some sort of directory infrastructure. And sure, that’s fine if all you’re doing is authenticating users. But authorization is where it gets a little trickier. You’ve heard me say it before: there’s a ton of information about each identity that isn’t part of that basic record. Even if the directory contains the core set of identity attributes for each user, many specific aspects of an identity will be handled by more specialized applications—HR, production, marketing, sales automation, and the like. And getting to all the nuggets that are siloed across these specialized applications is a real identity integration challenge (and that’s our favorite kind of challenge here at Radiant…).
Beyond the Meta/Virtual Paradigm: A Federated Identity Service to Gather Attributes from Disparate Sources
We believe that the solution is not (yet another) centralized uber-directory. The answer is a common coordination effort that’s based around a virtualization layer that creates a federated view of identity out of multiple applications and identity silos. This smart layer normalizes all that disparate data for “curated” views of identity that can be customized for each consuming application. Now, this solution goes way beyond what the market calls a “virtual directory,” although it grew out of that technology. And it’s not a traditional metadirectory, although it centralizes and synchronizes the data in a logical way.
Such a service derives its flexibility from metadata consolidation and remapping, making it easier to manage and deploy. It provides is a consolidated view of your identity, while also adding the ability to delegate security back to the authoritative stores. Basically, it’s the identity counterpart to the federated access made possible by SAML and, we bet in the near future, OpenID Connect and OAuth 2.0. In, short it is the identity infrastructure that enterprises need to access the cloud through those protocols.
So how is this layer implemented? I’m sure some attentive readers are wondering how this works within the realm of directories, metadirectories, and virtual directories. In fact, there is an interesting conversation on this topic going on right now at LinkedIn with Dave Kearns and others, and Radiant will also be hosting a webinar about this soon with Gartner Nick Nikols (although that discussion will center around why you need such a federated identity structure for cloud access and Office 365—be sure to sign up!).
To keep today’s story short (and visual!), we believe that the architecture needed to gather those attributes looks something like the following picture:
Of course, an architecture diagram always looks clean and simple. The devil is always in the implementation details.
Why do you need to federate your identity in order to pull and join your attributes? Well, for the simple reason that even if you have only one identity, most of the time you are known by different identifiers in each application or identity silo. So first, before you can extract those attributes, you need one global, normalized view of your identity. (And that isn’t just a baseline requirement for groups or access policies—this ”smart global view” is becoming mandatory for pretty much any security initiative coming down the pike, along with data management, business intelligence, personalized services, and any other buzzword you want to throw onto the list.)
read more →