- 15 Non-Certified IT Skills Growing in Demand
- How 19 Tech Titans Target Healthcare
- Twitter Suffering From Growing Pains (and Facebook Comparisons)
- Agile Comes to Data Integration
Network World - Companies looking to make Web services available to business partners and their respective user bases must first figure out how to federate identity. Federated identity management refers to managing access so that only those who have a right to use specific services may do so.
Take for example Acme Insurance, which wants to make quotes through Web services to legitimate employees of multiple employer partners. If Acme needs to create a user account for each new employee of an employer partner, it would need to maintain a large user database at a high cost. It's far more efficient to have the employer basically vouch for its employees.
There are several XML standards for federating identity across domains: Security Assertion Markup Language (SAML), Liberty Alliance and Web Services Federation Language (WS-Federation). They can be used to eliminate duplicate user repositories, while letting companies intermix standards-compliant products from different vendors. For example, an XML-/SAML-aware gateway or proxy can be used to both enforce access control efficiently and handle other Web services security processing such as XML threat protection, schema validation and message security.
SAML and Liberty Alliance are converging: SAML 2.0 is under public review and will incorporate more advanced features from Liberty Alliance, such as single logout and account linking.
An examination of SAML 1.1 will provide a good understanding of the basics that can be extended to SAML 2.0/Liberty Alliance.
SAML is a framework for exchanging XML assertions of security information so that a user only needs to be authenticated once and other parties can use that information. More specifically, SAML supports:
Here's how Acme can use SAML to manage federated identity. First, the employee authenticates with the employer Intranet portal. Clicking on a link on the employer's portal triggers a Simple Object Access Protocol (SOAP) request to Acme's Web service for an insurance quote. In the SOAP request, the employer inserts a SAML authentication assertion about the employee having been authenticated by the employer identity server where it stores employee IDs. Acme then can check the SAML assertion in the request to ensure that the employee identity is valid, and returns the requested quote to the employer for formatting and display on the Intranet portal.
Different employees might be eligible for different discount on insurance policies based on their position and years of seniority with the employer. The employer can insert SAML attribute assertions on relevant attributes for each employee. Acme then, based on different attributes, can quote a different price.
How can Acme ensure the employee did not fake a SAML assertion claiming authentication by the employer? While not a requirement, SAML provides guidelines on signing the message to provide message integrity, authenticity and non-repudiation. In our example, the employer can sign the message and Acme then can verify the signature before allowing a message through. Parts of the message containing sensitive information, such as the employee's Social Security number, also can be encrypted.