What’s in a Name? Everything…

Some years ago, we put together a fun little map that shows some of the dangers our customers face in the treacherous waters of Identity Management. But now, after meeting with our customer advisory board during the recent Gartner IAM event in Las Vegas, we’ve had to expand the map to include the cloudy skies of “Azuria” and “Amazonia.”

Your Guide to a Federated Identity Service

Many of our largest customers—including Fortune 100 companies—are looking to shutter their data centers and move all operations, including identity, to the cloud. Luckily, Radiant will be right by their side, helping our customers streamline operations and secure their application portfolios. One of the main reasons we can be so helpful is that we’ve evolved the virtual directory technology we pioneered way back in 2000, moving from a proxy-driven tool for aggregating across disparate data stores—which was a huge innovation at the time and still useful in many situations—to a federated identity service based on advanced virtualization, or what we call “FID.”

(Virtualize, Transform, Store) + Sync = FID

This federated identity service gives you complete identity integration from end to end. And it’s more than just an acronym change. Moving from VDS to FID signifies the evolution of identity integration from a lightweight tactical solution to a strategic identity service. The challenges of identity management have only gotten more complex over the years, with the rise of digitization, mobile services, and the cloud. Given the new constraints and challenges facing today’s identity management, we’ve evolved and modified this architecture over the years—in a dramatic way.

The result is an advanced identity service combining real-time synchronization, identity correlation, and directory storage, and leveraging our patented identity virtualization technology. The main challenge of modern identity systems is to address two conflicting trends:

  • The multiplicity, heterogeneity (AD, LDAP, SQL, APIs), and distribution of authoritative identity sources.
  • The need to present a common global view of identity to applications, no matter where they are—on premises, on the web, or in the cloud.

As an entirely new “identity service” architecture, RadiantOne combines identity information from local sources, then normalizes and generalizes it into a global service. This is what enables companies to authenticate and authorize users across a diverse array of applications, no matter where they’re hosted—and it’s what will enable our customers to take the next major step, shipping their identity into the cloud.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

That’s right—we’re bringing identity back… 😉

There is no doubt that IT in general and IAM in particular are facing a sea of change. The disruption of the cloud, along with the emergence and explosion of new devices and form factors, is creating the kind of turbulent environment where major opportunities can be exploited—and major blunders can sink the best organizations. So who will get swept away and who will discover new lands? I’d like to take my next few posts to look at what’s happening in IAM these days and why we believe that federating the identity layer—not just the access layer—is essential for empowering today’s fragmented IAM infrastructures and driving business in a cloud and mobile world. And for a look at the choppy waters we’re all sailing in these days, don’t miss our map of Ye Olde Identity Infrastructure—just click to enlarge:

Ye Olde Identity Infrastructure

As the Chinese curse says, we are living through interesting times. When we look at current trends in IAM, the strongest wave is coming from the federation corner. Now, we can discuss at length which protocols will win the Federation Cup—will it be SAML 2.0 or Open-ID connect/Oauth 2.0? My guess is both—and, as usual, the answer will depend on the problem at hand. Are you focused on access for employees, contractors, and other “internal” users, or is your course set for customer and prospects? But there is common consensus that organizations will have to access services—likely in the cloud—as well as expose their own services to other organizations.

The Rise of Federation: Putting New Demands on Your IAM Infrastructure

Beyond the specifics details of protocols, the blueprint of federation is spreading across the whole IT landscape, and will become dominant over the next 3 to 5 years. The federation pattern divides the task of authenticating/authorizing between two main roles for the participating organization: a Service Provider (SP) (with the Relying Party (RP) in a supporting role) and an identity Provider or “IdP.” This division of work was originally designed for a traditional federation, a group or consortium of companies pooling together services/resources while delegating onboarding, registration, and single sign-on to selected members.

But thanks to the existence of the standards I mentioned above, this same framework is becoming the de-facto access method for SaaS or “cloud” applications. Acting as a Service Provider, the SaaS vendor can dedicate its best minds to delivering and supporting a high value, specialized service to its tenants. And when those tenants are themselves medium-to large-enterprises with thousands of employees or members, the only practical approach is delegating user management—in particular the authentication function—back to those same organizations. In short, turning them into IdPs.

Federation Only Routes Access to an IdP…

