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.

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.

Shadow IDs: Why the SP Needs a Corresponding Image of Identity

Of course, when the IdP is authenticating a user against some internal store, the user must first exist in such a store. This seems like a reasonable requirement for the “identity provider.” Perhaps less obvious is why an SP should also have some form of corresponding image of this identity. What’s the point of dividing the work if the information is replicated? After all, you divide the work between an IdP and SP in order to keep the concerns separated, and avoiding redundancies is just good engineering design. But the truth is, you cannot avoid it! Even if the IdP is the initiator and owner of the identity information, the SP still needs to replicate part of this info for its own internal management. To identify a user of its service, at a minimum the SP needs some kind of identifier or “handle” for a given user that matches or correlates with the name it’s receiving from the IdP. (We don’t have to go back to OOP101 to remember that any object requires at least an identity, and in a distributed system, you need a way to remap between internal and external ”namespaces”—right? 🙂 )

Here’s an example—see if you can guess who I was for Halloween this year:

• IdP: internal identifier: JB007 token format: James Bond
• SP: token format: James Bond internal identifier: X2011

In this example, the SP has to know that James Bond = X2011, and the IdP has to know that JB007 = James Bond—because that’s what goes through SAML. So we see that in order to deploy these federation roles, you must seed both the IdP (if it’s not already done) and the SP with some form of identity list and a mechanism for mapping/lookup.

In order for the operation to start, you must first provision the SP with the list of the identities that will access the services. One bulk upload of those identifiers for a given service might be fine in rare cases, but we also know that identities are never static—they go through a lifecycle. What happens when a new user is added, deleted, or changes some relevant info? Whoops—your federation began at access management and now it’s forced to rediscover the wonderful world of identity synchronization and provisioning!

Such services are not described within the federation standards, but make no mistake: they’re essential for securing access for all those SaaS apps you use. Some companies in the federation space would argue that it’s enough to do a poor man’s version—what they’d call “just-in-time” provisioning. But the reality and requirements of your system are more complex than any ad-hoc, piecemeal solution can accommodate.

Think About How Well Provisioning Went Within Your Perimeter…

Then imagine repeating this operation for every underlying identity source in your infrastructure and for each of the cloud apps you’re targeting and you can begin to see the challenge. We all know it’s true: provisioning has never been easy—and why should it be easier now, reaching into the cloud? As I mentioned above, Nick and I would argue that such complexity calls for the establishment of some sort of logical center—a hub where identities can be federated, rationalized, and transformed according to the unique requirements of each SP. At Radiant, we call this a “federated identity system” because it’s the next essential step in developing your federation. Once you’ve federated your security layer, it’s time to federate your identities, as well—only then can you orchestrate those identities within your infrastructure, across the cloud, and even onto the many mobile devices of your stakeholders.

We’ll take a closer look at this idea of the hub in my next post, including ways you can get all the benefits of the metadirectory without the huge expense and hassle—so be sure to check back and stay tuned!

In my last post on digital context, we took a trip back to logic class, looking at how we could begin to describe our world using “sentences” based on first order logic. This essential “predicate semantics” is the foundation of all mathematics, and hence, computing. In fact, it’s the basis for our most key data storage mechanisms (think SQL). With so much of structured information already encoded in this predicate representation, this gives us an excellent foundation for more semantically-driven contextual computing.

Let’s Begin at the Beginning: What is Context, Anyway?

According to my Webster’s, the word “context” comes from the Latin ”contextus,” which means a joining or weaving together. There are a couple of different types of context:

1. There’s context as represented through language, or “the parts of a sentence, paragraph, or discourse immediately next to or surrounding a specified word or passage and determining its exact meaning (e.g., to quote a remark out of context)”.
2. And there’s the context we glean through perceptions, meaning “the whole situation, background, or environment relevant to a particular event, personality, creation, etc…”

It’s this second aspect, the perceptual side, which most would agree upon as the meaning of context. Using this definition, our animal friends are “context-aware” up to some level, able to “read” a situation and act accordingly. But we also have the first aspect, language, which allows us to describe the world in sentences, sharing contextual information. So context can be represented by a set of related sentences about a given subject—that’s our “parts of a…discourse immediately next to or surrounding a specified word.” And what makes this especially interesting from my perspective, which begins in the narrow field of security, a “security context” is a set of facts about a given “subject” represented by attributes and relations between entities. As such, a security context can be represented as a subset of first order logic—or by sentences in a limited, constrained form of English.

