Students taking physics courses at Penn State University may be rocket scientists in training, but they're all too normal in one respect: Like most everyone else, they often forget the multiple user names and passwords they need to authenticate themselves on the various systems they use within the 24-location university.
Solving that problem – replacing forgotten passwords – was, in a nutshell, the driving force behind one of the earliest deployments of a so-called federated identity management system. At the request of physics instructor John Hopkins, the school's emerging technology group in 2002 deployed a pilot federated ID management project based on an early version of Shibboleth, an open source middleware product developed by the Internet2 consortium that allows the granting of access rights to multiple systems via a single set of authorization credentials.
The project delivered results quickly: The physics department's help desk reported an 85 percent drop in user- and password-related calls after using Shibboleth for just the last two weeks of the spring semester.
Not surprising, the department was thrilled with the project, says Renee Shuey, a senior systems engineer and crew leader of the university's emerging technology group, which acts as a liaison between faculty, students and the administration to investigate and deploy new IT systems. The department opened the Shibboleth-based project to several other instructors in the fall, and now has expanded it to encompass the school's entire population – 80,000 students and 20,000 faculty and staff.
While all of those students and faculty may not be actively involved with the program, all of them are supported by a single, centrally supported user name and password to their PSA account that can be used to authenticate a broad range of systems within and outside the university.
These include access to resources at a variety of organizations via InCommon, a federation of about 80 higher education institutions, research labs and commercial businesses across the U.S., and 14 federated ID projects within Penn State, including Simplicity, a partnership between Penn State's Career Services Department and an outsource recruiting service. Penn State students can also use their single federated ID to access Microsoft's DreamSpark (which allows them to download the company's software for free), the National Institutes of Health, the Lawrence Berkley National Laboratories, and iTunes via the InCommon Federation.
Holy grail of IDs
It's not too far-fetched to call a federated identity management system the holy grail of authentication and access control. In its ideal form, it is intended to allow an end-user to login once – so-called single sign-on (SSO) – then access a multitude of resources, not just the servers and applications within an organization's perimeter, but those located outside the firewall, as well.
In a federated environment, an employee could log into a software-as-a-service offering, such as Salesforce.com, or check on the inventory of a partner, such as a supplier of auto parts, all after using just a single set of credentials. The outside resources could also include medical or 401K records maintained by the enterprise's insurance company or an independent financial services organization – again, accessible via one set of credentials.
Federation is also a key requirement in emerging service-oriented architecture (SOA) implementations. An SOA system unifies business processes by structuring large applications as an ad hoc collection of smaller modules, or services, all of which require credentials to authenticate themselves with each other.
That being said, however, with the notable exception of InCommon, there are few federated ID management implementations, according to vendors and analysts.
“We haven't seen the kind of adoption one would expect,” admits Daniel Blum, senior vice president and principal security analyst with the Burton Group.
Blum says that the federal government has developed an E-Authentication Solution intended to simplify doing business with a variety of government agencies, including the General Services Administration (GSA), the Veterans Administration and others. However, it hasn't lived up to hopes they had for it in terms of bringing government to citizens, Blum says.
In the enterprise space, federated ID management is on a paced adoption, according to Matthew Gardiner, a senior product manager in CA's security management unit. “We've seen steady adoption over the last five or six years, but no one's shooting at the moon,” he says.
Several vertical markets have seen strong deployment of federations, according to Blum, Gardiner and others. These include the financial services environment, the manufacturing sector and the aerospace, automotive, health care, pharmaceutical and petroleum industries.
Among the forces driving the adoption of identity federations within the enterprise space are regulatory compliance, the need to automate business or economic processes among multiple companies, and lowering the costs of managing identities. They also include end-user convenience and the increasing use of outsourced services and applications that require secure communications channels.
“In a word, federated ID management is about compliance and compliance automation,” says Roger Sullivan, vice president of business development in Oracle's identity management group. “I've spent time with customers here in the U.S. and internationally, and the single motivating factor over and over again is they're buried with requirements for compliance, either regulatory, such as Sarbanes-Oxley (SOX) or the Gramm-Leach-Bliley Act (GLB), or internal policies.”
Federating their access-management environments gives them another set of tools to show that they conform to SOX or GLB mandates, Sullivan explains. “Moreover, I don't see it limited to publicly traded companies. If I'm a large multinational subject to SOX, I tell every supplier they must be SOX compliant as well. In order to do that, they need to know who is accessing their data.”
An identity federation that brings together individuals from multiple entities provides these capabilities, he says.
Before organizations can take advantage of federated ID, however, they must deploy underlying identity management technology, such as SSO, to manage access control, the provisioning of authentication credentials and to provide effective auditing and reporting capabilities, Sullivan adds. “They can then move onto more sophisticated scenarios that federate identity across divisions or even corporate boundaries.”
Outsourcing drives it
Mike Donaldson, vice president of marketing at Ping Identity, says that the trend to outsource a wide range of operations – from human resources to 401K to SaaS applications – is also driving federations. Increased business process outsourcing (BPO) is another driving factor, he says.
Federating IDs in outsourced environments pays off in increased user convenience, according to CA's Gardiner. Users like federated ID programs because it allows them to rely on SSO credentials to access multiple outsourcers' resources, he points out. CA itself outsources health and pension plans and building management, among other things, and its employees can access them all with a single user name and password, he says.
As the 85 percent drop in help desk calls in the Penn State pilot showed, identity federations can also help lower the cost of managing user credentials. When IT help desks answer calls to reset passwords, they cost real money, Gardiner says. “If you federate access, only one ID provider, not every participant in the exchange, has to issue a credential.”
Federated ID programs offer a hidden benefit, as well, according to Donaldson. “Users are more apt to access the outsourced application with federated identity because there are fewer barriers for them to overcome,” he says.
That factor has played a role in federated ID's growth in health care, according to Joe Anthony, a program director for security and compliance management at IBM's Tivoli unit. It enhances collaboration between so-called health care providers (i.e., physicians and hospitals) and payers, such as insurance companies, he says.
“It makes it easier to pass information back and forth. Employees don't have to enter multiple user names and passwords,” he says. “And you can have some of the applications talk back and forth.”
Building ‘trust relationship'
One of the major hurdles in deploying an identity management system is establishing what the Burton Group's Blum calls the “trust relationship” across the organizations involved.
“Secondary to that is putting the technology into play,” he says. “There may or may not be a sense of human trust between the executives at the companies involved,” he explains. “It's more than just a relationship of convenience – with many different companies involved which have not worked together before.”
The process of developing an identity federation requires lead time to get buy-in from the various interested parties and hammering out the agreement, he adds. Some of the details include determining the security technologies to be used, how users will be authenticated, and how to determine when employees have left a member organization. In other words, why should I trust your company when your employee is authorized to sign into my system? Blum says.
There are obstacles in getting trust between the legal folks, who want contracts, and security folks, who want an audit, he says. “There isn't a standard boilerplate contract that covers this, and there isn't one audit process that every company can easily fit into place for federating identity.”
‘Closed circle' federations
With true multicompany federated deployment facing slow adoption outside of higher education, so-called hub-and-spoke variations of the technology are appearing. In these environments, several entities – suppliers, outsourcers and others – all share a hub with a single partner, but there's no interaction among the multiple participants.
Such closed circle federations working with a strong central participant, such as Wal-Mart, force suppliers to adopt its identity management practices if they want to do business with the company, says Jackson Shaw, a senior director of product management at Quest Software. In these cases, the company with a big stick requires its suppliers to federate, he says.
That might well be the future of federated ID management within commercial enterprises.
“We're not seeing the true multilateral use that characterizes high education use,” says Ken Klingenstein, director of the Internet2 Middleware Initiative, the industry group that develops Shibboleth. “I'm not even sure there's a real multilateral use case for federated identity outside of the educational domain. Companies are more competitive than collaborative, whereas higher education is more collaborative than competitive.”
Cliff Grossman, a product manager at Alcatel-Lucent, who works in the federated ID market, doesn't foresee what he calls “volume deployment” of the technology in the next year. “We're looking more at three to five years before significant volume deployment,” he says, “because customers I talk to are more concerned about cleaning up internal security issues and compliance than investing in automating partners in business-to-business transactions.”
Federated ID may not be appropriate for enterprises with “too many business partners,” the Burton Group's Blum says. As a result, “Longer term, we may see more adoption of the hub concept.”
[Sidebar]
SAML:
Like most of the federated identity management solutions available, Shibboleth – the open source middleware software product at the foundation of the InCommon Federation and in use by nearly 100 U.S. universities – is based on SAML, the Security Assertion Markup Language (SAML).
SAML, developed by the OASIS Security Services Technical Committee, is an Extensible Markup Language (XML) standard for exchanging authentication and authorization data between security domains. It provides standard mechanisms for organizations – called identity providers in the SAML parlance – who want to authenticate their users with those who provide services, such as outsourcing firms or partners in online business-to-business transactional environments.
SAML is analogous to IP in the TCP/IP protocol stack, while Shibboleth is the TCP portion of the equation, according to Ken Klingenstein, director of the Internet2 Middleware Initiative, which develops Shibboleth. “SAML moves packets with attributes of people rather than data,” he says.
SAML began as a unidirectional protocol that allowed exchanging credentials on a one-to-one basis, according to Roger Sullivan, an Oracle vice president as well as president of the board of the Liberty Alliance, a group of industry and government organizations working to develop open federated identity standards. It now supports bi-directional credential exchange, making it easier to bolt together federated ID products from multiple business partners, he says.
Most of the commercial federated ID management products on the market use SAML-based technologies, according to Klingenstein, adding that most of them have gone through the Liberty Alliance's conformance program to ensure interoperability among the various products. – Jim Carr
Solving that problem – replacing forgotten passwords – was, in a nutshell, the driving force behind one of the earliest deployments of a so-called federated identity management system. At the request of physics instructor John Hopkins, the school's emerging technology group in 2002 deployed a pilot federated ID management project based on an early version of Shibboleth, an open source middleware product developed by the Internet2 consortium that allows the granting of access rights to multiple systems via a single set of authorization credentials.
The project delivered results quickly: The physics department's help desk reported an 85 percent drop in user- and password-related calls after using Shibboleth for just the last two weeks of the spring semester.
Not surprising, the department was thrilled with the project, says Renee Shuey, a senior systems engineer and crew leader of the university's emerging technology group, which acts as a liaison between faculty, students and the administration to investigate and deploy new IT systems. The department opened the Shibboleth-based project to several other instructors in the fall, and now has expanded it to encompass the school's entire population – 80,000 students and 20,000 faculty and staff.
While all of those students and faculty may not be actively involved with the program, all of them are supported by a single, centrally supported user name and password to their PSA account that can be used to authenticate a broad range of systems within and outside the university.
These include access to resources at a variety of organizations via InCommon, a federation of about 80 higher education institutions, research labs and commercial businesses across the U.S., and 14 federated ID projects within Penn State, including Simplicity, a partnership between Penn State's Career Services Department and an outsource recruiting service. Penn State students can also use their single federated ID to access Microsoft's DreamSpark (which allows them to download the company's software for free), the National Institutes of Health, the Lawrence Berkley National Laboratories, and iTunes via the InCommon Federation.
Holy grail of IDs
It's not too far-fetched to call a federated identity management system the holy grail of authentication and access control. In its ideal form, it is intended to allow an end-user to login once – so-called single sign-on (SSO) – then access a multitude of resources, not just the servers and applications within an organization's perimeter, but those located outside the firewall, as well.
In a federated environment, an employee could log into a software-as-a-service offering, such as Salesforce.com, or check on the inventory of a partner, such as a supplier of auto parts, all after using just a single set of credentials. The outside resources could also include medical or 401K records maintained by the enterprise's insurance company or an independent financial services organization – again, accessible via one set of credentials.
Federation is also a key requirement in emerging service-oriented architecture (SOA) implementations. An SOA system unifies business processes by structuring large applications as an ad hoc collection of smaller modules, or services, all of which require credentials to authenticate themselves with each other.
That being said, however, with the notable exception of InCommon, there are few federated ID management implementations, according to vendors and analysts.
“We haven't seen the kind of adoption one would expect,” admits Daniel Blum, senior vice president and principal security analyst with the Burton Group.
Blum says that the federal government has developed an E-Authentication Solution intended to simplify doing business with a variety of government agencies, including the General Services Administration (GSA), the Veterans Administration and others. However, it hasn't lived up to hopes they had for it in terms of bringing government to citizens, Blum says.
In the enterprise space, federated ID management is on a paced adoption, according to Matthew Gardiner, a senior product manager in CA's security management unit. “We've seen steady adoption over the last five or six years, but no one's shooting at the moon,” he says.
Several vertical markets have seen strong deployment of federations, according to Blum, Gardiner and others. These include the financial services environment, the manufacturing sector and the aerospace, automotive, health care, pharmaceutical and petroleum industries.
Among the forces driving the adoption of identity federations within the enterprise space are regulatory compliance, the need to automate business or economic processes among multiple companies, and lowering the costs of managing identities. They also include end-user convenience and the increasing use of outsourced services and applications that require secure communications channels.
“In a word, federated ID management is about compliance and compliance automation,” says Roger Sullivan, vice president of business development in Oracle's identity management group. “I've spent time with customers here in the U.S. and internationally, and the single motivating factor over and over again is they're buried with requirements for compliance, either regulatory, such as Sarbanes-Oxley (SOX) or the Gramm-Leach-Bliley Act (GLB), or internal policies.”
Federating their access-management environments gives them another set of tools to show that they conform to SOX or GLB mandates, Sullivan explains. “Moreover, I don't see it limited to publicly traded companies. If I'm a large multinational subject to SOX, I tell every supplier they must be SOX compliant as well. In order to do that, they need to know who is accessing their data.”
An identity federation that brings together individuals from multiple entities provides these capabilities, he says.
Before organizations can take advantage of federated ID, however, they must deploy underlying identity management technology, such as SSO, to manage access control, the provisioning of authentication credentials and to provide effective auditing and reporting capabilities, Sullivan adds. “They can then move onto more sophisticated scenarios that federate identity across divisions or even corporate boundaries.”
Outsourcing drives it
Mike Donaldson, vice president of marketing at Ping Identity, says that the trend to outsource a wide range of operations – from human resources to 401K to SaaS applications – is also driving federations. Increased business process outsourcing (BPO) is another driving factor, he says.
Federating IDs in outsourced environments pays off in increased user convenience, according to CA's Gardiner. Users like federated ID programs because it allows them to rely on SSO credentials to access multiple outsourcers' resources, he points out. CA itself outsources health and pension plans and building management, among other things, and its employees can access them all with a single user name and password, he says.
As the 85 percent drop in help desk calls in the Penn State pilot showed, identity federations can also help lower the cost of managing user credentials. When IT help desks answer calls to reset passwords, they cost real money, Gardiner says. “If you federate access, only one ID provider, not every participant in the exchange, has to issue a credential.”
Federated ID programs offer a hidden benefit, as well, according to Donaldson. “Users are more apt to access the outsourced application with federated identity because there are fewer barriers for them to overcome,” he says.
That factor has played a role in federated ID's growth in health care, according to Joe Anthony, a program director for security and compliance management at IBM's Tivoli unit. It enhances collaboration between so-called health care providers (i.e., physicians and hospitals) and payers, such as insurance companies, he says.
“It makes it easier to pass information back and forth. Employees don't have to enter multiple user names and passwords,” he says. “And you can have some of the applications talk back and forth.”
Building ‘trust relationship'
One of the major hurdles in deploying an identity management system is establishing what the Burton Group's Blum calls the “trust relationship” across the organizations involved.
“Secondary to that is putting the technology into play,” he says. “There may or may not be a sense of human trust between the executives at the companies involved,” he explains. “It's more than just a relationship of convenience – with many different companies involved which have not worked together before.”
The process of developing an identity federation requires lead time to get buy-in from the various interested parties and hammering out the agreement, he adds. Some of the details include determining the security technologies to be used, how users will be authenticated, and how to determine when employees have left a member organization. In other words, why should I trust your company when your employee is authorized to sign into my system? Blum says.
There are obstacles in getting trust between the legal folks, who want contracts, and security folks, who want an audit, he says. “There isn't a standard boilerplate contract that covers this, and there isn't one audit process that every company can easily fit into place for federating identity.”
‘Closed circle' federations
With true multicompany federated deployment facing slow adoption outside of higher education, so-called hub-and-spoke variations of the technology are appearing. In these environments, several entities – suppliers, outsourcers and others – all share a hub with a single partner, but there's no interaction among the multiple participants.
Such closed circle federations working with a strong central participant, such as Wal-Mart, force suppliers to adopt its identity management practices if they want to do business with the company, says Jackson Shaw, a senior director of product management at Quest Software. In these cases, the company with a big stick requires its suppliers to federate, he says.
That might well be the future of federated ID management within commercial enterprises.
“We're not seeing the true multilateral use that characterizes high education use,” says Ken Klingenstein, director of the Internet2 Middleware Initiative, the industry group that develops Shibboleth. “I'm not even sure there's a real multilateral use case for federated identity outside of the educational domain. Companies are more competitive than collaborative, whereas higher education is more collaborative than competitive.”
Cliff Grossman, a product manager at Alcatel-Lucent, who works in the federated ID market, doesn't foresee what he calls “volume deployment” of the technology in the next year. “We're looking more at three to five years before significant volume deployment,” he says, “because customers I talk to are more concerned about cleaning up internal security issues and compliance than investing in automating partners in business-to-business transactions.”
Federated ID may not be appropriate for enterprises with “too many business partners,” the Burton Group's Blum says. As a result, “Longer term, we may see more adoption of the hub concept.”
[Sidebar]
SAML:
The heart of federated ID solutions
Like most of the federated identity management solutions available, Shibboleth – the open source middleware software product at the foundation of the InCommon Federation and in use by nearly 100 U.S. universities – is based on SAML, the Security Assertion Markup Language (SAML).SAML, developed by the OASIS Security Services Technical Committee, is an Extensible Markup Language (XML) standard for exchanging authentication and authorization data between security domains. It provides standard mechanisms for organizations – called identity providers in the SAML parlance – who want to authenticate their users with those who provide services, such as outsourcing firms or partners in online business-to-business transactional environments.
SAML is analogous to IP in the TCP/IP protocol stack, while Shibboleth is the TCP portion of the equation, according to Ken Klingenstein, director of the Internet2 Middleware Initiative, which develops Shibboleth. “SAML moves packets with attributes of people rather than data,” he says.
SAML began as a unidirectional protocol that allowed exchanging credentials on a one-to-one basis, according to Roger Sullivan, an Oracle vice president as well as president of the board of the Liberty Alliance, a group of industry and government organizations working to develop open federated identity standards. It now supports bi-directional credential exchange, making it easier to bolt together federated ID products from multiple business partners, he says.
Most of the commercial federated ID management products on the market use SAML-based technologies, according to Klingenstein, adding that most of them have gone through the Liberty Alliance's conformance program to ensure interoperability among the various products. – Jim Carr