Let’s see what this process implies. From a SAAS application, or any external application that is based on the federation pattern, your organization is in charge of managing and authenticating your users. This is a smart way to do things: instead of having n applications trying to manage  users in n different ways, the protocols “federate” their request for authentication, delegating it to an agreed-upon “identity provider.”

Identity Provider

Identity ProviderSo if we analyze a protocol like SAML 2.0, we see that it gives all the details about how the authentication request and response will be made, and we also see that in the agreement between the service provider and the identity provider, the content of the token—the set of attributes that establishes the identity of a given user—can vary widely. No problem there, because different applications or services can require different level of identity insurance and so the protocols support that.

But at a minimum, this means that each of these external applications will require a set of specific attributes to be returned by the identity provider as a proof of authentication, along with additional attributes for authorization, personalization, and other initiatives. It’s like having a single user who needs to present a new boarding pass for every flight on their way to a destination. So as an IdP, you must identify and authenticate a user—we’ll take a closer look at that process in my next blogpost—and then remap the identity information you manage, translating it into the different specific token formats required by each application. This diagram shows how the process works:

The Challenge of IdP Implementation: Managing Different Security Domains

The Challenge of IdP Implementation: Managing Different Security Domains

But here we are just looking at the external aspect, the contract to be fulfilled by the service provider and the identity provider. According to this contract, the authentication request will be handed off to the IdP, which identifies the user, and then returns the proof of this authentication with the required attributes in the format of SAML2. Repeat for each application that talks to your IdP and you have the complete picture.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Are you ready for more Microsoft? A couple weeks ago, I posted an overview of the recent Windows Azure AD (WAAD) and Access Panel announcement that heralded Microsoft’s entry into the IDaaS market. In it, I looked at Sean Deuby’s excellent article on the WAAD news, as well as his analysis of Microsoft’s hybrid identity paradigm, which envisions a world where on-premises identity happily co-exists with—and empowers—identity in the cloud.

Now I want to take a deeper dive into how to make all this work, and why we here at Radiant believe you must normalize, aggregate, and remap your identity before shipping it off to the cloud. Today, we’ll look at making WAAD work in an environment made up of only Microsoft identity sources—your basic AD domains and forests. Of course, since even the most Microsoft-centric Fortune 1000 companies tend to have much more complicated environments (SQL and LDAP, oh my!), my next post will focus on enabling hybrid identity within the heterogeneous infrastructure.

But for today, let’s examine the deployment of a hybrid environment where WAAD functions as your service-based identity for the cloud, but your identity continues to be managed and originated on-premises at your enterprise.

WAAD is Your IDaaS, but AD is Still Your Co-Pilot

In this scenario, the most likely use case involves these steps:

  1. You move your local AD user accounts—or more likely, a sculpted subset of that user data—to populate accounts on WAAD.
  2. You point WAAD to an instance of ADFS that’s installed on-premises, so it can leverage your enterprise security means.

With these two steps, you’re using WAAD to identify a user by confirming that he/she exists in the WAAD global list, and then delegating ADFS to check the user’s credentials using your AD integrated authentication (Kerberos) and SAML to verify the user. We see this somewhat convoluted process play out here:

How Microsoft Would Authenticate Users for WAAD in a Federated Accounts Scenario

How Microsoft Would Authenticate Users for WAAD in a Federated Accounts Scenario

In the diagram above, we see that the operation can be divided into two main parts:

  1. The synchronization of identity from the local AD to WAAD, after some level of remapping.
  2. The delegation of authentication—credential checking—via ADFS back to your enterprise AD infrastructure using SAML and Kerberos.

For the first operation, DirSync works with WAAD and your on-premises forest and domains to synchronize your identity. On the surface, this seems pretty straightforward, beyond a little remapping to make the AD version of identity line up with the more specific federated version you’ve created for WAAD. But when you look at the real picture for most medium-to-large sizeable organizations, it’s not so simple.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

I’ve been blogging on Gartner analyst Ian Glazer’s recent video on whether we need to kill IdM in order to save it. It seems appropriate to begin these with words of Martin Kuppinger, in response to the Glazer video and my first post on this topic:

“…. 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.

