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!
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
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 →
In my most recent post, we looked at how today’s static groups are an essential building block in most policies used to “authorize” access to application resources. So when we talk about providing finer-grained authorization for an existing application, we are essentially talking about finding a better way to dispatch users to the different existing roles. Now, these roles are mostly associated with an application’s resources, which are pretty stable—except when the application allows a user to create new “resources,” such as report pages, that can be shared and hence could need authorization.
Because roles and application resources are created at application design-time, they’re only updated when there are product upgrades and new releases. So unless you’re facing a complete new release of an application with major new features (and hence new resources), the finer-grained mechanism for authorization—the real degree of freedom that exists for users of an application—resides in your ability to dispatch people to different groups and to switch those groups between different roles as the business demands.
Give Me Granularity or Give Me Death: The Evolution of RBAC
We know that more granularity at the level of authorization translates directly into more flexibility at the level of business. With greater granularity, you’re free to dispatch people into roles and groups according to your business requirements—and ideally, you don’t have to lean on the IT team as much. But here’s where the notion of “static” groups starts to become a hindrance for better business agility within the security realm. In fact, the whole progressive evolution toward Attribute-Based Access Control began with groups based around a static association of “labels” with respective populations, such as “Sales,” “Marketing,” “Production,” “Gold” and “Silver” customers, and the like:
Step 1: RBAC Based on Static Groups
But usage quickly dictated the introduction of a finer-grained way to characterize these populations. Hence, the introduction of subgroups:
Step 2: RBAC with Sub/Nested Groups
Notice that the introduction of one level of sub-grouping is equivalent to adding a second column of labels that now subdivide each group. If we go a few iterations further, we see the introduction of multi-level grouping, for a full hierarchy of groups:
Step 3: RBAC with Sub-Groups of Many Levels
Implicitly, even if those levels are not named, you can think about each of them as a sublevel of the group hierarchy (sublevel 1, sublevel 2, etc…). But as this hierarchy starts to grow, we quickly discover the management challenge this poses. Sure, you get a finer-grained way to dispatch your users, but you have to satisfy two constraints:
- You need to define a vocabulary that’s consistent across the entire organization—and if this set of labels is not enforced across the org chart, you’ll not only have a data quality issue, you won’t be able to give the right person access to the right resource. So if one set of people in your organization creates a group called “Product Marketing” and another “Product Management,” you need to know whether these are two completely separate groups, two groups with some overlap, and or if they have any dependencies, where one group is a subgroup of another.
- Once the group labels are created, you still need to assign/administrate those people to these different groups. And, alas, the information about who belongs to which group is only in the mind of the administrator, which means these assignments are done manually, and not by any data-driven rule. So it’s labor-intensive and potentially a bottleneck in an otherwise automated authorization chain.
Last week, I posted about a syndrome I called “trapped in the future.” We often get stuck in this kind of future dreaming, because even if the target we want to achieve is great, the challenge of getting there seems so high. We tend to overplay the characteristics of the ideal solution, imagining the perfect world down to the excruciating details, only to finally drop out of our dream with a long sigh, telling ourselves: “oh yeah, one day…but not today.” And just like people who believe the grass is always greener in neighboring yards, we ignore the fact that, yes, we also have green shoots—the beginnings of a solution—showing up in our own garden.
From Roles to Attributes Via Groups
So in search of how to deliver ABAC today, let’s first examine what we have in our existing security backyard. The current model that is predominant in modern applications is role-based access control, or “RBAC” (of course, every sizable enterprise also has a handful of legacy apps that cover the gamut of authorization concepts from ACLs to DAC). So let’s take a look at the best practices and principles behind RBAC. The two next pictures summarize the story.
First, roles and permissions are defined at design time:
Then, groups are assigned to roles during deployment:
The idea is to divide the authorization process into two steps: design and deployment. And it makes sense because it matches the division of work between:
- The application designers who are in charge of creating the applications and defining the main use cases and the abstract profiles of the people who will be using the application—the so-called “roles.”
- The end users who will be assigned to those roles at deployment time through the groups mechanism. These users carry out their tasks, without tinkering with the applications in any way.
So, in the case of a web access management package like SiteMinder, this division of work shows up in the following policy architecture:
So let’s reexamine what we have. When it comes to authorization, most “relatively” modern security applications (WAM, NAC, etc…) follow the RBAC-model. This approach divides the process into two steps:
- Design, where you define the policies enforced behind each role.
- Deployment, where you assign groups to roles and control access and authorization through group membership.
Since an application evolves relatively slowly—there aren’t new releases of functionality or policy every two days—any changes follow the lifecycle of the application.
read more →