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…
- First we introduced the topic of Context as the Next Frontier of Your Digital Identity.
- Then we went From Groups to Roles to Context, looking at the Emergence of Attributes in Authorization.
- Then we explored Attributes, Predicates, and Sentences as the Building Blocks of Context.
- And finally, we achieved Valhalla: Man and Machine, Speaking the Same Language.
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 →
Welcome back to part three in my latest blog series about bringing identity back to IAM. And when I say bringing identity back, I do not mean just to the periphery—at Radiant, we believe identity should be right at the center of your organization. That’s right, it’s time for the hub discussion. Now, we’ve had this talk a time or two (or ten), looking at the idea that the complexity in today’s infrastructures demands a sort of logical center, a place where identities can be federated, rationalized, and transformed according to the unique requirements of each service provider or application.
If you remember my last post, we looked at metadirectories as our last attempt to centralize identities—and we know how well that went. (It was the same story for the older ”enterprise directory,” as well.) But what if we could keep the idea of a central identity, while achieving this “logical” centralization in a more flexible way—one that respects the role of the silos as masters of their domain? A way that evokes the “meta” part of “metadirectory,” while providing a more agile “directory” part?
And that’s where virtualization comes in.
The Radiant Mantra: Manage Globally, Act Locally
Virtualization is the logical part of “logical center” I mentioned above, and it’s how we can create a smart hub that’s based on the cooperation of the periphery. This idea evokes the exact sense of the word “federation”—federate the work, giving each actor its own role to play.
At the center of such a system is a virtualization engine, busy pulling information from your heterogeneous backends and making that data ready to meet the needs of your applications or service providers, whether they’re in-house, on the web, or in the cloud.
The first step in this “active summarization” is to create a reference table of all identifiers, the “golden list” of all your identities out of many disparate data representations. Once the list is complete, your federated identity hub can produce the new—and many times different—views of identity that your applications need. That’s the “manage globally” part of the mantra.
Now when a request comes from any service provider—to check a user’s credentials at login, for instance—that task can also be delegated back to the correct authoritative local store, thanks to this global reference table. After all, we may complain about identity silos, but they’re not just silos, they’re application specialists, designed to do exactly what they do very well. So their “views” are essential to user authentication and need to be preserved—just think about the role of Active Directory in this food chain. This is the “act locally” part of the equation, and taken together, these actions give you an identity infrastructure that’s truly designed for federation.
But let’s take a closer look at how we got to this idea of “manage globally, act locally.”
The Rosetta Stone of ID: Global Integration Backed by Local Ownership
I’ve made a bold claim: that we need to respect both the global and local views, that it’s not enough to merely pull things into the center like the metadirectory, or to simply delegate and proxy back to the different stores like the most commonly sold form of the “classical” virtual directory. We really need a way to do both. We need to synthesize all user data into a reconciled global list of users but built on top of what already exists, and will continue to exist, because it covers some very specific aspects of identity that we need.
If we can agree on this, then the requirement for a dictionary of identifiers—a “Rosetta Stone” that maps a global identity into its specific application representation and makes it easy to look things up—becomes clear. Of course, life would be easier if we were all operating according to a set of predefined “generic” global identifiers, defined at the start of all processes. But the reality is that we’re dealing with different applications adopted at different times from different vendors—each speaking a different language and checking credentials in a different way. They don’t even agree on the basic building block of identity, the identifier!
But don’t feel bad, we’re all in the same boat—even Pyongyang probably has tons of diversity and duplication in its monolithic identity system, with no common global identifiers. So if you cannot impose a common identifier upon each application, then you have to establish this correlation after the fact. That’s what we call a “federated identity system.” And yes, we believe that the accelerated deployment of federation will require such a change at the level of the identity structure. If any sizeable enterprise wants to manage their users and access the cloud, then the structure of an IdP will require a federated identity system (whether it’s hosted in-house or on the cloud only matters in terms of your particular deployment). I believe that such a federated identity system, acting as a consolidated view of your identity, is the exact technical characterization of the function than eluded the so-called “meta”directory.
The Hook-Up on Look-Ups: Remapping Identifiers Inside the Hub
By mapping each identifier, each “global” identity in the Federated ID system has its corresponding translation in a specific silo. So when you look up that individual, you’re able to use the correct identifier of a user for each given application. So my global identifier might be “Michel,” but I am also known as:
Michel = Mike in A = Michael in B = MPrompt in C
That’s the first function of the hub, establishing that there’s an individual called “Michel” who’s common across systems, but also known by other names.
A Global List from Multiple Systems
This correlation table is the start of being able to link all the information about a given individual—and it’s no mean feat to pull all this together. Even assuming you have no data quality issues in your system (and if so, I’d like to hire your data entry team!), what happens when you have name collision?
read more →
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!
- 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.
- Then, because this operation has to happen for each identity source and target, medium-to-large organizations acting as IdPs—or hosting their IdP functions as a service—are rediscovering a practical requirement: you need a complete identity hub to simplify the identity orchestration required by the different cloud services (including authentication and authorization, along with provisioning).
Beyond connectors and syncing capabilities, Nick and I were struck by the idea that this requirement for a common hub, this staging engine for identities, whether hosted on premise or in the cloud, reminded us of something…what could it be? You guessed it—it’s the second coming of the meta-directory, back from the (near) dead, or at least a similarly centralized structure that drives your cloud provisioning and access efforts. Now wait, before my wife, my mom, and my dog stops reading this blog, let me assure you: I have not been visited by the ghost of Elvis, even though Halloween was just last week. Before you call me crazy, take a look at this cloud apps slide from the gurus in Redmond, depicting a required architecture for the deployment of Microsoft Office 365.
See, it’s not just the nuts in Novato who see the need…
Federation Provisioning: Seed the Infrastructure, Keep it in Sync, and Remap on the Fly
Now, there’s a lot here to discuss, but let’s analyze each paradox in its turn, so these posts don’t become War and Peace (or its even longer sequel). For today’s post, we’ll take a look at the idea that federation doesn’t eliminate the need for identity management on the part of the service provider or relying party.
Basically, the IdP converts an internal identity representation into a token, then the SP converts that token and checks it against the internal identity representation. What we’re seeing in the authentication operation is the creation of a token through a remapping/conversion operation on the sender’s side and the finalizing of the authentication through a remapping /conversion operation on the receiver’s end. So a whole lot of remapping and conversion here, and even at the level of authentication, we start to see that the system only works if enough parts of the infrastructure have been seeded with some form of identity list, along with a way to look up identities and map them to the proper format.
read more →
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:
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 n users in n different ways, the protocols “federate” their request for authentication, delegating it to an agreed-upon “identity provider.”
So 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
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 →
Meet Our Latest Edition, VDS v6.2 (and Get Ready for the Big 7.0 Release!)
Your environment is continually changing and your Identity infrastructure needs to stay up to date. Don’t worry, we’ve got you covered and true to our goal of continuous product improvement, we released RadiantOne VDS v6.2 at the end of September, 2013.
Here are the main environment and configuration changes you should be aware of:
- RadiantOne now includes and has been certified with Java SE 7.
- RadiantOne now includes and has been certified with, the latest version of Glassfish application server: v3.
And we added some new functionalities to the security stack:
- VDS v6.2 now supports a new SAML profile for attribute queries: the BAE profile as it is defined in the FICAM (Federal Identity, Credential, and Access Management) standard. As an attribute server, VDS will respond to such queries with SAML assertions based on the BAE profile.
- NTLM v2: Although VDS has always supported NTLM v1 for client authentication, v6.2 introduces support for NTLM v2. NTLM v2 is a cryptographically-strengthened replacement for NTLMv1.
But we did not stop there, VDS 7.0 is coming and we will release it before the end of the year! Although we’re still fine-tuning the last details, we are able to deliver HDAP in beta version to a selected number of customers (Learn more about HDAP here)!
As you can see, we have been busy here at Radiant! Please let us know if you have questions or concerns and we encourage comments below.
- 02 Dec 2013Context is Coming: The Move from IdM to Identity Relationship Management and the Internet of Things
- 22 Nov 2013Identity at the Center: Why You Need a Federated Identity Hub
- 08 Nov 2013The Hidden Requirement for Federation: Syncing and Provisioning to the Cloud
- 23 Oct 2013From Virtual Directory to Federated Identity: Bringing Identity Back to The Center of IAM