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!

The post From Groups to Roles to Context: The Emergence of Attributes in Authorization appeared first on Radiant Logic, Inc

Although my French heritage and Math background prefer to start from theory and illustrate through examples, my newly American pragmatic tinkerer side is planning to do a quick roadmap here, then look at examples from our existing systems and, through them, make the theoretical case. It’ll take a few posts to get there, but then, I’ve really been enjoying blogging lately, as my manifesto in response to Ian Glazer will testify. Read it from the beginning, if you’d like a peek into my recent madness: one, two, three, four, five, six.

Context Matters: Where We’re At, Where We’re Headed

We’ve already seen the word creeping into marketing materials, but one of these days—okay, maybe months or years—it’s going to be more than a promise: digital context will be everything. As we get closer to digitalizing our entire lives, we’re also moving toward a context-aware computing world. Now, when we’ve talked about context-aware computing so far, it has seemed like one of those woolly concepts straight from a hyper-caffeinated analyst’s brain (or an over-promising marketer’s pen). But the truth is, any sizeable application that’s not somehow context-aware is pretty useless or poorly designed.

Sure, there are pieces of code or programs that exist to provide some transition between observable states and, as such, are “stateless.” And I know that on the geeking edge, it’s trendy to talk about stateless systems, which are an important part of the whole picture. In reality, however, the world needs to record all kinds of states, because a stateless world also means a world without any form of memory—no past, present, or future. So it’s not like most of our programs and applications are not context-aware. They are, and most of the time they’re pretty good at managing their own context.

The problem is that we move from context to context, and in the digital world this means that unless those programs, those agents, those devices share their context, we are facing a stop-and-go experience where the loss of context can be as annoying—or as dangerous—as an interrupted or broken service. The lack of context integration can mean a bad user experience—or a dead patient due to a wrong medication. In a world where actions and automated decisions can be taken in a split-second, this absence of context integration is a huge challenge. Nowhere is the issue is more acute than in security, in authentication and authorization.

The Big Question: What is Context?

This is what we’ll consider over my next few posts—what context is, how we represent it in current programs, and how we could link each island of context for a fuller, more fluid picture of how everything interrelates. We’ll begin by observing how authorization enforcement has evolved from the use of groups to roles to attributes and try to characterize what is context in those specific cases.

Then we’ll see how generalizing those observations and combining them with an intuitive, natural language description of context can guide us toward a solution to represent and link context across data silos.

Of course, since I’m all about evolution and not disruption, we’ll look at how such an implementation can leverage existing databases and directory structures to deliver the same advantages—familiarity, experience, scalability—while cancelling the current limitations, such as both systems’ known inflexibilities and the problems of large-scale distributed deployments.

Finally, I’ll illustrate how this new category of software—what I call context servers—can be leveraged, first in security and later as a way of gluing together our existing application silos.

Be sure to check back to join our discussion of using context to drive policy development and authorization enforcement.

The post In Context: The Next Frontier of Your Digital Identity appeared first on Radiant Logic, Inc

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.

The post Bringing IAM Back to Life with a Federated Identity Service: Leveraging Your Silos for Authentication and SSO appeared first on Radiant Logic, Inc

The latest version is a big step forward for RadiantOne, meeting our longstanding vision of a single product that federates access and identity alike. We take pride in a decade of expertise harnessing identity virtualization to solve infrastructure challenges. Now, with major upgrades to our Cloud Federation Service, we’re providing a one-stop solution for integrating identities across data repositories, enabling authentication through social networks, and managing access to hundreds of supported applications.

For more about the vision behind RadiantOne 6.1, be sure to read the full press release.

RadiantOne 6.1 brings new features and upgrades for Identity Management:

• Tailored backend handlers for leading cloud applications, allowing VDS to provide unified access and provisioning
  Salesforce, Google Apps, Office 365, Sharepoint, Concur, Workday, and many more standards-compliant applications
• Unified web-based control console for VDS
• New Web Portal design, including dedicated mobile device version
• Expanded protocols to access RadiantOne VDS
  SCIM, RESTful APIs, and enhanced SPML
• Support for RSA’s Distributed Credential Protection
• Improved monitoring and alert tools
• Rich logs available in CSV

… and Access Management:

• Easy configuration of the Cloud Federation Service (CFS) as an Identity Provider or Relying Party via metadata
• Support for new trusted identity providers with easy wizard-based setup
  Supported IdPs include Microsoft, Facebook, Twitter, AOL, Paypal, Verisign, and more
• Individually-tailored support for scores of new relying parties and cloud applications

A free trial download of the RadiantOne federated identity service is available – grab it now!
Do you have any questions about what RadiantOne 6.1 can do for you? Contact us today.

Try RadiantOne 6.1 →

The post The Next Big Leap in Identity and Access Management Is Here appeared first on Radiant Logic, Inc

A Millions Paths to Everywhere: The Internal Authentication Challenge

As we discussed in my most recent post, authenticating users and securely communicating authorization information with a cloud application—or any web-based portal—requires a common endpoint acting as the enterprise IdP. We also know you’ll need to be able to access multiple cloud applications, such as Salesforce, Workday, and Google Apps, as your enterprise moves toward this model. And we’ve seen that you’ll need many token translations on a per-application basis. But this is only one part of the requirement.

Another key function to support is being able to authenticate an incoming user against multiple internal authentication sources. Think about all the legacy applications and identity stores deployed across your infrastructure, with their various authentication methods and protocols—they’re all over the map, right? First, you encounter the AD domains, and get lost in all those forests. The authentication method here could be name/UPN and password or based on Kerberos and Windows integrated authentication. But the user could also be stored in some SQL database with a proprietary hard-coded password encryption. Chasing the user across diverse forests and data stores and knowing which authentication method is appropriate for presenting and checking credentials is a full-time job—one that predates the challenge of cloud applications. In fact, the search for a common identity structure has been a primary headache for IAM for as nearly long as the category has existed. Multiple attempts have been made to solve these issues, from in-house script-and-sync to metadirectories to virtual directories. These new requirements for supporting the cloud have just made it more acute.

No matter what you call it (or how it works)—whether it’s an enterprise directory, metadirectory, or virtual directory—the logical mechanism you need is a federated form of identity. Why federated? Because you don’t want to reinvent this layer, which already exists in a highly distributed, heterogeneous way across your identity silos. Better to tap into what already exists, while giving your underlying data more scope and flexibility by bringing it—or a flexible representation of it—into an identity hub. Now, you could implement this hub in many different ways, but we believe that a virtualization layer, based on a global data model that rationalizes and reconciles the different local views, is the most effective way to do it. And in a world where you will connect to multiple applications using “federation” standards, you need to do more than just federate access via the SaML or OpenID Connect layer—you need to federate your identity layer, as well. And the way to get to a federated identity is through virtualization.

All Roads Lead to the Hub: The Need for a Common Attribute Server and Better Provisioning

But authentication is only the first challenge for bridging your identity infrastructure to the cloud. Beyond providing secure internal authentication, you must also deliver attributes that are required for groups, access rights, and authorization. So as an identity provider, you will need to act as (or be coupled to) an attribute server. And then there is the huge challenge of accounts and attribute provisioning. Despite tons of progress in terms of user interface, connectors, workflow, business logic , transaction support, and standards (anyone remember SPML?), provisioning on the internal, legacy side of applications has only encountered limited success and remains a stop-and-go process. I believe you need all the features I just mentioned, but unless you want to go through endless iterations of manual workflow definition, you need an automated system that can normalize the different versions of the truth for your identity, before pushing it through your provisioning and logic engine.

Fast forward and think about the n different applications in the cloud you need to provision to, and it’s like déjà vu all over again…with even more complications. So again, as both a final authoritative source of your identity and as an attribute server, you will need a rationalized view of your identity, a federated Identity system.

This diagram illustrates how such a federated identity service would enable authorization and provisioning to cloud-based applications, using attributes from across your heterogeneous stores:

Next time we will look at the architecture of this federated identity, or “FID,” and then we’ll end this series with a deep dive into my favorite topic—context—along with graph and protocols support.

The post The Federated Identity Service as a Hub for Authentication, Authorization, and Provisioning appeared first on Radiant Logic, Inc

And I’ve had lots of flight time since then to think about what he said. I’m a “coder” at heart (and you know the old adage: “program first, think later”), so I jumped quickly to the hardcore story about SQL, graph, and LDAP, with lots of good justification for that focus—and you can follow along here, here, and here. But I agree that the drivers, the pain points that are forcing us to re-think identity management as we know it, are the fast adoption of the cloud and its multiple SaaS applications on one side and the unstoppable growth and demand for access through all kinds of mobile devices on the other.