So if you can find a way to extract information for a given subject from a structured system and represent it as sentences then you are, in fact, extracting the underlying “application” context for this subject. And—drumroll, please—that’s just what we’ve done! Basically, we’ve returned to first principles here at Radiant, devising a “contextual and computational language” method to reverse engineer metadata from an application and represent it in a way that’s as easy to interpret at the human level as it is to execute at the machine level.

Now, this wasn’t my idea alone—if you follow the developments around the semantic web, you know that the idea to semantically encode the web (HTML/text) so that our machines can more meaningfully interpret our descriptions and intentions is based on this same foundation. But standards such as RDF and OWL depend on adoption, which cannot be controlled and is currently confined to a minuscule part of the web. On top of that, they have a different purpose. While they are tagging text the same way than we do—object attribute/verb value or other object—their objective is for machine to be able to interpret these tags. Our goal is bigger: we want to create sentences that are readable by both man and machine. So unless you can read the XML that’s behind RDF as if it were your own language, why not speak in plain English instead, rather than working at the interface level and supporting RDF at the generation phase? But we’ll get to that part a little later on…

From Database Standards to Semantics: Making Structured Data Searchable Across Silos

There’s no single data standard representation in our enterprises—you have vital data stored across SQL databases, LDAP directories, XML, web services/REST, and more. While useful on their own, this “Babel tower” of protocols, data representations, and abstractions makes it difficult, if not impossible, to connect the information across different application kingdoms. Why is this so important? Because each silo offers plenty of powerful contextual richness that we can leverage well beyond the scope of that application.

This is essential because even in the very specialized scope of security, you can’t adequately protect a system of applications if you don’t have a clear picture of what’s really enforced at the level of each application, and how all your applications are interrelated. This is why, despite lots of tools for creating roles and policies, progress in authorization has been extremely slow. The challenge is not just in knowing what you want to enforce—that’s the easy part—you must first understand what exists and what is really enforceable, both at the level of a single application and across a complicated process made up of multiple applications. For instance, when I talk to people in the banking sector about their compliance efforts, what I hear is that it’s not only about defining what they want to enforce, it’s about understanding what they have in the first place.

Context is also vital because this structured data is so valuable. It represents perhaps only 10% of the data in the world, but 90% of the value that we derive from automation. Without structured data, automation would be extremely limited, and the productivity that we derive from automation would evaporate. So wouldn’t it be great if we could understand at the layman’s layer what exists in an application (beyond just forms and interface), and link it to the rest of the infrastructure?

Think about what HTML did for text and other unstructured data on the web, making it searchable, discoverable, and so much more useful. Now imagine your structured data, all that incredible process-driven information and context trapped in application silos. What if we could read all that information, link all that data, and free all those contextual relationships that exist between silos? After all, it’s not only the facts, it’s the links between facts that build up a context. Go back to the etymology we discussed above: “context” is from the Latin contextus and it means the joining, the weaving together.

Again, these ideas are not mine alone—there’s a whole discipline within the semantic web dealing with “linked data,” based on how you could link information once it’s tagged under the form of RDF, which means subject-verb-object or subject-attribute-value. (See my last post for an in-depth look at this.)

Using Model-Driven Virtualization to Reveal the Hidden Semantics of Structured Data

Here at Radiant, we’re leveraging the same principles as those behind the semantic web, but applying them to all the structured data you have stored in SQL, LDAP, web services, REST, etc… We re-discovered these ideas because we were facing the challenge of integrating identity and its extended profiles across silos. And in order to do that, you need first to translate—to tag—this information into a common language or annotation. The method we use is called “virtualization by model,” and we’re going to take a look at how that works in the slideshow below. (And yes, my old friend Dave Kearns, the wise man of IdM, always teases me about the fact that I’ve been telling this same story with the same slides for an eternity now. So Dave, please forgive me here. As far as I know, the theorems of Thales or Pythagoras are more than 2000 years old now and are still presented with the same original proofs, too…). 🙂

The common language is first order logic, and the method we propose just automates to a large extent the tagging, the metadata reverse engineering and translation of our structured data from multiple specific protocols to this common representation. With this virtualization approach, we can extract application contexts that can be linked to unify these application silos. And because those predicates, with the right vocabulary defined by the users, can be read as a limited, “constrained” form of English sentences, these contexts are intelligible for the non-IT person. While it isn’t Shakespeare by any means, our system delivers English sentences that we can all understand—even machines.

A Sort-Of Pidgin English, Readable By Both Marketers and Machines

This basic “caveman” English allows a business user—the exact person who knows precisely what he needs to define the security policy—to “read” into the “books” of his automated process made of application silos. This gives business users a way to directly understand what really exists and is enforced currently in their applications, and to interact with this information to define the security policies they want to enforce.

