Federated Identity Management Interoperability

  • Article

 

Microsoft Corporation

May 2004

Summary: As enterprises extend internal systems to external users, it is important to ensure that the systems can interoperate with other organizations' applications. Leading Identity Management Solution providers demonstrated their solutions that meet this need in a recent Interoperability Workshop. (7 printed pages)

Note This document describes the results of that Workshop in which implementations of an interoperability scenario using the WS-Federation Passive Requestor Profile based upon the Web Services Security set of standards were tested.

Contents

Federated Identity Management
Web Services Protocol Workshops
WS-Federation Passive Requestor Profile Interoperability
Workshop Results and Discussion
Related Links

Federated Identity Management

To meet the challenge of current industry trends such as growth in business-to-business commerce, increased mobility and the need for persistent connectivity, organizations are extending internal systems to external users providing connectivity to customers, partners, suppliers and mobile employees. Providing efficient and seamless connectivity requires building "trust-based" relationships that 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. Trust relationships need to be formed quickly and efficiently to maximize productivity and eliminate the manual processes that often take place today. Federation describes the technology and business arrangements necessary for this interconnection.

Federated systems need to interoperate across organizational boundaries and connect processes utilizing different technologies, identity storage, security approaches and programming models. Within a federated system, identities and their associated credentials are still stored, owned and managed separately. Each individual member of the federation continues to manage its own identities, but is capable of securely sharing and accepting identities and credentials from other members' sources.

Within a federated system, an organization needs a standardized and secure way of expressing not only the services it makes available to trusted partners and customers, but also the policies by which it runs its business such as which other organizations and users it trusts, what types of credentials and requests it accepts, and its privacy policies.

Responding to this need, Microsoft is working with industry leaders to develop a set of specifications for distributed application architecture commonly referred to as Web services. The Web services architecture is based on industry standards such as SOAP, XML, WSDL and UDDI and provides a foundation for delivering complete, interoperable business solutions for the extended enterprise including the capability to manage federated identity and security. The Web services model is grounded on the idea that enterprise systems are written in different languages, with different programming models, which run on and are accessed from many different types of devices. Web services are a platform- and language-independent means of building distributed systems that can connect and interact with one another easily and efficiently across the Internet. More information regarding Web services and Web services specifications can be found on the MSDN Web Services Developer Center.

Interoperability

Success of the Web services architecture, and the applications it enables, depends upon the ability of these applications to interoperate across a trusted network of businesses, partners and services regardless of the platform, programming language or application with which they're interacting. To that end, enterprise businesses implementing Web services want their applications to comply with Web services standards to ensure interoperability. Web services standards—including SOAP, XML, WSDL, and UDDI—successfully enable developers to create Web service solutions that are interoperable across multiple platforms, programming languages and applications. One of the main ways to confirm this interoperability exists, and that the Web services specifications are delivering on these business goals, is through protocol interop workshops.

Web Services Protocol Workshops

Web Services Protocol Workshops are a way to involve the Web services community (including end-user companies, ISVs, and other vendors) in the process of validating and refining the WS-* specifications. There are two types of Workshops: Feedback and Interoperability. Feedback Workshops allow the author of each Web Services Protocol to share background information on the design and receive feedback from attendees on the practicality of implementation. The Interoperability Workshops are held for the same reasons and in addition allow companies to test the interoperability of their implementation with other Workshop participants.

Once all feedback and implementation results have been gathered from the Workshops, the authors update and refine the specification for submission to a standards-setting organization.

WS-Federation Passive Requestor Profile Interoperability Workshop

On March 29th and 30th, 2004, the authors of the WS-Federation Passive Requester Profile specification hosted a two-day Interoperability Workshop on the Microsoft campus in Redmond, Washington.

The two-day workshop was an open forum for companies who have implementations based on the WS-Federation specification published on July 8th, 2003 and the WS-Federation Passive Requester Profile, also published July 8th, 2003. A scenario document was provided before the event and attendees were invited to test their implementations of the scenario with implementations from other companies. Participants in the Workshop included IBM Corporation, Microsoft Corporation, Netegrity Inc., Oblix Inc., OpenNetwork Corporation, Ping Identity Corporation, and RSA Security Inc. More information regarding this and other Web Services Protocol Workshops can be found on MSDN.

WS-Federation Specification

The WS-Federation specification is part of the Web Services Security specification set. It defines a model and set of messages for brokering trust and the federation of identity and authentication information across different trust realms.

The WS-Federation specification identifies two sources of identity and authentication requests across trust realms: active requestors, such as SOAP-enabled applications, and passive requestors defined as HTTP browsers capable of broadly supported HTTP (e.g., HTTP 1.1).

WS-Federation Passive Requestor Profile

The WS-Federation Passive Requestor Profile is an implementation of WS-Federation and proposes a standard protocol for how passive requestors (such as Web browsers) apply the federation framework. Within this protocol, Web service requestors are expected to understand the new security mechanisms and be capable of interacting with Web service providers.

WS-Federation Passive Requestor Profile Interoperability

WS-Federation Passive Requestor Interoperability Profile

The WS-Federation Passive Requestor Interoperability Profile is a further constraint on the Passive Requestor Profile with the purpose of providing more interoperability guarantees. The profile defines a standard for requesting, exchanging, and issuing security tokens within the context of a passive requestor using SAML (Security Assertion Markup Language) as the token type.