And here I believe is where the analysis from Ian is at its best.

Let’s look at the two main players (beyond the dreaded form-based, name/password authentication) when it comes to federated access to an application that’s delivered on the cloud (or even on the internet). Our best candidates here would be SAML 2.0-based federation and Open-ID Connect/Oauth 2.0. You would find SAML 2.0 in use with most SaaS vendors. And more and more, your web applications, Facebook, Google +, Windows Azure, and others can act as a “trusted identity provider” to allow external users to sign to your application.

I will illustrate the issue by looking at SAML 2.0, but the need for mapping “external identity” to your own internal representation will still exist, even when you trust Facebook.

Federating Access and Federating Identity

One of the main values of a “federation” layer is to funnel authentication requests to an “identity provider” or IdP. In the case of SaaS applications, this redirection points to your company—basically, your enterprise is the IdP.

Once the IDP receives the authentication request, it must:

1. Authenticate the user against some “internal authentication sources,” such as AD, LDAP, or databases.
2. Map the internal identity representation to the external format the SaaS application requires.
3. Encode the authentication token based on the mapping result.
4. Send it back to the SaaS application.

The process is illustrated here:

What Could Go Wrong? The Care and Feeding of Your IdP

This process raises a couple of major challenges. The first challenge is the need for internal authentication and remapping. The first three operations—authentication, mapping, and token creation—need to be done by you, the identity provider. All the SAML layer does is move the token around; all the rest is up to you. So what does this mean for the enterprise-as-identity-provider? In a typical scenario, you would have to map InetOrgperson attributes to a SAML2.0 attribute or a JSON structure. And that can get very complex very quickly.

The second challenge is that there are as many remappings as there are applications. The translation and mapping is based on a given list of token attributes for each application. So the mapping for Google apps has nothing to do with the mapping for SaleForce, etc. Basically, every SaaS application speaks a different “dialect” of SAML—and expects to get that exact language back from the IdP.

The bottom line is that without an authentication hub and application-specific mapping to act as a bridge between your internal and external systems, you still have what I call “Star Wars” syndrome when it comes to authentication—and that’s not the fun part with light sabers or ewoks.

This diagram shows the Star Wars effect happening in today’s identity environments (I sense a disturbance in the infrastructure, Luke):

Now that we’ve established what’s ailing IdM these days, I’ll spend some time on the cure in my next blogpost. Be sure to check back for a look at how a federated identity service solves the “Star Wars” syndrome and lets you leverage your current infrastructure to do some very cool new things (think context-aware applications).

The post Token Translation and Internal Authentication: Where Your Federation Needs a Federated Identity appeared first on Radiant Logic, Inc

“…. I believe in approaches that build on existing investments. IAM has to change, no doubt about that. But there will still be a lot of “old school” IAM together with the “new school” parts. Time and time again it has been proven that change without a migration path is an invitation to disaster. Embrace and extend is the classical migration methodology for classical technical transformative strategies.”

Anyone who’s been following along understands that Martin echoes my perspective here—I am all about taking what still works and making it work better. So before we dive into the global picture about what is dysfunctional with current IdM deployments amid the clamor for access (SSO and cloud), access rights (authorization), and governance, I want to share some final thoughts on identity representation and storage.

SQL and LDAP: Strengths and Weaknesses

As I mentioned in my most recent post, if we’re focusing only on finding the most flexible, non-redundant, easy-to-maintain system to represent and record identity (and information in general), it’s tough to beat the relational model. And as a result, the majority of our applications are based on SQL, which means the largest chunk of key identity information is also managed by SQL.

While it’s one thing to accurately capture information, however, querying and retrieving this data is another story. Fast lookups—especially those involving some form of contextual navigation and link-hopping—require a lot of “joins.” And joins are a very slow and expensive operation with SQL, because each join means a “multiplication of links” between objects. So after two or three hops, you have exponential growth of your database operations—and even on the fastest computer in the world, an open and potentially infinite number of operations will take forever.