These application contexts, described in English sentences (a subset of first order logic), would allow any business user understand what exactly is occurring within an automated process as it is enforced by an application. But all this sounds very esoteric—let’s take a look at how this might work in real life. We saw above that using virtualization by model lets us deliver different “views” of identity to meet the needs to diverse applications, whether they’re expecting LDAP, SQL, REST and yes, even RDF. But we can take that a step farther and deliver views of data designed for the human user, as well, using these plain English sentences I keep talking about.

Voilà, digital context, delivered through the magic of first order logic and model-driven virtualization! 🙂

Last week, I introduced my favorite topic—digital context—and laid out a plan for how to consider the case. Today, we’ll dive in with a real-world example, looking at how freeing context from across application silos helps us make more considered, immediate, and relevant access control decisions. For those of you who have been following along (and thanks for sticking with me in my madness), this is blog 8 in response to Ian Glazer’s provocative video on killing IAM in order to save it. And if you haven’t been with me from the beginning: I’m in favor of skipping the murder and going straight to the resurrection.

It All Starts with Groups: The Simple, Not Especially Sophisticated Solution

Let’s start first with the notion of groups and their implementation. On the surface, nothing could be more straightforward: If I have to manage a sizeable set of users and assign them different rights to applications, I need to categorize those users into groups with the same profile, whether that’s by function, role, need to know, hierarchy, or some other factor. This is the simplest approach to any categorization, creating some “relevant” labels, then assigning people that fit within those label to define groups.

So let’s say we’re creating groups based work functions, such as sales, marketing, production, and administration. All we need to do is list all the people under a particular function, create a label, and then assign this label to those people. Couldn’t be easier, right? The simplicity of the process explains the huge success of groups—and although we implementers tend to make fun of groups as crude categorizations, I would guesstimate that at least 90% of our authorization policies are still implemented through groups. (So much for all that talk about advanced fine-grained authorization! But I’m getting ahead of myself here…)

In fact, we’ve become so dependent on groups that in many cases, especially with sizeable organization where the business processes are quite refined and well managed, we’re seeing that there are often more groups than users! At first glance, this seems paradoxical—after all, what’s the point of regrouping people if you have more groups than people? But the joke is on us technical people because we ignored another key reality: the business one. Sure, we could have a lot of people, but generally a well-managed and productive organization can have more activities (or different aspects of a given activity) that require the multiplication of those groups. So we gave our users a simple mechanism to categorize people into groups, and they used it—talk about being a victim of our own success! 🙂

Basically, we played the sorcerer’s apprentice and our simple formula yielded a multiplication of groups, which quickly became  un-manageable. So we went back to the formula and started to tweak it, creating groups inside groups, hierarchies of groups, and nested groups; introducing Boolean operations on groups; aggregating them into roles, and so on. So what we were just saying about groups being simple? Simple for whom? Simple for the group implementers—yes, definitely. Simple for a user in charge of the initial creation of the group—sure. But add any complexity into the mix and the chaos begins.

So Much for the Digital Revolution: Every Change, Managed Manually

From a computer’s point of view, the assignment of a user to a group is totally opaque—just an explicit list entered by the person in charge of creating the group. This explicit list contains no information about why or how a user is dispatched into or associated with a group. In short, the definition of membership rests with the group owner, which is fine on the face of it. But that excludes any automated assignment of a new member to the group without manual intervention of the group owner. That means every change must be entered by hand—imagine the complexity as people constantly change roles and shift responsibilities. And imagine how easy it would be for an overworked manager to miss removing the name of the person she just fired from just one of the groups he was part of. Now imagine the security risk if that guy’s still got access to sensitive files.

Without explicitly externalizing those rules, those policies, the administration of the system becomes tied to the group owners/creators. The effort of sub-categorizing with nested groups or introducing more flexible ways to combine groups by using Boolean operators just reveals the root of the problem: When you give users better ways to characterize their groups, you are forcing those users to either make explicit the formation rules of their groups—or continue to make every single change manually, even as those changes become more complex and unmanageable.

And that’s how we (re)discovered the value of attribute-based group definitions.

Machine-Readable Groups: Using Attributes to Simplify Management and Make Policies Explicit

We realized that if we wanted to automate, to simplify the management of all these groups, we needed to describe them at the lowest level as the set of attributes that defined a given group, role, and—yes—context. We discovered that groups and policies can be managed in a more finely-grained manner with increased automation (and greater productivity!) if we characterized them as a set of attributes, combining them with the usual arsenal of Boolean expressions and functions. Basically, we needed an explicit computer representation of this characterization, instead of leaving such definitions in the head of an overtaxed administrator, hoping that auto-magically our human semantic would be interpreted and executable by our machines.