sql-ldap-graph table

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Last week, we discussed Ian Glazer’s video on killing identity in order to save it. And this week I want to follow up on some of the questions I raised at the end of my post:

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

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Michel PromptWe’ve been banging the federated identity service drum for a while now. But no less than Salesforce CEO Marc Benioff has taken up the beat: Identity federation is the next big thing for one of the biggest players in the SaaS category. As Benioff announced, the new Salesforce identity service will “deliver a single, social, trusted identity service across all enterprise apps.”

And we say—welcome to the party! Ours is not the only voice echoing this cry. As our good friends at Ping Identity said: “If you didn’t get identity before, you better get it now.” Gartner weighed in, as well: “This changes the balance of the identity ecosystem,” analyst Ian Glazer said. “…the market may never be the same.”

Federated Identity System: A Central Clearinghouse, Not an Authoritative Store

I was especially pleased by the way Benioff defined the Salesforce identity service as a federated identity management system: “We don’t just use other directories,” he said. “We build a new, central identity management directory. The identity service imports identities from any LDAP directory, Microsoft Active Directory, or any other standards-based directory service and then serves as a central clearinghouse for a broad set of applications.”

And I will confess to feeling a little vindicated—and less alone in the federated identity wilderness (which should not be confused with federated security means, a far more populated place that’s all about SAML, OAUTH, and OpenID Connect. Don’t miss Dieter Schuller’s excellent presentation explaining the difference.) After all, since the full availability of our VDS 6.0 this summer, we’ve been talking about the idea that the central identity store—this directory which acts as a clearinghouse for all other authoritative identity sources—can be best achieved through a virtualization layer with advanced functionality such as identity union and join.

Now, some of you seasoned veterans out there could read “central identity management directory” and think it means that Salesforce is trying to build some super-duper centralized enterprise directory on the cloud, replicating the painful failure of a couple decades back. But if you read carefully, you’ll see that Benioff’s talking about importing identities (and their definitions)—aka pulling—from peripheral sources into a central clearinghouse, not imposing—or pushing—identities into a single authoritative store. And this is right in line with our mantra of the past few years

Manage Globally and Act Locally: Not Just a Slogan, a Way of Life

Of course, when we look back, the task of creating such a logical centralized system, of aggregating, correlating, and integrating identity from a myriad of authoritative and sometimes contradictory sources, has been littered with many failed attempts. But we know it’s totally achievable—and our customers are a testament to our approach. So let’s take a look at the parameters of the problem—which is very tricky—and see why we believe that virtualization, along with a set of key functions, is needed to achieve this goal.

With all the new applications, devices, identity sources, and user populations companies are managing these days, federation is now a “best practice,” if not a must, and every sizeable company must deliver some form of Identity Provider. But delivering a “logically central” system of identity, one rationalized abstraction point where all your identity exists, is much easier said than done. While federation standards are very established from the security layer side, you also have a thicket of heterogeneous, distributed identity stores in your infrastructure. You’ve heard me talk about this identity mess before, but while these sources may be siloed, they’re also authoritative for many specific aspects of an identity, such as HR, marketing, or project management; each has a job to do.

You can’t just ignore those sources—and trying to recreate all this logic at the center is a nightmare, as our experience with the enterprise directory taught us. In a world where everything is everywhere—identities, apps, devices—you can’t just reinvent identity data into a hard-coded central system. To build your IdP, you must be able to publish, pull, and transform data, aggregating where needed, and integrating where it makes sense, while letting each local system capture the information it needs to do its job. You need a way to harness your distributed local identity sources, elevating the identity and attributes they contain so you can “manage globally,” while letting each specialized silo stay authoritative for what it does best, which is “act locally.”

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Explore our New Federated Identity Service at RSA

I’m looking forward to RSA this year, where we’ll announce a major breakthrough in the way companies manage their identity in this increasingly web and cloud-centric world. I’m also proud to see that RSA is integrating our solution into its excellent IdM stack.

I’ll tell you all about it below, but first, I’d like to address a topic that’s been burning up the blogosphere lately.

The Virtual Directory is Dead. Long Live the Virtual Directory!

