A Case for Hidden Identity: The concept of federated identity takes shape
28 July, 2004
category: Library
By Nicholas Engels, Contributing Editor
The last time I moved, I made sure to call every company I had any connection with and give them my new address. I was especially concerned that I receive bank statements without interruption, so using my newly installed Comcast Internet service, I signed up for the bank’s online bill pay and address change.
Though I ordered new checks online, they never arrived at my new home. I found the bank’s phone number in my online account statement and was informed that the bank had mailed the package – but it was sent to my address from two years ago, in Northwest Washington, D.C.
Somebody opened my box of checks and made a couple dozen of purchases around the area. The bank refunded me, not my problem I figured, but the bank also refused to pay all the debt – so now Target and a couple liquor stores have my name on a list and won’t let me pay with ink.
Since I never mix alcohol and bargain house wares, it’s not a problem. It’s going to be harder to qualify for a mortgage, less likely that I’ll profiteer from the booming DC housing market, but on the bright side I can still use my debit card.
Ideally, the bank would have shared my address information with the check makers. Even better would be if the bank shared my address change with every person and corporation that I like and trust. Banks should do this, they are in the business of relationship and identity management, and it would make moving much easier.
Federated and Free
Good news is that the banking community is working with service providers and government agencies like GSA and the Social Security Administration. Alliances are forming, building “trust-based” relationships, which enable organizations to securely share a user’s identity information.
Trust relationships allow identity and policy information to flow between organizations independent of platform, application, or security model. Federation, according to Microsoft, describes the technology and business arrangements necessary for this interconnection. Microsoft and IBM (as well as smaller operations like Oblix, Netegrity, and RSA Security) have gathered round the campfire for a chance to stamp product names on a popular federated identity product to master seamless identity management. Non-profit groups, striving for open source access, are also pushing for interoperability, working to create interoperable scenarios.
The Liberty Alliance Project is a growing consortium of 150 companies, non-profits, and government organizations from around the world, fiercely committed to developing an open standard for a federated network identity that supports current and emerging network devices. Federated identity projects in alignment with Liberty want just one set of credentials for trusted transactions with multiple providers on the Web. Liberty dreams of connecting diverse networks, like linking your PDA to a car, with seamless single sign-on. And to think, being Batman used to rank atop of the far-out techie fantasy list behind Warp speed and super lasers.
Liberty Alliance Project :
- Links identity providers
- Links through account federation
- Simplifies sign-on methods
- The U.S. Department of Defense and Argonne labs see light at the end of the tunnel
- The same light warms the Austrian government, Universities in Birmingham and Hamburg, industry groups like Internet2, and dozens of corporations.
SAML with XML delivers
Extensible Markup Language (XML) is a simple, very flexible text format, called extensible because it is not a fixed format like HTML, which is a single, predefined markup language. According to the World Wide Web Consortium, XML can do this because it’s written in SGML, the international standard metalanguage for text markup systems. XML allows design of customized markup languages for different types of transfers, including ID information swapping.
SAML uses XML to provide a standard way to represent authentication, attribution, and authorization decision information. Groups like Liberty, OASIS and Microsoft’s WS-Security offer a series of request and response protocols for exchanging statements.
In the case of XML secure assertions, Liberty extends SAML 1.0 through the creation of original profiles that define federated roles for SAML, an Identity Provider (IDP) and a Credential Service Provider (CSP). These profiles, and others, apply to defined roles within the trust relationships, and make possible single sign-on with global login/logout and account linking.
“Prior to SAML, there was no XML-based standard that enabled exchange of security information between a security system and an application,” said Prateek Mishra of Netegrity, co-chair of the OASIS Security Services Technical Committee. OASIS is an umbrella group that includes businesses and other organizations looking to define and refine SAML standards and applicability. SAML specifies authentication, attribution, and authorization statements.
Unlike PKI, there is no need to utilize outside registration or certificate authorities. Liberty trust circles seamlessly pass identity information back and forth. Recovering lost or stolen passwords becomes an expense of the past. Instead a user passes along an already acceptable credential, verified through the trust relationship.
Advanced Liberty projects are still debugging anonymous one-time assertions of identity. Fear looms over credential service providers, because single sign-on means that once a villain is in, it can go anywhere and do anything. Liberty feels it can address fears with its Phase 3, expected to extend new services built on top of attribute exchange, such as a digital wallet and calendaring/address book services.
SAML 2.0 shoots for full federation with metadata exchanges playing a bigger role. CSPs hope that 2.0 will streamline identifier mapping for steady session management. OASIS says that 2.0 will address enhancement requests that have arisen from experience with real-world SAML implementations able to handle SAML-based standards architectures. OASIS is mulling over the 2.0 refinements, and recently released review documents that will be open to public comment. URL: http://www.oasis-open.org/committees/download.php/4156/sstc-saml-scope-2.0-draft-09.pdf.
“SAML has gained widespread industry adoption as a basis for federated identity and security environments,” said James Kobielus, senior analyst at Burton Group. “Clearly, SAML is a living, evolving standard, and OASIS has, with the new version 1.1, incorporated changes that reflect real-world experience with SAML version 1.0.”
Troubleshooting Federated Identity Schemes
It’s a strange bird that that has time and money to experiment with federated identity models. One such group is the eGov sponsored E-Authentication Initiative, which opened an interoperability test lab last fall to experiment. The initiative teams up with federal agencies and software developers, under guidance of NIST standards, to develop an authentication architecture that could potentially support the twenty-four eGov Presidential initiatives.
E-Auth encourages authentication technology providers to bring SAML 1.0 compliant products to its lab for testing. E-Auth also welcomes certificate validation providers, capable of path validation and discovery in the Federal PKI.
Less than a year after inception, the initiative validated an open standards-based, federated authentication model. Five vendors demonstrated basic interoperability using SAML 1.0 artifact profile.
- Entegrity AssureAccess v3.0.0.4
- Hewlett-Packard Select Access v5.2
- Oblix NetPoint v6.1
- RSA Security Federal Identity Manager v2.5LA
- Sun Microsystems Sun Java System Identity Server v6.1
Interoperability configuration occurred over two general phases. First vendors worked with E-Auth lab teams to identify and configure SAML assertions. After troubleshooting and debugging, vendors are required to independently configure their product to enable interoperability. Independent of lab guidance, Sun Identity Server programmers had to achieve basic interoperability with Oblix Netpoint before the initiative labeled the two interoperable.
About the author:
Nick Engels is a consultant for several Federal Contractors, most recently with ED.gov and GSA. Engels is also co-founder of Leviathan Technology Group, which developed the pilot version of CourseList.net – an array of search tools designed to deliver location-based results for education markets.