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 →
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:
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 →
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
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.
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.
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:
- Authenticate the user against some “internal authentication sources,” such as AD, LDAP, or databases.
- Map the internal identity representation to the external format the SaaS application requires.
- Encode the authentication token based on the mapping result.
- Send it back to the SaaS application.
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 →
We’ve recently returned from the Gartner Catalyst Conference in San Diego, which was an incredible opportunity to learn from analysts, do a little salesmanship, and share a drink with new friends.
One of the hallmarks of these events is the proclamation that a technology, standard, or practice “is dead.” Of course, such proclamations are generally made tongue-in-cheek, and have even spawned the occasional zombie meme and fears of a standards-hungry serial killer.
Whatever protocols rise or fall, the demise of a particular technology does not mean enterprises (and the Internet more generally) will not need to reliably identify users and assert their permissions. Indeed, as ever more credentials and valuable data are shared among servers across the web, robust authentication and authorization are becoming more important every day.
Bob Blakley famously proclaimed “the death of authentication” at last year’s Ping Cloud Identity event. But he didn’t mean the time had come to give up on confirming users’ identities across computer networks; he was foretelling the demise of simplistic authentication techniques like technologically obsolete Form Based Authentication (the ubiquitous username and password), and the rise of more sophisticated identification schemes. While most systems the world over are still based on FBA, technological advances and the proliferation of myriad access devices have enabled and then necessitated the emergence of smarter user recognition.
This secure recognition is dependent on an attribute-rich and context-based view of users, their online personas, and the devices they carry. Attribute-based authorization is pretty intuitive: by leveraging more of the information a company has about its users in building secure tokens, enterprises can enable more nuanced permissions to their users. To restate a classic example of context-driven IAM, we might authorize financial transactions by the CFO very differently when they come in at 3 PM from his desktop computer at corporate headquarters than if they come in the middle of the night from a mobile device in the Cayman Islands.
As Gartner analyst Ian Glazer stated in his presentation on externalized authorization at Catalyst, the value of a federated virtual directory becomes ever clearer as the need for attribute-rich and context-driven authorization grows. In order to deliver this level of fine-grained security, any identity provider or policy server will require access to as much identity data about users as possible – roles, seniority, geography, device permissions, and so on. Yet, for many enterprises, the identity backend is a tangle of heterogeneous data silos and custom script routines, making it all but impossible to deliver the coherent and comprehensive logical view of users needed to grant access rights.
Simplifying a complex, distributed and heterogeneous patchwork of identity silos so that it is ready for use, whether by on-premise, SaaS, or federation applications is the job of a federated identity service. This system forms a virtual layer that integrates with each of your organization’s underlying data silos, performing a union of user populations and joining their attributes from across the enterprise. That federated hub becomes the authoritative source for identity data for your identity provider and applications.
No matter how you slice security, the need to identify your users—and the context surrounding them—is greater than ever before. Specific technologies come and go, but the changing computing landscape doesn’t mean an end to those fundamental issues; it just means the technologies that deliver it must evolve.
In just four short days, the annual Gartner Catalyst Conference will be kicking off in sunny San Diego, California. It’s a highlight of the Identity Management community’s year, and we certainly won’t be missing it.
A posse of 18 Radianteers will be at this year’s Catalyst to represent the company, host events, catch up with old friends, and make new ones. And, of course, we’ll be eager to hear about the latest and greatest in technologies in our domain, along with what’s happening in the broader technology market, from Gartner’s top analysts.
We’ll also be hosting two events at this year’s conference:
- On Monday, our own Dieter Schuller will be hosting a lunch presentation on how to integrate new applications into your business cheaply and easily – without custom coding – using identity federation.
Get the details and add Dieter’s talk to your agenda.
- We’re letting our hair down Tuesday evening, when we’ll be hosting our Federated Identity Pub. We’ll be serving up a range of free beers on tap, handing out some fun swag, running a pub trivia competition for some neat custom prizes.
Get the details and add the Federated Identity Pub to your agenda.
Of course, we’re always eager to talk shop with our fellow IAM enthusiasts, so if you’re looking at RadiantOne as a solution to your identity woes, then we’d love to use Catalyst as an opportunity to give you a VDS 6 demonstration. Just reach out to us at @RadiantLogic on Twitter, or by phone or email via the Novato office.
See you there!
The Role of Virtual Directory and Synchronization Services in Large-Scale Identity Deployments
Virtual Directory, Cache, and Synchronization Provide a Full-Spectrum Solution
No matter the identity initiative you’re starting—extending SSO for your portal, enabling or improving authorization policies, or deploying a new cloud app—all signs point to the ballooning size and complexity of the average deployment. However, with critical information siloed in diverse identity stores, directories, and databases, what you know about a user is scattered across disparate sources, protocols, and identity representations—with no easy way to put it all together.
Managing identities in this environment requires a solution that is flexible, scalable, and comprehensive. In his March 2012 report, Gartner analyst Kevin Kampman explores the roles of virtual directories, caching, and synchronization in managing large, customer-facing identity deployments. Learn how our RadiantOne federated identity service combines a spectrum of functionalities in one solution, letting you mix and match capabilities to meet the unique requirements of many use cases.
The Role of Virtual Directories High-Volume, High-Diversity Identity Deployments
Gartner analyst Kevin Kampman’s recent report (G00227151) explores the importance of a virtual directory in high-volume identity environments. Kampman writes, “For larger organizations and in customer-facing environments, the quantity and size of datasets are increasing along with performance expectations and data diversity,” and he urges readers to “use virtual directories wherever there is ready access to data and to manage complex relationships.” We couldn’t agree more, and we’ve been talking about the importance of virtual directories in high-volume, high-diversity, and mega-challenging identity environments for years. When it comes to large-scale customer facing initiatives, you need an identity solution that can scale, that can deal with heterogeneity, and that won’t fade with the next power outage. That’s why an advanced virtual directory with sync and persistent cache—like our RadiantOne—is the best choice for the challenging environment of the modern infrastructure.
Identity Integration: A Drive in the Slow Lane?
While directories scale well, not all directories scale the same way, and what if you start throwing in non-directory sources? When you’re storing identities for externally-facing initiatives, you would traditionally store them in a SQL database, which may be slowest of all. So how can you pick up the pace when you’re integrating slower sources with your LDAP directories—and can your identity management system navigate this kind of diversity? In his report, Kampman writes, “A virtual directory plus a cache is optimal for many high-performance, high-volume situations. A synchronization service provides comparable performance. Both are limited by the responsiveness of the source repositories and underlying network infrastructure.”
With identity virtualization, speed of the underlying source repository isn’t even an issue. Virtualization allows you to create one global LDAP list of identities from across all data stores that the client application can query. And, because it’s stored in a power-boosting persistent cache, one lookup in the global list immediately returns the results, while back-ends are shielded from excessive queries, and the even the slowest database can be reached at the speed of a directory.
Add Extra Horsepower with for Scalability
Enriching identity profiles is where the extra performance becomes especially handy, like when you need to create identity profiles based on multiple sources—which means joining identity attributes. Kampman writes, “The use of a cache with a virtual directory may be required as performance expectations grow. An example of this might include aggregating profile information across dissimilar repositories or where the performance or availability of the source repositories isn’t sufficient.” Large-scale WAM deployments that must integrate large, heterogeneous populations usually require a performance-enhancing cache to help power those attribute joins on the fly. Effective joins means you get the complete view of each identity, which is essential not only for security processes, but also for most information about each customer.
For a sizable, attribute-rich system with an extensive set of profiles, then high availability, scalability, and stability are essential. With the ability to transform, rationalize, and stabilize the choppiest of identity management waters, RadiantOne’s federated identity service is purpose-built to handle the kind of environments Kampman describes.
Bridging On-Premise Identities with Web and Cloud Applications
Mark Diodati, Research VP
Elle Griffin, Marketing Director
Radiant Logic, Inc
Gone are the days when your identity and applications were securely stored behind the firewall. Going forward, every application you deploy will be web or cloud-based—and the people accessing them could be inside their cubicles, or across the world. You need a federated identity hub to shield such applications from the complexity of your identity sources—but where should that hub live?
Find out at our next webinar on April 12, when featured speaker Mark Diodati, Research VP at Gartner, will explore the use of identity bridges to address business demands for SaaS-based applications. Elle Griffin of Radiant Logic will discuss why deploying a federated identity service is an important step for rationalizing and managing a chaotic identity infrastructure behind the firewall, while also enabling a secure connection to cloud and federated applications.
Date: April 12, 2012
Time: 8 AM PST, 11 AM EST
>> Register here!
Bridging On-Premise Identities for Web and Cloud Applications
Gone are the days when your identity and applications were securely stored behind the firewall. Going forward, every application you deploy will be web or cloud-based—and the people accessing them could be inside their cubicles, or across the world. You need a federated identity hub to secure such applications—but where should that hub live? Find out at our next webinar on April 12, when Gartner’s Mark Diodati will explore the use of identity bridges to address business demands for SaaS-based applications, and provide use cases drawn from Gartner client experiences. Radiant Logic’s Elle Griffin will discuss why deploying a federated identity service is an important step for rationalizing and managing a chaotic identity infrastructure behind the firewall, while also enabling a secure connection to cloud and federated applications.
>> Join us
- 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