The WS-Federation Passive Requestor Interoperability Profile was created and distributed to participants prior to the Workshop as a guide for creating interoperable implementations of the WS-Federation Passive Requestor Profile. To test the recommended protocol, vendors collaborated on the creation of an implementation scenario. This scenario reflects the common need for organizations to outsource services, such as benefits, to third parties but provide branded access to the service through an internal Web site (the passive requestor in this scenario).

Interop Scenario

In the scenario for the interoperability workshop, a company, My Employer (ME), outsources the management of employee benefits to a third party, Benefits Company (BC). My Employer and Benefits Company have established trust and policies for a business federation. As part of the coordination of their business federation with Benefits Company, My Employer agrees to send certain user-specific attributes, along with the resource request to Benefits Company. The benefits management application at Benefits Company requires these attributes to exist before displaying the specific resource the employee at My Employer has requested.

The goal of this scenario was threefold:

  • Illustrate a business-to-business federation between an organization and a third-party service provider by enabling ME to outsource the management of employee benefits.
  • Test the interoperability between different vendor solutions created using the standards outlined in the WS-Federation Passive Requestor Profile.
  • Realize the benefit of a business federation by:
    • Eliminating the need for BC to manage identity and passwords for ME's employees in order to administer benefits.
    • Providing trusted Web Single Sign On (SSO) for the ME employees to the BC domain.

Scenario Walkthrough

An ME employee is at work and accesses an internal benefits portal page. If the employee has not yet logged in to their domain at ME they must do so before being given access to the benefits portal page. The benefits portal page displays information pertinent to the individual user, or ME itself, and has links to manage the user's benefits.

The employee clicks on the benefits management link and is authenticated to the Benefit Company using the credentials previously provided for authentication to the ME benefits portal page.

The employee is presented with a customized "Welcome Page" by the benefits management application that provides personalized information about the employee's benefits choices.

Here an actual benefits application implementation would allow an employee to update their health plan options and click a link to manage their health plan. The employee is shown the different health plan options available and how much each plan costs. The employee selects a new health plan and is shown the new amount to be deducted from each paycheck. The employee is asked to confirm this transaction.

The employee confirms their selection and returns to the customized "Welcome Page" which now displays the updated health plan information.

If the employee again clicks the link to their health plan, they are shown the details of the health plan they chose and have the ability to modify their choice before the end of the enrollment period.

After completing the transaction, the employee clicks a sign-out link on the BC site, and is transferred back to an internal portal at ME that displays confirmation that the employee has been signed out of the Benefit Company application.

Workshop Results and Discussion

The WS-Federation Passive Requestor Profile Interoperability Workshop demonstrated high levels of interoperability between all implementations from all vendors participating, and this was achieved much more rapidly than expected, and with fewer issues—which is a clear sign of the growing maturity of these implementations.

Customers implementing Web services today want to know that their applications comply with existing standards and are capable of interoperability with other products supporting Web services. Implementations of the interoperability scenario tested at the Workshop demonstrated interoperability between all vendor solutions.

Providing a comprehensive, consistent and extensible model for Web services and Federated Identity Management requires coordinated efforts by platform vendors, application developers, network and infrastructure providers and customers. Events such as the recent WS-Federation Passive Requestor Profile Interoperability Workshop promote broad industry involvement in the evolution of Web services standards and ensure customers, developers and vendors have proven protocols for building Web services that are consistent, reliable and interoperable across platforms, applications and programming languages.

Interoperability is, and will continue to be, a growing factor in customers' decisions regarding Web Services implementations. To support interoperability in the implementation of Web services, Microsoft recommends:

  • Follow established Web services implementation protocols. Web services specifications and additional support for the development and implementation of Web services can be found on the MSDN Web Services Developer Center.
  • Participate in upcoming Web Services Feedback and Interoperability Workshops. Click to get more Workshop information.
  • Familiarize yourself with WS-I interoperability guidelines. More information about the guidelines and other WS-I developer resources can be found at http://www.ws-i.org/.
  • Utilize WS-I testing tools to confirm your Web services application conforms to WS-I interoperability guidelines.

The Web Services Security specification set provides a complete solution for Federated Identity Management allowing secure and efficient communication and collaboration between organizations and external users. The creation of interoperable solutions based on WS Security standards will further accelerate the adoption of Federated Identity Management and enable customers to implement Web services solutions with reduced implementation cost and risk.

See the following resources for further information:

© 2004 Microsoft Corporation. All rights reserved.

This is a preliminary document and may be changed substantially over time. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

The presentation, distribution or other dissemination of the information contained in this document is not a license, either expressly or impliedly, to any intellectual property owned or controlled by Microsoft and\or any other third party. Microsoft and\or any other third party may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to Microsoft's or any other third party's patents, trademarks, copyrights, or other intellectual property. The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, places, or events is intended or should be inferred.

This document and the information contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, Microsoft provides the document AS IS AND WITH ALL FAULTS, and hereby disclaims all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the document. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS WITH REGARD TO THE DOCUMENT.

IN NO EVENT WILL MICROSOFT BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Microsoft and Microsoft Web Services are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.