The key problem with navigating hierarchies or graphs in SQL is that the paths are generated on the fly—and this is precisely where hierarchical or a graph database is strongest. In such tools, the links are hard coded and stored. Because the paths are pre-defined through indexation, you can always pick your starting point and navigate quickly, thanks to these pre-established paths.

And here we have the dilemma: on one hand, we have a system that reflects reality in a faithful, non-redundant way, not only capturing the information about a given object, but also reflecting the relationships around that object. And it can also generate all the paths to and from that object, whether in a graph or a tree. But if there are a lot of relationships—a lot of context surrounding that object—those queries will be slow and, in some cases, with a response time that’s difficult to determine. And that doesn’t work in a world where users expect immediate access to resources.

Or you have a system that’s easy to navigate, once you get the data in—but far from optimal when it comes to write and update. Redundancy is one big challenge, and being able to flexibly modify the structure—deleting or updating a link—is another.

What If: Imagining a World without LDAP

I know LDAP is no longer fashionable: Ian is leading the charge on that, and on many points he is right. LDAP is a kind of lost art; for the younger web 2.0 generation—the JSON/REST crowd—anything that is not based on a browser and HTTP is like Cobol (aka, the dinosaurs). Of course, you have to be careful with fashion and trends, because there’s always a next generation. For instance, the Apps/APIs IOS/Android crowd looks at HTTP and HTML 5.0 as “designed by committee,“ and uncool, to boot.

Let’s imagine for a second, though, that we killed all those LDAP servers and their derivatives. First, many of our portals would stop authenticating and authorizing, and that’s only considering the external users—the “Sun” side of the market. If we ended Active Directory, as well, many of our SharePoint portals would stop in their tracks. I cannot even imagine the state of our internal networks, our enterprise intranets.

And finally there is a lowly function that we cannot just ignore: the email address. Yes, those weird conglomerations that often act as a proxy to your unique identification, your “login.” Most email servers are using LDAP or some form of LDAP for email address lookup. To some extent, the problems with LDAP are a bit like the problems we have with DNS (yet another tricky naming service…). We hate them, but we cannot just kill them—or not that easily. As Steve Jobs used to say, you only know the value of something once you lose it.

Embrace and Extend: The Identity Bridge to Somewhere

As Martin says above, I believe it’s better to embrace and extend, to evolve. So let’s look at how we can use two of the mainstays of our identity infrastructure—SQL and LDAP—and give them new life by bridging them through virtualization and federation. Let SQL record and capture identity and information as it does behind our multiple applications and then “publish” that data in a specialized identity look-up and attribute-oriented store, such as our old friend LDAP. (By the way, this virtualization layer approach would also work going from SQL to graph, if graph databases suddenly replaced LDAP.)

Such a system offers the best of both worlds. Identity management, or the identity representation and storage side, at least, would be reconciled with the rest of the infrastructure: “a part of” and not just “apart,” as Ian said. Before we dive into the analysis of how such a SQL-to-LDAP bridge could be built, I would like to reiterate that this approach— what we call “model-driven virtualization”—is not applicable only to the pair SQL/LDAP. It also works going from “N variation of LDAP” to “canonic LDAP” (such as AD-to-LDAP or Novell-to-LDAP), as well as from application APIs or web services mapped to LDAP (WS-to-LDAP or API-to-LDAP).

So think about the approach I am describing as a typical building block. The idea is to find a systematic approach to building identity bridges, so that we stop building a bridge to nowhere, as in this diagram of a typical fragmented identity infrastructure:

And end up with a rational federated view of identity acting as a hub, as illustrated by this diagram:

This is what we at Radiant call a “federated identity service based on virtualization,” and I look forward to diving into what this means and how it works in my next post…stay tuned!

The post From SQL to LDAP/Graph: Bridging the Two Worlds appeared first on Radiant Logic, Inc

• What makes hierarchies, along with graphs, so important (think contextual relationships).
• How SQL databases can capture information without redundancy, but still need a materialization layer (think cache) to deliver contextual views at the speeds required for security and context-aware applications (think mobile).
• Why virtualizing both identity and context is key to breathing new life into IdM, while respecting your current identity investments (think Radiant).

These can be regrouped into two topics: The first is identity representation and how we should record it, which is a problem of structure and storage. What is the ideal directory structure and storage for identity and how could we better integrate this life cycle with the larger field of data management? Or, as Ian stresses, how could IdM be a part of IT, instead of apart from it? The second is architecture and real life deployment or how in practice we could and should manage the identity lifecycle in a world of silos. I’d argue that the current fragmented identity infrastructure landscape requires a more rational solution, one that would involve what we at Radiant call a federated identity service, based around a virtualization layer for identity and context.

Today, we’ll be considering the structure and storage side of this equation: how to build the most modern, flexible, and future-oriented way of representing, storing, and sharing essential identity information.

The Rise (and Fall) of the Comma: On SQL, LDAP, and Graphs

As I mentioned in my previous post, although Ian wants to “kill the comma”—and don’t get me wrong, I agree with most of his critiques of the system—I believe there’s more life left in LDAP. To make my case, let’s take a trip back in time, because those who do not know their history are doomed to repeat yesterday’s mistakes—and miss yesterday’s lessons.

Now, we all know that in terms of programming languages, there’s been much evolution since the sixties/seventies, including C, C++, logic programming, functional programming, Java, aspects programming, Erlang, Scala, and many more, with each language offering its own strengths, specializations, and limitations. But we have not seen the same exuberant dynamism in the world of databases. In the earliest days, the hierarchical systems emerged, then some forms of the network database, but from the seventies on, SQL has dominated the landscape. Sure, there were some attempts at object-oriented databases in the late eighties and early nineties, but these were specialized niche products that never cracked the mainstream.

Given this history, we know that around the year 2000 or so, SQL remained the workhorse, the predominant database system in enterprises everywhere. So why did we see the emergence of LDAP, itself a simplification of x500, a kind of “object-oriented” hierarchical database? Why did a bunch of very smart people sitting on a standards committee commissioned by many organizations—including the largest telcos in the world—bypass SQL standards to implement a look-up mechanism based on a hard-coded hierarchy? Why did they create a distributed hierarchical database for email addresses and other information about people (including pictures and preferences—hello, Facebook!), which later evolved into a repository for PKI and source of authentication for internal networks?

Could it be that the hierarchy had some relevance that they weren’t getting from the relational model alone? I believe the much-maligned comma, or rather the DNs (and don’t you love the weird jargon from the X500 world?) still has something to tell us, even now, as identity environments grow increasingly fragmented and demand is going mobile and reaching into the cloud. So let’s look at why, where, and how LDAP is still very relevant for today’s identity infrastructures. But first we need a detour through SQL.

A Thought Experiment: Trees Inside of Tables

Imagine that we could implement a directory model—a complete LDAP schema and directory tree—in a set of SQL tables following best data management practices. Such an implementation would offer several major benefits:

1. The information kept in the system would be extremely flexible. You could modify and generate as many directory trees as you need from your LDAP schema. You could also generate all the graphs you need from these schemas, including graphs containing loops, which are no longer strictly trees.
2. The information in your system would be non-redundant and easy to maintain, following the normalization rules of the relational model. This is a key advantage of the relational system and one of the biggest weaknesses of the hierarchical and graph/network models.
3. Your identity would be managed like all other essential business data. Basing your identity infrastructure on SQL technology also means that your IdM is now “a part” of classic data management, and your DB team is working in their most comfortable environment.

Given these known advantages of SQL, why did our committee from above decide to implement the X500 data model (and hence LDAP) as a specialized hierarchical “pseudo object-oriented“ database? Because of one of the prime advantages of the hierarchical model: fast look-up (or “queries”) and fast attribute value-based search. (And here’s where the link with Hadoop, HDFS, and other big data “NO SQL” implementations will become apparent for the advanced reader.)

The Dark Secret of SQL: It Takes Forever to Navigate Complex Hierarchies and Graphs

You see, the best system to record and update data supporting the so-called ACID properties is also terrible at answering very complex queries. The beauty of the relational model is that it can capture any relationship (whether in graphs or trees) and organize data so it’s captured only once and the updates are consistent, with any change in the real world reflected faithfully in the database. Once recorded in SQL, any graph, hierarchy, or relation between entities and data can be re-generated. As a result, there is no question that the relational system cannot answer. But there is also an important hidden cost: While you always get an answer to your SQL query, receiving that answer can take an incredibly long time. Isn’t it ironic that the world’s leading provider of SQL databases is named “Oracle”? Because, just as in Delphi, when it comes to graphs, hierarchies, or rich contextual data, your questions will always be answered—at some stage, when the fates are ready to tell you.

Pictures Tell the Story: Graph/Trees as a Recursive Relation

Still not convinced? Let’s take a look at how we might represent the “graph” of a person and all his or her friends in the relational world. In the following diagrams, we can see the flow of the representation from the most abstract entity level into a complete instantiation at the network or record level.

At the entity (or model) level, we see a recursive relationship in a relational store, where the recursive “friend of” link loops on the person structure. This very abstract and elegant model can generate both graphs and trees, proving my point that “a relational database can be the mother of all trees and graphs.” One way it does that is representing a tree or a graph by a recursive relationship, where the entity loops on itself.

Implemented at the table level, we see that each row is a person. We can use this table to anchor and encode all the relationships between people. (Of course, we didn’t expand all the duplicate rows for the purpose of illustration.)

At the relational level, when you navigate those rows from picture 2, we see how we can generate an infinite number of trees and graphs from a relational table. This is a tremendous capability—and one that we could and should leverage in the IdM of tomorrow. But, as I mentioned, it comes at quite a cost. While the relational model can represent any tree or graph you want, every time you have to navigate those links, you are joining across nodes—and that’s a very expensive operation. So we can represent any tree by a relationship, but while there’s no problem recording that tree, navigating through the tree will be very slow. That’s just a fact of SQL: you can record and update everything in a really robust system, but queries take forever to navigate. In fact, when in comes to context and graph navigation, “SQL” stands for “Slow Query Language.” (Luckily, there’s a way around the slow-down—stay tuned for my next post.)

And finally, at the network level, we see that in a complex table with lots of people and links, you’ll get to an image similar to this one, which I borrowed from Mark Dixon’s excellent response to Ian’s video. So you can imagine the performance in a complex network such as Facebook.

Everything Old is New Again: What About the Graph Database?

Okay, so we see how SQL can deliver all the trees and graphs we need—but at a snail’s pace. So should we try some thing new? Ian raises the issue of a specialized hierarchical or graph database that would be optimized for faster navigation/search. So let’s say we kill hierarchies and replace them with graphs, for a full network, which is a lot richer. So now we have fast access, but it comes with two huge problems:

1. Trading one specialized storage for another: Implementing a new array of graph databases means we still have a specialized storage that sits apart from the SQL mainstream, which is the source of reference for most of your identity data anyway. Basically, we just replace the LDAP ghetto for a graph ghetto.
2. Reconciling the system across multiple nodes: A graph database does not follow the normalization rules of the relational model, which make it simple to maintain a single version of the truth. While graph databases are very fast to navigate, it doesn’t take advanced math to see that information updates are hell in a network with umpteen nodes like the one we see in picture 4, where duplicate users may play many different roles. Imagine trying to maintain consistency when a person’s phone number changes and that update must be made at all n aliases across the network. The clean model of SQL, where each entity is only recorded once, starts to look pretty good, right?

So do we rely on the old workhouse SQL, a flexible and well-understood “update and record“ engine that’s mainstream for most of your applications? One that contains much of the information we need about identities and their diverse contextual attributes, but which is slow at tying them together in a contextual way? Or do we invest in a new set of specialized databases supporting hierarchies and graphs that are fast at queries (just like LDAP!), but not great at write and update—and devoid of all the information that’s been captured by your mainstream applications?

In my third post in response to the Glazer video, we’ll look at the practice side of this equation: how you can make identity work, given legacy investments and growing demands. I’ll focus on the fact that our existing infrastructure already has the two players we need—SQL and LDAP—and show what other player is needed (think cache-enabled virtualization) to make them work together to deliver all the trees, graphs, and—wait for it—context we could ever need.

The post From SQL to LDAP: Taking the Best of Both appeared first on Radiant Logic, Inc

There’s a great discussion of this new reality in last week’s The Economist, about who’s going to profit from online identity, and how acting as a certified, trusted identity provider is a key function that should not be left to government entities or loosely managed by Facebook or other new social networking “properties.” But today, I want to focus on Ian’s battle cry. In this video, he has come down the mountain with tablets for a new identity, ready to wage war against the “comma.” It’s time to replace the existing identity management—based on LDAP—with REST, JSON, OpenID Connect, OAuth 2.0 and SCIM, he tells us. IdM is all over but the shouting.

Now, don’t get me wrong. I welcome those standards—in fact, our latest version of RadiantOne supports SCIM and a REST interface to our federated identity system, while our CFS service supports OpenID Connect and OAuth 2.0. And I totally buy into Ian’s analysis about the core issues facing our current approach to identity and access management. But I don’t think we need to sacrifice anything.

What Ian Gets Right: The Issues Facing IdM Today

Ian begins with the notion that today’s identity is static, which no longer works when everything is interconnected. We must be able to mirror the relationships, the graphs, the networks that are driving everything around us, he says. And he’s absolutely right! I love how he looks at the current provisioning life cycle, saying that it doesn’t move as quickly as our partners or their customers—or even our own employees—which is really the crux of the challenge. To make identity a competitive advantage instead of an IT cost, it must enable you to collaborate across and outside the corporate walls, and to expand your customer base beyond your current channels. And true, this is a huge challenge, given current constraints. But then Ian jumps to some observations, recommendations, and conclusions that strike me as controversial.

Where He Goes Wrong: Is the Remedy Worse than the Disease?

According to Ian, comma-separated values (CSV) are too simplistic a mechanism for data representation and data transfer in today’s web-driven world—and LDAP is way too inflexible with its hierarchical infrastructure. Instead, we need a graph, a full network of the relationships between nodes/entities. The solution, he says, are new standards, such as OAuth 2.0 and REST. And we need to kill our current IdM systems to get there.

We could not agree more with Ian’s analysis of the state of IdM—but we disagree on the solution. I’ll be looking at why over the rest of this post, then developing these ideas in greater depth over the next few weeks. (I’ll even give a defense of the poor old comma, which gets quite beaten up through the course of Ian’s video.)

Meet the New Standards: Same as the Old Standards?

Like any IdM veteran, I understand how static the current system is, with its jumble of application silos and data stores, where any changes take months of your life, big bites of your budget—and often hairs off your head. You need a system where the definition of identity attributes can evolve depending on context. Do I like the definition of an identity OAuth 2.0 style? Sure, as much as I like LDAP’s “InetOrgperson” in some use cases or even Microsoft AD’s definition of a “User” in other circumstances. There is no ultimate definition of identity—it all depends on needs and requirements. Here at Radiant, we’re pretty agnostic about how identities are described. We like them all, in the same way we’ll like whatever’s part of OAuth 3.0, or any other future standard.

The only certainty is that the definition of identity will evolve as we develop new standards to solve new challenges—and if our definition of identity itself evolves, why not our identity management system? That’s why our federated identity service is based on virtualization, so you can define, remap, and deliver any view of identity you need.

As for REST, we love it and support it in our upcoming release of RadiantOne version 6.1 (look for it in March!). But we also love SOAP when and where it’s not smart, secure, or scalable to use HTTP as a transport protocol. And we even love plain old RPC, when it’s the only mechanism supported in some outmoded, legacy system that’s currently deployed. Like I said, we always try to work with what we have to, to get where we need to be—and that’s a big part of our evolutionary strategy based on virtualization.

Hierarchies, Networks, and Relations: Looking to History to Lead Us Forward

Ian bangs the anti-hierarchical drum in his video, claiming that the hierarchies of LDAP are insufficient and incomplete. A graph is better, he says, because a network of relationships is the most faithful representation of reality. And sure, that’s totally true… But I do think this raises a key issue: as it stands right now, IdM standards (and LDAP as a hierarchical repository) stand apart from the rest of IT, and especially data management. After all, LDAP is not SQL.

However, Ian is short on details here. If he does not want hierarchies, is he thinking about some sort of graph or network database to store those multiple identity relationships? If this is the case, his thought about a graph database—a database that captures all the links of a full network of relationships—should give a big jolt to any relational database practitioner. Did we not settle this debate 40 years ago between SQL and Codasyl and other IMS hierarchical databases? I thought that the first lesson in Database 101 is about how a relation (hence, a relational database system) can represent any graph and, as a consequence, any hierarchy? So we all know that SQL can generate all possible hierarchies and networks. And this is the main reason why the relational database and SQL won the war and now dominates data management as a key mechanism to capture and store application information.

But why then, around the end of the 1990s and beginning of 2000, did we see this resurgence of the hierarchical database model in the X500, which finally yielded LDAP? And why did we in the IT realm—who were fully aware of the limitations of hierarchy versus relational—accept this move, which has led to the current IdM situation? Could there be something useful about hierarchies that we were hoping to capture back then? Couldn’t that value still exist, even in our siloed, static identity environments?

Even in our IdM-isolated world, we should not ignore the growing momentum for attribute and keyword search on all kinds of “Big Data” stored in systems such as Hadoop and other “NoSQL” databases, nor the advantages these technologies might bring. What we need is a good way to unlock all those advantages.

Unless we analyze our past clearly, we are condemned to repeat the same mistakes in the future. So I think it’s essential to step back and look at:

• What makes hierarchies, along with graphs, are so important (think contextual relationships);
• How SQL databases can capture information without redundancy, but still need a materialization layer (think cache) to deliver contextual views at the speeds required for security and context-aware applications (think mobile); and
• Why virtualizing both identity and context is key to breathing new life into IdM, while respecting your current identity investments (think Radiant).

I told you I was about evolution, not revolution. Now, I’ve addressed some of these topics before, but I want to dig a little deeper in coming posts—stay tuned!

And thanks, Ian, for your thought-provoking call to arms!

The post Why Kill Identity Management When You Can Virtualize It Instead? appeared first on Radiant Logic, Inc

Groups are great because they make sense: they represent how employees and resources are organized in the real world, and they’re well-supported by legacy applications while simultaneously enabling emerging best practices for authorization. At a technical level, groups easily distribute users into application-defined roles, making them a natural fit in an ecosystem increasingly populated with role-driven API-based applications. In this world, controlling the groups means controlling access. Without an agile identity infrastructure, though, building and managing groups for your access management regime is a burdensome process that often calls for compromises in either security or agility.

Each time resources are reallocated in the real world, an administrator must update the corresponding group entries with each effected user’s DN (whether adding, updating, or deleting it). That puts time-consuming grunt work onto administrators. Each update to the roles within those groups can mean a team leader needs to put more work on the desk of already-burdened IT professionals. Enterprises often end up facing lose-lose choices between tight group management that sacrifices flexibility, and looser kludges that can leave gaping security holes.

To reduce these group management headaches and make authorization more agile, we’ve built the RadiantOne federated identity service to achieve three key objectives:

• Preserve and migrate existing groups from decommissioned identity stores
  When it’s time to retire older identity sources, you don’t want to scrap all the work you’ve put into setting up your existing groups. That’s why we built our Groups Migration Wizard to help you virtualize your existing groups, transferring them into the federated directory’s namespace so that they can continue to serve your applications without interruption.
• Unify user populations to create flexible groups across identity systems
  When identities are scattered across silos, it becomes all but impossible to create groups with members from across the enterprise. When different divisions are stored in different forests, mobilizing cross-functional teams becomes trickier. That brings serious business consequences like slower, more disjointed deployments and less agile responses to new challenges. With RadiantOne, a global list of users in the federated directory allows for enterprise-wide group creation and management.
• Auto-generate groups and roles in real-time based on attributes
  We can harness virtualization to take the grunt work off of group management your identity managers’ agenda. RadiantOne can dynamically create groups based on the attributes of your users. For example, when a new hire is given the department “Sales” in the HR directory, they will automatically become a member of the Sales group. When her title is bumped from Associate to Director, her group membership will automatically change and her role will be upgraded from User to Superuser.

With groups that represent users from across your enterprise, and group membership based on rich sets of attributes from users’ global profiles, we can leverage your existing infrastructure – and use the cutting-edge security protocols like SAML – to strengthen greatly your access management routines. Auto-generating groups and group migration ensure that adopting federated identity saves your IT workers time now and in the future, while the global view of user identities that RadiantOne provides ensures that you have the IAM flexibility to deploy new groups to meet the challenges of the future quickly and easily.

Interested in learning more about how federated identity can drive a more secure and agile access management system while simultaneously enabling SSO and delivering stellar ROI? Contact us at info@radiantlogic.com.

The post There’s More To Groups Than Meets the Eye appeared first on Radiant Logic, Inc

]]> http://www.radiantlogic.com/2012/11/29/theres-more-to-groups-than-meets-the-eye/feed/ 0