Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption
| < Day Day Up > |
| The Liberty Alliance Project is developing a set of standards that allow you to use an SAML authentication assertion across multiple security domains. The Liberty federated identity infrastructure allows you to create a circle of trust with your affiliates . Although each member of this circle maintains and protects its own unique user information, a single federated identity credential can be used as proof of authentication with all members of the circle. Each member maps the federated identity credential into the private user identity known within that member's trust domain. The Identity Problem
A digital identity is a name with a set of attributes. You can think of it as a credential. Attributes of this credential might be date of birth, email address, Social Security number, phone number, medical data, financial data, and so on. Each user has multiple identities. You have one for your laptop login; one for your online bank account; one for your ATM; one for your company intranet; one when you buy from Amazon.com, from Travelocity, from Avis, from Marriott, from Staples; and so on. In this case, each identity requires you to re-authenticate. This has led not only to a dramatic proliferation of passwords to remember, but also to a degradation in overall security as humans with limited memories use simpler passwords, use the same password at every location, and write them down in defense from this onslaught. As long as each of these resources requiring authentication remains distinct with its own trust domain, this situation will persist. Worse, there is no possibility for merged services from these resources. For instance, buying a ticket directly from United.com, where you authenticate yourself and then to book a hotel directly from Marriott.com at your destination requires you to re-authenticate at Marriott.com because the company's trust domain and that of United.com have nothing to do with each other. This affects all these consumer services negatively. Portals are a stop-gap solution short of federation because they provide " one-stop shopping" for a variety of related resources. (Portals are most often constructed by using Web services to link all the back-end resources into a Web front end accessible to browser users.) Travel sites, company intranets , trading partners , employee benefits providers ”all are hampered from delivering better service as long as the "islands of identity" problem persists. One solution is a centralized identity provider. This is the model for Microsoft Passport. This model has met with a lot of resistance because it puts too much control in the hands of one provider. The alternative is an open federated model. Federated Identity
Federated identity is really just shared authentication. It will open new relationships between partners on the Internet. Shared authentication allows one enterprise, which has an online relationship with a customer named Alice, and a means of authenticating Alice, to pass her identity over to another enterprise. The "receiving" enterprise does not have to re-authenticate Alice but can rely on the work done by the "sending" enterprise. The process by which these two entities establish this shared identity is called identity federation . Cross-domain authentication of humans is just part of what Liberty's federated identity is all about. Clearly, there is a need with Web services for cross-domain authentication of applications as well. How Liberty Uses SAML
Travel providers all have dedicated sites with a different identity for you at each one. When you travel, you usually need a hotel and frequently a car at your destination. But if you started directly at the airline site because you wanted to use frequent flyer miles to buy the ticket (because airlines don't share that program with either the travel portals or their business partners), you are out of luck in reserving your hotel and car through that site. You have to go to the corresponding hotel or car sites and log in again. Web services between their back-end systems will link them together, and with Liberty enabled by SAML, your login at the airline site will be transported as a set of SAML assertions to the hotel and car rental sites, and you won't have to log in again. Liberty is designed to allow all the travel sites to create a circle of trust and to federate your identity between them as they send data about you back and forth over Web services. Banks, merchants , and many other federations that share users are ready to "flatten" out the Internet's hub-and- spokes model with Liberty and SAML. Liberty explicitly uses SAML and even extends it to provide for an authentication context (described soon). Today, Liberty is used mostly in consumer- facing Web sites, but increasingly it will be used in Web services. The initial focus for the Liberty standards is to provide single sign-on (SSO) capability for Web services. Account Linking
Privacy is a big concern for Liberty because it does not want to allow circle of trust partners to share your personal information with others. Identity federation provides for privacy through a concept known as account linking . As accounts are linked, each account owner needs a frame of reference for the user. If the account names were to be freely exchanged, privacy would be compromised. So Liberty defines opaque handles for each account that the others cannot see; only the user can resolve the handles. Authentication Context
Liberty provides an enhanced single sign-on known as authentication context . It extends an SAML authentication assertion to include context. Context includes important questions relating to the identification step that initially established the subject's identity. That step results in stored shared secrets that later authentication uses in a challenge that must be met correctly for successful authentication. If the shared secret is "Fay" and the authentication challenge is "What is your mother's maiden name?" successful authentication will happen only if the SAML assertion included the correct answer to the challenge. But how strong was the identification when the user was initially identified and stored the maiden name as Fay? And when should re-identification be done? Answers to these questions are needed to know how trustworthy the identification is. Authentication is only as strong as
Liberty extends SAML authentication requests to allow for requesting a specific authentication type. And different levels of authentication are available. Authentication you need to buy a book, for example, is not the same as what you need to commit your company to a $100,000 contract. Liberty's SAML Profiles
Liberty is building a suite of SAML profiles. Some of the profiles initially proposed include
The Microsoft Passport Alternative Approach
Microsoft proposes Passport as an alternative approach for identity management. Consumers place all relevant personally identifiable information that might be useful when interacting with consumer-oriented Web sites into a centralized registry, which is managed. Sites that sign up to support Passport then accept login credentials from Passport as opposed to direct interaction with the consumer. Passport has not endorsed SAML nor made itself interoperable with SAML.
|
| < Day Day Up > |