SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| Proposed Charter: OASIS Web Services Federation (WSFED) Technical Committee. |
Contents
Update 2007-05: In May 2007, OASIS announced that its members had formed a new committee to advance the WS-Federation specification through the international standards process.
[March 20, 2007] OASIS has acknowledged receipt of a draft TC charter proposal to establish a new Web Services Federation (WSFED) Technical Committee. The TC would accept as input the December 2006 Version 1.1 "WS-Federation" specification as published by BEA Systems Inc., BMC Software, CA Inc., IBM Corporation, Layer 7 Technologies, Microsoft Corporation, Novell Inc., and VeriSign Inc. The purpose of the WSFED TC is to extend basic federation capabilities enabled by other Web service Security specifications (WS-Security, WS-SecureConversation, WS-Trust, WS-SecurityPolicy) to provide advanced federation capabilities. The proposed charter is open for commment through on April 02, 2007.
Representatives from twenty-three companies have provided statements of support of the charter proposal: Active Endpoints, AmberPoint, BEA Systems, BMC, CA, Forum Systems, HP, IBM, IONA, Layer 7 Technologies, Lockheed Martin Corporation, Microsoft, Nortel, Novell, Open Applications Group, Ping Identity, Progress Software, Red Hat, SOA, Tibco, VeriSign, webMethods, and WSO2.
Federation capabilities envisioned by the TC proposers "includes, but is not limited to: structure and acquisition of federation metadata; sign-out notifications; the use of pseudonym and identity mapping services and attribute services in conjunction with Security Token Services; claims-based authorization; and protection of a principal's privacy with respect to claims asserted in security tokens.
In addition, the TC will define an HTTP serialization mechanism allowing the richness of WS-Trust security token based mechanisms for SOAP Web services — brokered trust relationships and distributed authentication and authorization — to be used in browser-based scenarios. This work will be carried out through continued refinement of the Web Services Federation Language Version 1.1 specification.
The "Scope of Work" statement in the proposed TC charter reads in part: "Building on the foundation of WS-Security, WS-SecureConversation, WS-Trust, and WS-SecurityPolicy, a federation protocol should include mechanisms for a Security Token Service to advertise the details of the tokens it can issue (e.g., token and claim types). A federation protocol should also address the relationship of advanced federation services (e.g., Pseudonym services or Authorization services) to baseline Security Token Services. In addition, a federation protocol should describe the message syntax and protocol extensions that participants in a federation must use to communicate with these advanced federation services and the security policy extensions that should be supported for successful interaction with such services."
The principal published deliverable of the proposed TC would be a revised (Version 1.2) Web Services Federation specification, together with associated XML Schemas and WSDL; a Committee Specification is scheduled for
completion within eighteen months of the first TC meeting. These specifications will reflect refinements, corrections or material technological improvements with respect to the input documents and in accordance with the proposed charter.
According to the terms of the draft proposal, the first meeting of the WS-SX TC would be a two day face to face meeting held in Redmond, WA on June 6-7, 2007, sponsored by Microsoft Corporation. This TC would operate under the "RF (Royalty Free) on RAND Terms" IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy. The designated TC Convener is Paul Cotton of Microsoft Corporation.
Web Services Federation Language (WS-Federation). Version 1.1. December 2006. 124 pages. Copyright (©) 2001-2006 BEA Systems, Inc., BMC Software, CA, Inc., International Business Machines Corporation, Layer 7 Technologies, Microsoft Corporation, Inc., Novell, Inc., and VeriSign, Inc.
With XML schemas: federation.xsd, authorization.xsd, privacy.xsd; WSDL: federation.wsdl. XML namespaces: http://schemas.xmlsoap.org/ws/2006/12/federation, http://schemas.xmlsoap.org/ws/2006/12/authorization, http://schemas.xmlsoap.org/ws/2006/12/privacy. ZIP archive, and source.
By: Hal Lockhart (BEA), Steve Andersen (BMC Software), Jeff Bohren (BMC Software), Yakov Sverdlov (CA Inc.), Maryann Hondo (IBM), Hiroshi Maruyama (IBM), Anthony Nadalin - Editor (IBM), Nataraj Nagaratnam (IBM), Toufic Boubez (Layer 7 Technologies Inc.), K Scott Morrison (Layer 7 Technologies, Inc.), Chris Kaler - Editor (Microsoft), Arun Nanda (Microsoft), Don Schmidt (Microsoft), Doug Walters (Microsoft), Hervey Wilson (Microsoft), Lloyd Burch (Novell, Inc.), Doug Earl (Novell, Inc.), Siddharth Baja (VeriSign), Hemma Prafullchandra (VeriSign).
Abstract: "This specification defines mechanisms to allow different security realms to federate, such that authorized access to resources managed in one realm can be provided to security principals whose identities and attributes are managed in other realms. This includes mechanisms for brokering of identity, attribute, authentication and authorization assertions between realms, and privacy of federated claims."
2.1. Federation Basics: "The goal of federation is to allow security principal identities and attributes to be shared across trust boundaries according to established policies. The policies dictate, among other things, formats and options, as well as trusts and privacy/sharing requirements.
In the context of web services the goal is to allow these identities and attributes to be brokered from identity and security token issuers to services and other relying parties without requiring user intervention (unless specified by the underlying policies). This process involves the sharing of federation metadata which describes information about federated services, policies describing common communication requirements, and brokering of trust and tokens via security token exchange (issuances, validation, etc.).
Federations must support a wide variety of configurations and environments. This framework leverages the WS-* specifications to create an evolutionary federation path allowing services to use only what they need and leverage existing infrastructures and investments.
Federations can exist within organizations and companies as well as across organizations and companies. They can also be ad-hoc collections of principals that choose to participate in a community...
Web Services Federation Language (WS-Federation). DRAFT. Version 1.0. July 8 2003. 41 pages. With XML Schema and WSDL. Copyright (©) BEA, IBM, Microsoft, RSA Security, and VeriSign. WS-Federation: Active Requestor Profile. Version 1.0. July 8, 2003. 18 pages. See: http://schemas.xmlsoap.org/ws/2006/12/federation/, Superseded Versions, Published July 2003. WS-Federation: Passive Requestor Profile. Version 1.0. July 8, 2003. 32 pages. See: http://schemas.xmlsoap.org/ws/2006/12/federation/, Superseded Versions, Published July 2003.
Official copies of Web Services Federation Language (WS-Federation) Version 1.1 and Version 1.0 are available from the corporate authors' web sites, including:
Comments on the Proposed Charter were sent to the oasis-charter-discuss list in the 2007-03 and 2007-04 timeframe. On 2007-04-05, a compilation of all comments [source] was prepared by Paul Cotton (WSFED TC Convener) and posted to the list: "To help with the WSFED TC pre-launch teleconference, I have organized all of the comments on the charter into a single document..." Response to the comment set was provided by the TC Proposers in the teleconference of 2007-04-05. See the 2007-04-11 Comment Resolution Log for the proposed Web Services Federation TC Charter [source PDF, posting].
The complete text of the "Proposed Charter for OASIS Web Services Federation (WSFED) TC" is available online, containing the following information:
Federation Model
The basic goal of federation is to facilitate the sharing of security principal
attributes across trust boundaries to establish a security context (or a
federation context) for that principal which a relying party can use to
grant/deny access to a resource. Establishing a federation context when
Identity and Resource Providers operate in different realms requires agreement
on what attributes are required and frequently requires agreement on mechanisms
for securely transporting those attributes over unprotected networks. It is
necessary for participants in a federation to communicate these requirements
over a wide variety of trust and communication topologies. This requires the
exchange of metadata describing endpoint references where services may be
obtained, plus the security policies and communication requirements that must
be observed when accessing those endpoints. The exchange of this metadata is
further complicated because the participants in a single federation may have
different policies and service providers may participate in multiple
federations.
Federation Metadata
Organizations typically decide to federate based on business or legal
relationships. After a federation has been created, the participants must
publish and exchange configuration information (i.e., federation metadata) that
allows them to identify the services exposed to participants in the federation
and the policies for accessing them. For Web services, this information can be
expressed as statements in federation metadata documents and may include
endpoint references (EPRs) and security policies which list the security tokens
and claims required to access those end points. A mechanism must be
established for determining the authenticity of metadata documents. Since a
service may be exposed in multiple federations it must be possible to identify
the metadata that applies to each distinct context. In addition, it is
desirable to help automate this configuration process.
Federated Sign-Out
The purpose of federated sign-out is to cause federation participants to clean
up any cached state or security tokens for a principal that are no longer
required because the principal's session is being terminated. Federated sign-out is different than token cancellation as defined in WS-Trust [4] since federated sign-out applies to all tokens and all target sites for the principal
within the federation.
Attribute Services
The participants in a federation may not always be able to establish a
federation context for a principal using only the claims obtained from security
tokens. For example, after a principal's original request has been
authenticated a Resource Provider may determine that additional information is
required to authorize access to advanced functionality. A service provider can
address this situation by operating an attribute service that requesters may
use to obtain this additional information.
Pseudonym Services
A pseudonym service is a special type of attribute service which provides
alternate identity information for principals. It may provide distinct
pseudonyms for different scopes, that is, for access to different Resource
Providers. A pseudonym service may maintain and provide security tokens for
access to different scopes.
Security Tokens and Pseudonyms
A pseudonym service can store tokens associated with a pseudonyms to simplify
retrieving a pseudonym and associated tokens in a single security token
request.
Federation Extensions to WS-Trust
Interactions between participants in a federation may be facilitated by some
general purpose extensions to the token exchange mechanisms defined in WS-Trust [4].
Authorization
An authorization service is a special type of Security Token Service which
provides decision brokering services for participants in a federation. While
the internal processing of an authorization service is implementation specific,
interoperability requires development of a common model for interacting with
authorization services, and extensions to RST/RSTR mechanisms, as defined in
WS-Trust [4], for communicating request and policy inputs and decision outputs.
Indicating Specific Policy/Metadata
When a requestor attempts to access a target service there may be additional
security or contextual requirements based on the specifics of the request. A
mechanism allowing the target service to indicate that additional security
semantics apply to the request is required, enabling the requestor to
reconstruct the request and try again.
Authentication Types
The WS-Trust [4] specification defines the AuthenticationType parameter to
indicate the type of authentication required (or performed) with respect to a
particular security token request. However, no particular types are defined or
required. To facilitate federations, it is useful to establish some optional
pre-defined authentication types.
Privacy
Requests made to service providers for security tokens or authorization
decisions may include information that is subject to personal or organizational
privacy requirements. It is necessary to provide mechanisms for requestors to
indicate any restrictions on the use and distribution of such sensitive
information, including its disclosure in security tokens they request.
Web (passive) Requestors
For Web services the sections above describe extensions to WS-Trust [4] for
brokering trust and exposing and consuming services between the participants of
a federation. Web browser requestors typically cannot directly issue SOAP
requests. Consequently, syntax is required for expressing the WS-Trust [4]
protocol and federation extensions in a browser-only environment using widely
supported HTTP 1.1 mechanisms (GET, POST, redirects, and cookies).
Additional Policy Assertions
This work will focus on defining policy assertions enabling participants in a
federation to advertise support for federation protocols and features described
above.
General Notes on Scope
The output specifications will uphold the basic principles of other Web
services specifications of independence and composition and be composable with
the other specifications in the Web services architecture, such as the
specifications listed in the References section, numbers 1-18, 24-26. The TC
may also take into consideration the following specifications/works listed in
the References section, numbers 19-22, 24-27.
If any of the above specifications is outside of a standardization process at
the time this TC moves to ratify its deliverables, or is not far enough along
in the standardization process, any normative references to it in the TC output
will be expressed in an abstract manner, and the incarnation will be left at
that time as an exercise in interoperability.
While composition with other specifications is a goal of the TC, it is also a
goal to leave the specifics of how that composition is achieved outside the
scope of this TC.
Each of the protocol elements will use implementation and language neutral XML
formats defined in XML Schema [23].
Out of Scope
The following is a non-exhaustive list. It is provided only for the sake of
clarity. If some function, mechanism or feature is not mentioned here, and it
is not mentioned in the Scope of Work section either, then it will be deemed to
be out of scope.
The TC will not define a mapping of the functions and elements described in the
specifications to any programming language, to any particular messaging
middleware, nor to specific network transports.
The following items are specifically out of scope of the work of the TC:
1. Definition and management of trust policy expressions (that is, statements
about who is trusted to make what claims about an entity); these are different
from the in-scope "Policy assertions" referred to in the Scope of Work section
above.
2. Mechanisms and protocols for establishing federations beyond those described
in the input document.
3. Definition of specific authorization context data used in federation
extensions to WS-Trust [4].
4. Definition of specific claim types represented using common claims dialect
extensions described in the Authorization section above.
5. Specific contents of shared domain cookies used in home realm discovery and
mechanisms used to obtain them.
6. Definition of claim types carried in privacy parameters as described in the
Privacy section above.
7. Definition of the form and content of privacy statements.
8. Token revocation notifications and revocation management (e.g., via CRLs).
9. Schemas for specific tokens issued, renewed, cancelled or validated as part of the trust process.
10. The establishment of trust between two or more business parties.
11. Definition of new key derivation algorithms.
12. Definition or description of the contents and use of status messages in response to sign-out messages.
13. Definition or description of a specific type of attribute service or a
specific data organization or repository for implementing an attribute service
or the protocol for accessing such a service.
14. Definition or description of the types or contents of attribute data
elements to be provided by an attribute service.
15. Definition or description of an interface or protocol for communicating
with an attribute service.
16. Definition or description of a specific data organization or repository for
implementing a pseudonym service.
17. Definition of additional negotiation and challenge protocol mechanisms
18. Developing the roadmaps [21], [22] or other specifications mentioned in
those roadmaps, beyond the material listed explicitly as within the scope of this charter.
The TC will not attempt to define concepts or renderings for functions that are
of wider applicability including but not limited to:
- Addressing
- Policy language frameworks and attachment mechanisms
- Routing
- Reliable message exchange
- Transactions and compensation
- Trust
- Secure Conversations
- Metadata Exchange
- Resource Transfer
Where required these functions are achieved by composition with other Web services specifications.
The TC will not attempt to define functionality duplicating that of any
normatively referenced specification in the input WS-Federation Version 1.1
[1]. If the referenced specification is outside of a standardization process at
the time this TC moves to ratify its deliverables, or is not far along enough
in the standardization process, any normative references to it in the TC output
will be expressed in an abstract manner, and the incarnation will be left at
that time as an exercise in interoperability.
As the specifications developed by the WSFED TC are part of the Web services
Architecture, and must work well with other specifications within that
architecture, the following work may be relevant to this WSFED TC:
Similar Work
The specifications developed by the WSFED TC address functionality required for
Web services that is not addressed in other security related activities. The
WSFED TC will be informed by the following:
- Internet X.509 Public Key Infrastructure Qualified Certificates Profile [28]
- ITU-T Recommendation X.509 [28]
- The Kerberos Network Authentication Service [29] from IETF
- Security Requirements for Cryptographic Modules [30], from NIST
- Security Assertion Markup Language (SAML) [32] from OASIS
- The Liberty Identity Web Services Framework (ID-WSF) [33], [34]
The proposers of this TC recognize there are other possible approaches to
federation and believe that the defined Scope of Work of this TC addresses
many functional use cases of these parallel efforts. The proposers of this TC
seek involvement from authors of other such activities and the contribution of
their expertise and experience, and intend to work in harmony with them in the
creation of the product of this technical committee.
Applicable Work
- OASIS Web Services Security (WSS) TC. The WSFED TC will ensure that its specifications compose with the WSS TC specifications.
- OASIS Web Services Secure Exchange (WS-SX) TC. The WSFED TC will ensure that its specifications compose with the WS-SX TC specifications.
- W3C WS-Policy Working Group. The WSFED TC will ensure that its specifications compose with the W3C WS-Policy Working Group specifications.
The TC may decide to establish liaisons with other groups as needed. Responsibilities for such liaison will be defined by the TC at that time.
The following eligible individuals are in support of this proposal:
- Don Adams, Tibco, dadams@tibco.com
- Steve Anderson, BMC, steve.anderson@bmc.com
- Siddharth Bajaj, VeriSign, sbajaj@verisign.com
- Abbie Barbir, Nortel, abbieb@nortel.com
- Hanane Becha, Nortel, HANANEBE@nortel.com
- Jeff Bohren, BMC, jeff.bohren@bmc.com
- Toufic Boubez, Layer 7 Technologies, tboubez@layer7tech.com
- Lloyd Burch, Novell, lburch@novell.com
- Greg Carpenter, Microsoft, gregcarp@microsoft.com
- Marco Carugi, Nortel, marco.carugi@nortel.com
- David M. Connelly, Open Applications Group, dconnelly@openapplications.org
- Paul Cotton, Microsoft, pcotton@microsoft.com
- Glen Daniels, Progress Software, gdaniels@progress.com
- Doug Earl, Novell, dearl@novell.com
- Alistair Farquharson , SOA, alistair.farquharson@soa.com
- Marc Goodner, Microsoft, mgoodner@microsoft.com
- Tony Gullotta, SOA, tony.gullotta@soa.com
- Phillip Hallam-Baker, VeriSign, pbaker@verisign.com
- Patrick Harding, Ping Identity, pharding@pingidentity.com
- Mike Kaiser, IBM, mkaiser@us.ibm.com
- Chris Kaler, Microsoft, ckaler@microsoft.com
- Dana Kaufman, Forum Systems, dkaufman@forumsys.com
- Paul Knight, Nortel, paul.knight@nortel.com
- Hal Lockhart, BEA Systems, hlockhar@bea.com
- Jim Hosmer, Lockheed Martin Corporation, james.b.hosmer@lmco.com
- Kelvin Lawrence, IBM, klawrenc@us.ibm.com
- Mark Little, Red Hat, mark.little@jboss.com
- Michael McIntosh, IBM, mikemci@us.ibm.com
- Jonathan Marsh, WSO2, jonathan@wso2.com
- K Scott Morrison, Layer 7 Technologies, Inc., smorrison@layer7tech.com
- Anthony Nadalin, IBM drsecure@us.ibm.com
- Eric Newcomer, IONA, Eric.Newcomer@iona.com
- Kim Pease, Active Endpoints, kim.pease@active-endpoints.com
- Jason Rouault, HP, jason.rouault@hp.com
- Don Schmidt, Microsoft, donsch@microsoft.com
- Sameer Sharma, Lockheed Martin Corporation, sameer.sharma@lmco.com
- Yakov Sverdlov, CA, Yakov.Sverdlov@ca.com
- Gene Thurston, AmberPoint, gthurston@amberpoint.com
- Greg Whitehead, HP, greg.whitehead@hp.com
- Prasad Yendluri, webMethods, prasad.yendluri@webmethods.com
A few background documents and projects related to WS-Federation are provided here. See also the TC's listing of Related Work. Examples:
"Federated Identity Management Interoperability." Microsoft Corporation. May 2004. "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." Federation of Identities in a Web Services World. IBM and Microsoft Joint White Paper. July 8, 2003, Version 1.0. 19 pages. PDF format. Active Directory Federation Services, and "Simplify Single Sign-on Using ADFS." Microsoft: Federation and Issued Tokens. "With Windows Communication Foundation (WCF), you can create clients that communicate securely with services that implement the WS-Federation and WS-Trust specifications. The specifications use XML, SOAP, and WSDL to provide mechanisms that enable authentication and authorization across different trust realms." Tivoli Federated Identity Manager. "Companies that choose to collaborate in identity-based business processes may benefit from Tivoli Federated Identity Manager's ability to help... align with open standards and specifications including Liberty, SAML, WS-Federation, WS-Security and WS-Trust. WS-Federation for Apache 2.0 Toolkit. Overview: "The WS-Federation for Apache 2.0 Toolkit is an open source module that extends Microsoft's Active Directory Federation Services (ADFS) and WS-Federation to provide Web single sign-on (SSO) for Apache Web applications written in Java, Perl and PHP." From SourceID (PingIdentity 'Open Source Federated Identity Management'). OpenSSO Open Federation. "Open Federation is an open source project based on the identity federation and web services framework developed for Sun Java System Access Manager and Sun Java System Federation Manager. Open Federation provides an extensible framework to support these feature... Standards are implemented by Open Federation: Liberty Alliance Project Identity Federation Framework (Liberty ID-FF) v.1.1 and v.1.2 — including identity provider and service provider extended profiles; Liberty Alliance Project Identity Web Services Framework (Liberty ID-WSF) v.1.0 and v.1.1; Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) v.1.0 and v.1.1; OASIS SAML v.2.0 — Operational modes: IdP and SP Complete. The following will be supported in future releases: Liberty ID-WSF v.2.0; WS-Federation Passive Requestor Profile; Web Services Interoperability (WS-I) Basic Security Profile (BSP)
[Incomplete: TBD]
[April 4, 2007] "WS-Federation TC Roundup and Thoughts." By Eve Maler. In Pushing String (Blog). April 4, 2007. "A proposal for a new OASIS Technical Committee called WSFED was submitted on March 19 [2007] for the 'continued refinement' of WS-Federation V1.1. Following OASIS process rules, a period of public comment was held; you can see the official comments in the mailing list archives... Some previous analysis of WS-Federation with respect to SAML, on a fairly detailed technical level, can be found on Hubert's blog. Elsewhere he notes an analysis done by the Danish government at a higher business and technical level, ultimately motivating their selection of SAML V2.0. (A couple of previous posts of mine about SAML2 usage in the public sector put additional meat on the bones of this sort of analysis.) I'm proud to have been involved in a number of successful convergence activities. In a way, any standards effort that codifies current practice has a strong element of convergence or boiling down, but when it's an explicit effort to make there be fewer stacks in the world so that usage and deployment can surge forward, it's really something cool. SAML V1.0 itself converged the S2ML and AuthXML camps. SAML V2.0 converged the SAML V1.x, Shibboleth profile, and Liberty ID-FF streams. It's not easy to do, and even when the parties are very friendly towards each other, there are challenges. But first, the lightbulb has to want to change. I can think of a number of activities that could promote convergence. To give deployers of federated identity technologies the best confidence that the results will be useful and interoperable, I personally think that a program of profile, extension, and/or binding definition activities in the Security Services (SAML) TC is the ideal way to go — it comes with long expertise, lots of existence proofs, and even an interoperability certification program run by the Liberty Alliance. But any joint effort that gets the parties committed to addressing overlaps in a standards body would be helpful..." [April 04, 2006] "Proposed WSFED Technical Committee: Divergence Point for Federation?" By Gerry Gebel (Burton Group). April 04, 2007. "The March 20 announcement proposing a charter for a new OASIS Technical Committee for WS-Federation is rekindling a fire that has been smoldering for some time. Many a debate occurred at Catalyst and in other forums as to the merits of the WS-* long-term vision for web services security vs. SAML's immediate focus on browser-based federation scenarios. A common theme to these debates was a call for convergence of SAML, Liberty Alliance, and WS-Federation efforts. Meanwhile, vendors staked out positions regarding SAML, WS-Federation, and Liberty Alliance. Microsoft has held its ground in withholding support for the SAML protocol. IBM straddled the fence after initial reluctance to support Liberty ID-FF, ultimately supporting standards and specifications as demanded by customers. Most other vendors in the federation space hedged their bets by grudgingly supporting multiple protocols and specifications... Nearly two years ago, Burton Group published a report titled 'SAML 2.0: Convergence Point for Browser-Based Federation.' It contained the following statements, 'Security Assertion Markup Language (SAML) 2.0 represents a watershed moment for federation standards because it combines the efforts and features of SAML 1.x, Liberty Alliance Identity Federation Framework (IDFF), and Shibboleth' and 'OASIS may also attempt to foster more convergence for browser-based federation by working with the supporters of WS-Federation passive profile (WF-PP).' Obviously, this is not the case. Several have commented on the TC proposal, including Nokia, France Telecom, NTT, Sun, Oracle, and Neustar. In addition, Tim Bray posted a rip on his blog. The WSFED charter gives lip service to working on convergence with SAML 2.0. Like other commenters, we find this less than convincing; the WSFED charter's invitation to other standards committees looks like a passive-aggressive maneuver. It puts the onus on SAML 2.0, which has already been standardized, to come to WSFED on their terms and make changes to an established standard to accommodate features of a specification which was not developed in an open forum and is not yet a standard..." [March 05, 2007] Software Design Document: WS-Federation Support. OpenSSO. Version 0.1 (Draft). By Pat Patterson (Sun Microsystems). Please send comments to dev@opensso.dev.java.net. Issued under Common Development And Distribution License (CDDL) Version 1.0. Copyright © 2007 Sun Microsystems. This document contains a high-level design for WS-Federation support in OpenSSO. The high-level design of WS-Federation is included, that is, the gross structure of the proposed implementation, down to the method level. Design of individual methods is not included. This document should be read in the context of the OpenSSO WS-Federation Software Requirements Specification (SRS) [Software Requirement Specification: WS-Federation Support, February 13, 2007 or later; the document describes the requirements for WS-Federation cross-domain single sign-on and single log-out in OpenSSO/Open Federation]. See the posting, and blog Development in the Open II - OpenSSO WS-Federation SDD. [March 03, 2007] "Deep-dive on SAML 2.0 vs WS-Federation. By James McGovern. "Hubert A. Le Van Gong and Pat Patterson have recently chimed in on a comparison between SAML 2.0 and WS-Federation but of course left out some very important considerations... Consider if you are an Enterprise Architect for a large enterprise and wanted to establish a federation with another large enterprise. You would probably consider SAML 2.0 as neither enterprise would really be constrained in terms of costs in buying software that supports it. If software in this space costs say $100K, then if the business value in doing so exists, both parties could make this happen. Now ask yourself the same exact question where you are still the same Enterprise Architect for a large enterprise but only you want to establish a federation with hundreds if not thousands of small businesses where their company may only have a total of four or five employees on average... if Enterprise Architects stop being enterprisey, they may even realize that the solution that works for the small guys will also work for the large ones. WS-Federation support is built into the Windows operating system which is pervasively deployed. How difficult would it be to find a Fortune 500 enterprise with Windows installed? No effort required as it has 100% penetration..." [March 02, 2007] "Deep-dive on SAML 2.0 vs. WS-Federation." By Hubert A. Le Van Gong (Sun Microsystems). "After my previous blog entries on WS-Federation I received some requests for a more in-depth analysis of WS-Federation and in particular how it compares to SAML 2.0. It took me a while to get to it but I finally manage to spend some time to do just that. Below is a table where I compare both specs on various features and technical details. Note that each blue highlight identifies what I think is a plus for the specification (when compared to the other)... " [December 22, 2006] "SAML vs. WS-Federation." By Hubert A. Le Van Gong (Sun Microsystems). "Following my recent post on the (very) quiet publication of W-Federation, I was pointed at this excellent document that compares SAML and WS-Federation and explains why SAML is a better choice. This document is even more remarkable when one notices that it has been written by people working for the Government of Denmark obviously an impartial third party...." See comment from James McGovern. [December 20, 2006] "WS-Federation version 1.1 is out, 3 years after..." By Hubert A. Le Van Gong (Sun Microsystems). "So, it seems Microsoft, IBM & al. have decided to release a new version of WS-Federation, more than three years after their first version. I've done a quick read on it and listed some of the most noticeable changes below: (1) Structurally there is now only one document. The passive, active and various interoperability profiles have all been combined in this single document. I tend to think this is a good thing since all these profiles were certainly creating confusion. IMHO they were also showing a certain lack of testing before the first publication hence leading to the need for additional interoperability profiles (but I'm being controversial here...). (2) All the protocols have been combined in a single big section (13) (3) The focus seems to be more on the active requestor rather than the passive profile which is mainly addressed in section 13.6 There are some new features in this spec too: [i] Federation metadata: with the concept of context to describe the fact of belonging to one or more federation (what SAML or Liberty Alliance calls Circle of Trust (CoT)) [ii] Authorization service & Pseudonym service: these are basically specialized versions of an STS in order to be able to include either attributes or pseudonyms along with the token that's being issued..."
On May 02, 2007, OASIS announced that members of the consortium had "formed a new committee to advance the WS-Federation specification through the international standards process. WS-Federation aims to extend the scope of identity management, enabling federations of trust. Version 1.1 of the specification, which was created by a cooperative of eight companies, will be contributed to the new OASIS WS-Federation Technical Committee for advancement and input from the broader community. The OASIS WS-Federation Technical Committee will work to simplify interactions between the participants of a federation. The group will advance capabilities for structuring and acquiring federation metadata, sign-out notifications, and the use of pseudonym and identity mapping and attribute services. In addition, the Committee will enable brokered trust relationships and distributed authentication and authorization to be used in browser-based scenarios. The WS-Federation Technical Committee will operate under the Royalty Free on RAND Terms mode, as defined by the OASIS Intellectual Property Rights Policy. Paul Cotton of Microsoft, convener of the OASIS WS-Federation Technical Committee: "Organizations and business partners will be able to collaborate more safely and smoothly with WS-Federation. Today, it often takes weeks for a company to set up user accounts and access privileges to enable their partner organizations' staff to safely gain access to shared materials. When a project is complete, all that time and effort must be repeated in order to revoke the partner's accounts. WS-Federation allows user accounts to continue to be owned, stored, and managed by the users' companies, and shared as needed with partner organizations, instead of relinquishing control to them or creating duplicate copies."
Proposed Charter for OASIS Web Services Federation (WSFED) TC [June 07, 2007] WS-Federation Contribution to OASIS WSFED TC. With file listing. See the posting from Paul Cotton (Microsoft). Also from BEA, IBM, BMC, CA, Novell, Layer 7, and VeriSign. [document as uploaded to WSFED document repository] [May 28, 2007] Understanding WS-Federation. Version 1.0. Authors: Marc Goodner (Microsoft Corporation), Maryann Hondo (IBM), Anthony Nadalin (IBM), Michael McIntosh (IBM), Don Schmidt (Microsoft Corporation). White Paper. May 28, 2007. 49 pages. Copyright © 2007 International Business Machines Corporation, and Microsoft Corporation, Inc. Presented at the initial WSFED TC F2F Meeting 2007-06: "On the first day of the TC meeting Marc Goodner presented the 'Understanding WS Federation' slide deck. This session walked members through key features of WS-Federation using examples from the whitepaper, an Enterprise 'request for proposal' scenario and a Healthcare 'emergency room treatment' scenario." See also: (1) the associated slide deck 'Specification Features in Selected Application Scenarios'; (2) WS-Federation 1.1 Overview. "This paper is intended to help the reader understand the features of WS-Federation by describing the use of the specification in selected application scenarios. WS-Federation extends WS-Trust to provide a flexible Federated Identity architecture with clean separation between trust mechanisms, security token formats, and the protocol for obtaining tokens. This architecture enables a reusable security token service model and protocol to address the identity requirements of both web applications and web services in a variety of trust relationships. The features of WS-Federation can be used directly by SOAP clients and web services. WS-Federation also defines syntax for expressing the WS-Trust protocol and WS-Federation extensions in a browser based environment. The intention of this functionality is to provide a common model for performing Federated Identity operations for both web services and browser-based applications. The paper briefly reviews WS-Trust and then describes how WS-Federation builds upon the Security Token Service model defined in that standard. A basic overview of the features of WS-Federation is provided. Key concepts are explained by examples of usage in application scenarios... WS-Federation includes mechanisms for brokering of identity, attribute discovery and retrieval, authentication and authorization claims between federation partners, and protecting the privacy of these claims across organizational boundaries. These mechanisms are defined as extensions to the Security Token Service (STS) model defined in WS-Trust. In addition WS-Federation defines a mapping of these mechanisms, and the WS-Trust token issuance messages, onto HTTP such that WS-Federation can be leveraged within Web browser environments. The intention is to provide a common infrastructure for performing Federated Identity operations for both web services and browser-based applications. A common protocol provides economies with regard to development, testing, deployment and maintenance for vendors and customers alike..." [source PDF] [June 06, 2007] Understanding WS-Federation: Specification Features in Selected Application Scenarios. 27 slides. This slide deck corresponds to the Presentation: WS-Federation Part One: Understanding WS-Federation. Presented at the initial WSFED TC F2F Meeting 2007-06 (see above). Covers: (1) WS-Trust and WS-Federation Fundamentals; (2) Enterprise Scenario 'Request for Proposal'; (3) Healthcare Scenario 'Patient Record Access'. WS-Trust defines a Security Token Service (STS) model for security tokens, including: Requesting, Issuing, Renewing, Cancelling, Validating. It is token type agnostic. WS-Federation enables richer trust relationships. It allows authorized access to resources in one realm provided to security principles managed in another It defines mechanisms as extensions to WS-Trust for: Brokering of identity, Attribute discovery and retrieval, Authentication and authorization claims between federation partners, Protection of the privacy of claims across organizational boundaries. WS-Federation provides for mapping of the above, and WS-Trust token issuance messages, onto HTTP for web browser clients.." [source PDF] [June 06, 2007] WS-Federation 1.1 Overview. OASIS WSFED TC Inaugural Meeting, June 6-7, 2007. 68 slides. Presented at the initial WSFED TC F2F Meeting 2007-06: "On the second day, Anthony Nadalin and Don Schmidt presented the 'WS-Federation Overview' slide deck. This session explored how WS-Federation extends WS-Trust and reviewed almost all of the normative components of the WS-Federation 1.1 specification." Covers: Introduction; WS-Trust extensions for federations; STS service model extensibility; Federation metadata; Federated sign-out and Web requestors; Summary. [source PDF] Web Services Federation Language (WS-Federation) XML namespace document: http://schemas.xmlsoap.org/ws/2006/12/federation Public archive for comments on the proposed TC Charter
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