So we looked at how we represented those policies, groups, and roles and saw that an attribute-based system was a necessary condition. But unless we go further with this the analysis, we run the risk of oversimplification, of coming up with a solution that’s simplistic, instead of elegantly simple—and that would only create another set of problems down the road.

So we could keep all the elements—group, subgroup, etc.—as separated “entities” and link them to a person, as in the first example above. Or we could fuse them together with the definition of a user, as we’ve done in second example. After all, both implementations can technically yield the same categorization, meaning you can get to the definition of the groups and subgroups you need with the right members in both solutions.

But semantically, we’re not talking about exactly the same thing. In one case, we have a notion of groups and subgroups separated from the definition of the person. In the other, we’ve bolted those groups and subgroups on as attributes of that person. So which one is the right definition? That all depends on what you need in your representation—by which I mean it’s contextual—but it’s very important for us to fully grasp the difference. The decomposition into attributes is key for fine-grained authorization, but unless we have a clear understanding about what we are doing, we can take the decomposition too far. In such a case, the world becomes a chaotic set of attributes, where we can’t see the forest for all those trees. While we can peer into a universe made up of the most elementary particles, most real-life problems demand that we recompose that world by gluing all those objects back together again.

Breaking It Down and Building It Back Up, Better Than Before

And that is where we begin to see the need to not only decompose the world into attributes, but also to reorganize that world into objects, relationships, and context. What you get through this reorganization of your information representation is a more complete view of your system, where authorization can be enforced in a more granular way. This is the way we really intend to do it in our policies, as we would define them in natural language—and that’s exactly what we’ll be looking at in my next blog post.

So thanks for reading this introduction to my favorite topic, and be sure to check back for a deep dive into objects, relationships, and context. I’ll even show you how a marketing coordinator and a computer can learn to speak the same language!

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. 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:

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.

Virtualization + Transformations: The Foundation of SSO and Your Bridge to the Cloud

Not every situation requires all three of these advanced services, but at least one is usually required to ensure that your federated identity contains all the information you need for your specific use case. Once you’ve gone through some or all of these stages, you end up with a “rational” federated image of your heterogeneous system.

And if your main target is to authenticate users and deliver single sign-on, this is where you can call it a day. Such an image of your system makes it easy to identify and check credentials for any given user. All you do is a simple search, followed by an authentication request against the federated system, and you’ve got everything you need: you know if a user is defined in one or more of your identity sources, how to check his or her credentials, and which protocols to use. Once the user found, the virtual layer automatically conducts whatever specific authentication operation is required.

Beyond Credential Checking: Adding Extra Assurance to Authentication

Using our federated identity hub to solve this authentication challenge is a huge win, in and of itself. But for many industries, today’s world demands new layers of assurance—a form of extended authentication, like that second photo ID you have to produce when extra security is required. As service offerings grow more complex and demand greater security, you need different levels of identity assurance, unless you want to fall victim to what Anil John so brilliantly characterized as a “Maginot line of authentication.” His blogpost on identity assurance explained these issues perfectly and I encourage you to read it. For my purposes here, I’m borrowing one of his diagrams.

Here we have the “state” flow for a banking user, along with the requirements in terms of security. Once the credentials have been verified on the left, the other red diamonds indicate decision points where a user wants to access different levels of regulated service—and best security practices call for escalating identity verification. Those additional security challenges provide the right “level of assurance” needed to grant access to increasingly sophisticated services.

As we progress across this activity flow, each step requires more and more information from a user—and this is information that needs to be collected, either at identification/authentication time or as the user goes. So we can see that the authentication process in itself is beginning to demand a richer profile, a set of information that can be progressively disclosed based on a user’s activity. And here’s where the lines between authentication and authorization begin to blur, and where a federated —and context-aware—identity becomes increasingly imperative.

As the need for enhanced security grows, authentication and authorization will form a continuum where information needs to be disclosed and accessed based on context. And now we’ve come to my very favorite topic. Although RadiantOne does a great many important things, the system is at its best when it’s discovering context from across disparate sources to drive deeper security decisions—and build richer relationships with customers. My next blogpost will dive deep into how context works in a federated identity system, then we’ll finish up the series with a closer look at the other half of the security puzzle: authorization and provisioning.

Thanks again for reading, and stay tuned for Michel’s primer on context.