Integrating the New Identity While Evolving Your Existing Identity

Right at the beginning of the year, I introduced you to Radiant’s Great Migration map, our vision for the identity landscape of today and tomorrow. I’d like to follow up that discussion with a series of posts about the importance of integrating IDaaS cloud services and directories with your existing IAM infrastructure and LDAP applications. After all, unless your company is digital native or you’re starting from scratch with a greenfield deployment, you probably have an identity infrastructure that looks a little something like the lower two-thirds of the map—even as you reach for the cloud.

Your Guide to a Federated Identity Service

For many major enterprises, the existing identity system is more ocean and less cloud…

In any case, IDaaS or “identity-as-a-service” is a very promising direction for a field that’s been stuck in the datacenter for a very long time. The value proposition is especially exciting for larger enterprises, like most of our customers. For one, federation makes it easier to offer SSO and a more user-friendly portal, which is great news whether you’re extending access to new employees and partners after a merger or enabling customers to manage accounts across a world of different services, each one brought online at a different time. A directory on the cloud also abstracts location dependency for applications, which is key for mobility, as well as for multi-national companies with sites across the globe.

Can All Your Apps Speak Federation Standards or IDaaS APIs?

Yet at the level of access/authentication and directory information, these benefits are available only to applications that can leverage federation standards such as SAML and OpenID Connect and/or specific APIs supported by individual IDaaS vendors. Unfortunately, most enterprise LDAP-based applications and traditional WAM portals can’t do either, which means they cannot authenticate through SAML or a cloud directory because that would require calling an API that is not LDAP. While a directory on the cloud is great for new initiatives and applications, to all your WAM and LDAP apps, that cloud directory just looks like another silo. And that means that all these benefits are confined to the new part of the stack—even though they’d be especially helpful for adding agility to the existing stack. So how does a large company with extensive investments in yesterday’s tech take full advantage of tomorrow’s identity and access solutions? (Hint: it involves virtualization and integration with RadiantOne FID…)

Stay tuned for my next post, where we’ll dive a little deeper into the infrastructure—and soar a little higher into the cloud—as we look at how to empower IDaaS with a federated identity service.

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

How a Federated ID Hub Helps You Secure Your Data and Better Serve Your Customers

Welcome back to my series on bringing identity back to IAM. Today we’re going to take a brief look at what we’ve covered so far, then surf the future of our industry, as we move beyond access to the world of relationships, where “identity management” will help us not only secure but also know our users better—and meet their needs with context-driven services.

We began by looking at how the wave of cloud services adoption is leading to a push for federation—using SAML or OpenID Connect as the technology for delivering cloud SSO. But as I stressed in this post, for most medium-to large-enterprises, deploying SAML will require more than just federating access. By federating and delegating the authentication from the cloud provider to the enterprise, your organization must act as an Identity provider (IdP)—and that’s a formidable challenge for many companies dealing with a diverse array of distributed identity stores, from AD and legacy LDAP to SQL and web services.

It’s becoming clear that you must federate your identity layer, as well. Handling all these cloud service authentication requests in a heterogeneous and distributed environment means you’ll have to invest some effort into aggregating identities and rationalizing your identity infrastructure. Now you could always create some point solution for a narrow set of sources, building what our old friend Mark Diodati called an “identity bridge.” But how many how of these ad hoc bridges can you build without a systematic approach to federating your identity? Do you really want to add yet another brittle layer to an already fragmented identity infrastructure, simply for the sake of expediency? Or do you want to seriously rationalize your infrastructure instead, making it more fluid and less fragile? If so, think hub instead of bridge.

Beyond the Identity Bridge: A Federated Identity Hub for SSO and Authorization

This identity hub gives you a federated identity system where identity is normalized—and your existing infrastructure is respected. Such a system offers the efficiency of a “logical center” without the drawbacks of inflexible modeling and centralization that we saw with, say, the metadirectory. In my last post, we looked at how the normalization process requires require some form of identity correlation that can link global IDs to local IDs, tying everything together without having to modify existing identifiers in each source. Such a hub is key for SSO, authorization, and attribute provisioning. But that’s not all the hub gives you—it’s also way to get and stay ahead of the curve, evolving your identity to meet new challenges and opportunities.

The Future’s Built In: The Hub as Application Integration Point and Much More

Another huge advantage of federating your identity? Now that you can tie back the global ID to all those local representations, the hub can act as a key integration point for all your applications. Knowing who’s who across different applications allows you to bring together all the specific aspects of a person that have been collected by those applications. So while it begins as a tool for authentication, the hub can also aggregate attributes about a given person or entity from across applications. So yes, the first win beyond authentication is also in the security space: those rich attributes are key for fine-grained authorization. But security is not our only goal. I would contend that this federated identity system is also your master identity table—yes, read CDI and MDM—which is essential for application integration. And if you follow this track to its logical conclusion, you will move toward the promised land of context-aware applications and semantic representations. I’ve covered this topic extensively, so rather than repeat myself, I will point you to this series of posts I did last spring—think of it as Michel’s Little Red Book on Context… 😉

So the way we see it here at Radiant, the emergence of the hub puts you on the path toward better data management and down the road to the shining Eldorado of semantic integration, where your structured and unstructured data comes together to serve you better. But you don’t have to wait for that great day to realize a return—your investment starts to pay off right away as you secure your devices and cloud services.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

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.

Directory Synchronization - Windows Azure AD

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.

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

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 (and if you haven’t, you can catch up here: one, two, three, four, and five). 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:

Single Access Point for All Applications

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.

read more →

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

I’ve been blogging in response to Ian Glazer’s video about killing IAM in order to save it (I’m in favor of saving, even if we don’t agree on the killing part). Get caught up on my earlier posts here, here, here, and here.

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:
Federated Identity

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.

SHARE
FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

I ran into Ian Glazer at last week’s Gartner IAM conference. It was an excellent event, and the weather was so cold in London (or perhaps that’s just my inner Californian talking) that the crowd was even more attentive than usual. Although he had places to go and people to see, Ian gave me some quick but very valuable feedback about this blog series in response to his video about killing IAM to save it. His big takeaway was that “it’s not about the storage.”

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:
Federation IdP

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.

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