We all know that it’s not enough to innovate; the success of a new technology is also measured by its degree of integration within the existing ecosystem. I’ve been reflecting on that challenge lately, after reading this piece on Ping Federate’s new authentication chaining capability, which suggests the virtual directory is no longer necessary. Hmm, we know our good friends at Ping Identity are not that radical—just check out the slides from their latest webinar—but I guess you know the old joke: Groucho was a Marxist and Lenin was a Beatle. I will leave it to Nishant Kaushik’s excellent response to explain why authentication chaining is only a very small part of the answer.

Mostly, I’m struck by the fact that the virtual directory—technology my friend Claude and I invented back in the dark ages of last decade—is now such an accepted part of today’s identity infrastructure that people feel free to proclaim its demise. After years of trying to explain what a virtual directory was, that feels like a victory! 🙂

Okay, now let me share some news I’m really excited about.

From Virtual Directory to a Federated Identity Service Powered by Virtualization

Over the years, we’ve advanced virtual directory technology from a proxy-driven routing and remapping engine to a model-driven virtualization solution, which enables you to design the exact identity views required by your applications. Now we’ve taken it a step further, delivering a federated identity service based on virtualization that’s key to the deployment of any secure web application or identity provider (IdP) in a federation—all without disrupting your existing systems. This service hides the heterogeneity of your existing identity sources, and exposes a logical, coherent, secure, and application-friendly view of your users to both internal and external applications. And it drives any business initiative where a global view of identity is essential, including web access management, portal, and cloud integration.

Sounds like a great solution, right? But first, let’s take a look at the problem we’re solving.

Applications, Security Protocols, and Identity Sources—Oh, My!

In any sizeable modern organization, there are many links tying applications, via disparate security and access protocols, to all the different identity sources. I call this the “Star Wars” effect:

Identity Sources

For such companies, many internal, external, web, and cloud-based applications (A) must talk to many identity sources (I) using different security protocols (S), with every factor representing some number (N) of links—and every link costing lots of money ($$$) to develop, manage, and maintain.

When you do the math—A x I x S = N links (x $$$)—it’s basically a shoot-out at the Not-OK Corral, where you’re left with a brittle network of links, protocols, and identity representations that require a whole IT team to maintain. And whether your company is revamping its portal, adding a critical cloud-based application, or acquiring a partner, any changes put incredible (and incredibly expensive!) demands on a critical infrastructure.

An Identity Hub to Reduce Complexity and Rationalize your Infrastructure

Fortunately, there is a well-established pattern for solving the problem of too many links. By creating an intermediate layer—a hub—you can reduce the complexity of M x N interactions to more manageable and linear M + N connections. After all, this is why the airlines fly you through Denver or Charlotte or Chicago, instead of offering the chaos of thousands of direct flights between destinations.

Our federated identity service acts as a virtual identity hub, anchoring your identity infrastructure and enabling you to interconnect all the identities across the enterprise, no matter where or how they’re stored, for smarter security, better authentication, and more finely-grained authorization.

Federated Identity Service
Now, this idea of an identity hub is not new—in fact, identity vendors have been trying to develop (or reinvent) some form of an identity hub for years, from the over-centralization of the ”enterprise directory,” to the efficient but inflexible meta-directory, and more recently the flexible but limited “classical” virtual directory based on simple mapping, routing, and proxy. After many years of experience with customer integrations, we know you need to combine the strengths of all these different approaches, and add a little special sauce on top, so let’s take a quick look at the technologies and processes underlying our solution.


read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

By Michel Prompt, Founder & CEO

Last week’s webinar on “Data Clouds”, featuring Lyn Robison, Research Director for Data Management Strategies at Burton, is already generating a buzz in the blogosphere. In his recent blog post responding to the webinar, Jnan Dash expertly captured the data cloud concept. Formerly a senior executive at IBM and Oracle, Jnan’s insight into the architecture and potential of data clouds is impressive.

You’ll Need More than SQL in the Cloud

As Jnan mentioned, our background at Radiant is in directories and LDAP/X500. And in a world dominated by SQL and relational databases, one might wonder what a hierarchical data model could bring to the equation. Didn’t we all learn back in Database 101 that relational is the mother of all hierarchies and networks? Of course, I am being a bit disingenuous here, because unless you live on another IT planet, the buzz around an alternative model to straight-jacket SQL is growing stronger by the day. Just look into NoSQL or check out the excellent post in the identity space by my friend Dave Kearns.


read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail