Social Security: The Next Wave in Identity Management
Articles and Tips: article
30 Sep 2004
Not to sound overly philosophical, but technology is like the ocean. It comes in waves. Sure, vendors can paint a beautiful and inspiring picture of the sunrise on the horizon, but actually achieving that vision generally happens one wave at a time; and identity management is no exception.
In the mid- to late-90s, before identity management became a mainstream IT topic, the conversation revolved mostly around directories and the concept of storing identity information for use throughout the network. The pre-directory days were "machine centric," in that a network login was attached to a specific machine, and access rights varied from server to server. With the advent of directories from vendors like Banyan, Netscape and Novell, companies got their first taste of a "user-centric" world, where network and application access were based on a user's identity.
The next wave in identity management targeted Web access control, and gave rise to products like Netegrity Siteminder and Novell iChain. These products tapped the identity information stored in directories to control access and personalize content for Web sites and Web applications. But of course the proliferation of Web access management solutions and a host of other identity-based applications left many companies with dozens of non-integrated user identity stores that had to be managed and updated manually and individually. That administrative nightmare was the catalyst behind the third wave of identity management and the rapid adoption of meta-directory and provisioning products. Niche vendors such as Business Layers and Access360, and well-established players like Sun and Novell, gave companies a means to integrate different identity stores and automate the creation of user accounts across applications...and that's the point where many companies are today.
So what's the next wave in identity management? In a word: federation. Not the "explore strange new worlds" kind of federation, but rather securely sharing identity information outside the firewall with business partners. And just as it has been in many other facets of identity management, Novell is on the leading edge in developing products that make it possible to federate identity information. In November, Novell will begin beta testing a technology code-named Odyssey, which will make it very easy to federate identity information between business partners, as well as internal systems, without compromising a user's privacy.
Of course, the next question is, Why? While the concept of federation may sound intriguing, is it really something that can make life easier for a network administrator--or just more vendor hype?
Perhaps the best way to answer that question is to put Odyssey and federation in the context of the work you're already doing. Essentially, the product is going to extend the benefits that organizations have already realized from Novell Nsure solutions to trusted business partners. Identity management capabilities that have traditionally only been available (or at the least, viable) within the enterprise, can now be extended to encompass trusted services outside the firewall. For example, with Odyssey, you'll be able to provide single sign-on, advanced authentication, user account provisioning, identity integration and policy-based access control--only this time, those features will not just affect the systems you directly control, but also the Web sites, applications and services of trusted business partners. With those benefits in mind, let's take a closer look at what Odyssey is and how it works.
What is Odyssey?
The product consists of two basic components: an Identity Provider (IDP), where identity information is stored, and a Service Provider (SP), which can access the identity data within the IDP. From these two basic building blocks, business partners or even different departments within a larger organization can securely share both authentication credentials and specific identity attributes, such as a job title or a home phone number.
Organizations that would typically deploy the IDP would be those that already manage identity data in the physical world, such as a credit card company or an airline, or a large enterprise or government/educational institution that needs to integrate semiindependent departments or branch offices. In the case of an airline, a business partner like a rental car company would be an ideal candidate to deploy the SP; that is, the two companies would benefit by making it as easy as possible for users to transition between their respective Web sites.
For administrators familiar with Novell Nsure Identity Manager (formerly DirXML), you can compare the IDP to the Nsure Identity Manager engine and the SP to an external application connected using a driver. In the Nsure Identity Manager model, the engine is the hub of identity integration, where user, device or application identity data is stored in an identity vault and synchronized bidirectionally among any number of enterprise applications connected to the engine by drivers. Similarly, in Odyssey, the IDP houses identity information that can be shared among any number of SPs, and vice versa. Both products are capable of integrating login credentials (such as a password), identity attributes (like a phone number or e-mail address), and a broad range of other data. The main difference between the two is that while Nsure Identity Manager is primarily deployed on a corporate network, Odyssey can be deployed by business partners or a large, distributed organization over the Internet.
For instance, in an Nsure Identity Manager deployment, when a new employee joins an organization, she can be immediately and automatically granted access to multiple business systems through one simple operation. Provided each of the relevant applications is connected to the Nsure Identity Manager engine with a driver, once the new user account is created in one connected system, typically the HR database, it can be automatically provisioned in all of the others, such as the corporate directory/white pages and the company's e-mail system. Without almost any user intervention, the new employee has been granted access to all the systems she needs. However, as is the case with almost any organization, the employee will not just need to interact with internal company applications, she'll also need access to external partner systems, such as a financial services provider that manages the organization's 401k plan...and that's where Odyssey comes in.
Now that the new employee has been provisioned with basic internal access, she can visit the company intranet to make optional benefits selections, including setting up a 401k. Without Odyssey, getting onto the financial services Web site and accessing the 401k options would be a lengthy process: After clicking the 401k link on the company intranet, she would be required to enter a separate login to authenticate to the site and then spend several minutes entering personal information to create an account--information that's already available within the organization in a number of systems.
With Odyssey, on the other hand, the process is seamless. Because the company itself has deployed the IDP and its partner, the financial services provider, is an established SP, when she clicks on the 401k link in the company intranet, the financial system recognizes that it does not have an account for this user. The employee is then asked if she would like to federate her identity to the financial services provider. If she accepts, the SP will obtain the relevant identity data from the IDP and create the new user account in the financial system. By simply agreeing to federate her identity, the employee now has single sign-on to the 401k site, and her identity attributes, such as a mailing address for 401k statements, have been dynamically added to the system.
As for how the identity information is shared, whereas Nsure Identity Manager uses drivers to integrate with connected systems, the primary vehicle for transmitting identity data from an IDP to an SP, or vice versa, is the Secure Assertions Markup Language (SAML)--either as a general-purpose SAML connection or a SAML connection wrapped in the Liberty Alliance specifications. For the purpose of understanding the fundamental transmission process that underpins Odyssey, let's briefly take a closer look at how these two protocols work:
In order to use general-purpose SAML to share identity data, two business partners, such as a large enterprise and an outsourced benefits provider, have to agree upon the scope of their online partnership (i.e., what identity data they will share with one another) and then cooperate on the naming conventions used for specific identity attributes. For example, one organization might list a username as "samluserid:rjones" while another would use "samlid:rjones" to represent the same attribute. Once those conventions and the general business relationship are established, the companies will be able to transmit SAML assertions between one another. An assertion is essentially a claim made by an identity (such as a user or an application) as to the rights it possesses on another system. Assertions come in three basic forms:
An assertion can be made that a user (or another identity) has been authenticated to one system and should thereby be authenticated to a second, or partner, system. In the example of an enterprise and its outsourced benefits provider, a SAML assertion for authentication could allow a user to seamlessly move from the enterprise intranet to the benefits provider's Web site without having to log in again.
An authorization assertion defines a specific set of resources to which a user should be granted, or denied, access. With such an assertion, two users moving from the enterprise intranet to the benefits provider's Web site could be presented with different coverage information, based on the different health plans in which each is enrolled.
Finally, an attribution assertion actually transmits pieces of information, or identity attributes, about a user between two systems. With the user's permission, data such as a mailing address or a social security number could be transmitted to the outsourced benefits provider to speed, for example, the health insurance claims process.
In practice, these assertions are made using a SAML artifact, which is a time-bound and encrypted set of instructions passed from the source site to the destination site via a specified URL (also known as a backchannel). The destination system uses the instructions in the artifact to determine where on the source system it can obtain the relevant SAML assertion. In other words, the assertion, or the identity information, doesn't actually cross the wire, only the instructions do ensuring the highest level of security for identity data. Once that assertion is obtained, the user is authenticated to the destination site.
SAML is a powerful and extremely flexible vehicle for federation, but it can also be fairly complex to deploy which is where the Liberty Alliance specifications come in. Formed in September 2001 to develop open standards for federated network identity management, the Liberty Alliance is made up of more than 150 members, representing not just technology companies, but also manufacturers, financial institutions, government organizations, educational institutions and many others. Novell itself sits on the Liberty Alliance management board and has been an active member since February 2002.
Recognizing the complexity of a general-purpose SAML implementation, the Liberty Alliance has created a widely accepted set of instructions, known as the Liberty Alliance specifications, that describe a standard methodology for deploying SAML-based services. While these specifications, by their nature, do not offer the same flexibility as a general-purpose SAML implementation, they do allow a much faster deployment without requiring the same kind of one-off negotiation.
The Liberty Alliance specifications introduced a concept known as the Identity Web Services Framework (ID-WSF), which will offer predefined sets of identity information. To date, the Alliance has developed three of these predefined sets, known as Identity Service Instance Specifications (ID-SIS):
The Employee Profile (EP) specifies identity information associated with an employee, including attributes such as employee ID, job start date, job title, a manager's employee ID and many others.
The Personal Profile (PP) describes identity information associated with a principal (generally a user), including attributes such as name, address, social security or credit card number, marital status, phone number, e-mail address, instant messaging ID and many others.
Somewhat different from the EP and PP, the Discovery service (DISCO) provides a standard process for determining what identity data is available on a given system.
The value of these predefined sets of identity information is that they eliminate the need for a detailed discussion of naming conventions and data formats between business partners. In other words, to federate identity information using products that conform to the Liberty specifications, two companies need only negotiate a business relationship--the terms of the "technical relationship" have already been established.
The actual transmission of identity information using the Liberty specifications is based on the SAML process described above, with just one notable addition. Beyond defining standard formats for identity data, the Liberty specs also describe a means through which two organizations can establish a business relationship, at least in the technical sense. (Software will never completely obsolete the work of lawyers.) To create that relationship, two companies have to exchange what's called metadata. This metadata contains all the information necessary to establish a trust relationship, such as digital certificate data. Once the metadata has been exchanged, SAML becomes the day-to-day vehicle for identity federation.
Finally, a discussion of the Liberty Alliance would be incomplete without mentioning the reason the whole thing is meant to be so "liberating." Unlike other attempts at federated network identity (such as Microsoft Passport), the Liberty Alliance specs mandate that users, not Identity Providers or Service Providers or any other -iders, get to decide if and when their identity information will be shared. (See Figure 1.)
Figure 1: Identity federation based on the Liberty Alliance specifications requires that users give their consent before identity data is shared.
What Does Odyssey Do?
With the SAML and Liberty protocols as a foundation, Odyssey delivers a wide range of advanced features that take identity management beyond the firewall to encompass trusted business relationships:
Verify User Identities Through Direct and Indirect Authentication
Odyssey provides a means to manage authentication both across the enterprise and the Internet. Because the IDP features a connection to Nsure Identity Manager and support for federation protocols, it can provide a central point of authentication for internal systems (e.g., a financial application), external systems (a Web portal) and partner systems (personalized 401k information linked through the portal). And that access can be granted both directly and indirectly.
In a direct scenario, a user can log in to the IDP to be authenticated to enterprise applications and be granted (should she agree to federate her identity) single sign-on to partner systems as well as the option of sharing specific identity attributes with those systems. Similarly, if that same user were to log in to a partner system (the SP), that authentication would be redirected to the IDP via a specified URL. Once the user's identity is verified by the IDP, access to the partner system and other relevant applications is granted.
Odyssey also features a number of authentication options. The product's core authentication engine is based on the Pluggable Authentication Module (PAM) format, which includes support for passwords, tokens and X.509 authentication, and can be extended to include a host of other methods.
Once those login credentials are provided, Odyssey can verify them in one of two ways: either locally using an embedded identity store or against an existing enterprise directory. Both options are made possible by a new directory technology called Novell Nsure Identity Broker. Rather than requiring the deployment of a separate directory service (think about installing ZENworks or GroupWise and the requirement that eDirectory first be present), Novell Nsure Identity Broker is a built-in, local identity store specific to Odyssey which can also connect to other LDAP directories for authentication or authorization decisions. This approach gives companies a lot of flexibility. Those that don't have an enterprise directory deployed or that want to capture identity attributes that are relevant only to Odyssey can use the local identity store for authentication and authorization. On the other hand, if a corporate directory, such as Novell eDirectory, Microsoft Active Directory or Sun Java System Directory Server (yes, that's what it's called these days), is already in place, Odyssey can use Novell Nsure Identity Broker to simply link to the existing directory (or multiple directories) to verify user identities and grant access to resources.
Though Odyssey is the first product to feature this embedded directory technology as a built-in component, other Novell products will begin shipping with Novell Nsure Identity Broker in the coming months so stay tuned.
Share Identity Attribute Information
Novell's first foray into Liberty-based federation was the Liberty identity provider for Novell eDirectory, of which an early access version was released in April 2003. Based on the Liberty Alliance 1.1 specifications, this first identity provider made it possible to have single sign-on among different "Liberty-enabled" Web sites, but nothing more. Since then, the Liberty Alliance specifications have matured significantly, adding provisions for much more refined data transmission. By adhering closely to those revised specs, Odyssey allows business partners to securely share even the most sensitive bits of identity data, as noted earlier in our description of the Employee and Personal Profiles. And of course, those partners that want to share data that's outside the bounds of the Liberty specs can also use Odyssey to establish a more customized federation model based on general-purpose SAML. (See Figure 2.)
Figure 2: Odyssey gives companies the option of dynamically "Liberty-enabling" the Web sites of business partners--allowing users to enjoy single sign-on and the secure transmission of identity attributes between those sites.
Manage Identities and Provision Users Between Business Partners
To this point, we've discussed capabilities that, while definitely cutting edge, are at least being actively talked about by other vendors in the identity management space. However, Odyssey also takes the next step in federation capabilities by allowing business partners not only to share identity information but also to manage and provision user accounts on each other's systems provided, of course, the users involved give their permission to do so. This provisioning process is implemented in accordance with the Liberty specs, and can be turned on or off for each SP as the IDP administrator sees fit. If provisioning has been enabled, the process would typically begin when a user tries to federate her identity from an IDP to an SP. With Odyssey, when the transmission between the two partner sites is attempted, and it's discovered that no user account exists on the SP, instead of requiring the user to manually create that account, she is given the option to automatically provision a user account on the SP, based on the identity data contained in the IDP. Suddenly, for an IDP like an airline, the prospect of encouraging users to create a charge card account linked to the airline's frequent flyer program becomes a whole lot easier.
At a functional level, this federated provisioning is accomplished using the Liberty ID-SIS. When a user accepts the option of provisioning an account, the SP on which the federated account needs to be created simply makes a DISCO call to the IDP to determine and obtain the relevant identity data, which is then used to provision the user.
Of course, particularly for an enterprise deployment of Odyssey, the provisioning process doesn't always have to wait until the moment federation is attempted. Instead, for example, when a new employee joins the company, that employee can effectively give permission to federate her identity at the time she signs an agreement of employment. In turn, that agreement would allow an administrator to provision accounts even in relevant partner systems before the new employee's first day on the job. In other words, just as an administrator now uses Nsure Identity Manager to provision user accounts across enterprise applications like a corporate directory, HR system and e-mail application, the addition of Odyssey would allow that same user account to be created in a partner system, such as a benefits selection tool hosted by an outsourced benefits provider. No longer does user account provisioning (or de-provisioning) have to be a lengthy paper- or email- based process just because it crosses the firewall.
Enforce Role-based Policies for Web Access and Other Services
In addition to federation and provisioning capabilities, Odyssey also supports role-based policies for controlling access to Web sites and other applications. With role-based policies, access rights to a given Web site, for example, can be associated with a specific role, such as sales manager, citizen or doctor. In turn, access to that Web site is restricted only to those users that are also associated with that role. For instance, access to a hospital portal that provides private patient data might be available only to those users recognized as "doctors" and not to the hundreds of other staffers throughout the facility.
Using this model, Odyssey, because of its support for federation protocols, can provide policy-based access control not just for a given organization's Web sites and applications, but also for those of its business partners.
Deploy Quickly and Start Federating
Figure 3
Odyssey also makes the prospect of federated identity a relatively simple and easy-to-deploy process. While more complex relationships based on general-purpose SAML can certainly be established with Odyssey, most companies will likely see the benefit of a much faster deployment based on the Liberty specs. Because Odyssey acts as a proxy, it can be placed in front of another server to dynamically Liberty-enable virtually any application or service. Rather than trying to tackle complex configurations and rules definitions, administrators need only install the Odyssey server at both the IDP and SP sites, perform a quick exchange of metadata and then start federating identity information. With most any identity management project, quick success is the key to progress, and Odyssey is designed to provide just that.
Coming Soon...
With Odyssey, Novell maintains its leading-edge position in the latest wave of identity management technology: identity federation. For network administrators, especially those who are familiar with the capabilities of products like Novell Nsure Identity Manager and Novell iChain, Odyssey provides a vehicle to take those capabilities to trusted business partners through the SAML and Liberty Alliance standards. Novell will begin beta testing the product in November. Stay tuned.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.