Contents
- Overview
- Publication Highlights
- Principal References
- Related Activity
- News, Specifications, Articles, Commentary
Overview
"SAML, developed by the Security Services Technical Committee of OASIS, is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. Federation is the dominant movement in identity management today. Federation refers to the establishment of some or all of business agreements, cryptographic trust, and user identifiers or attributes across security and policy domains to enable more seamless cross-domain business interactions. As Web services promise to enable integration between business partners through loose coupling at the application and messaging layer, federation does so at the identity management layer — insulating each domain from the details of the others' authentication and authorization infrastructure. Key to this loose coupling at the identity management layer are standardized mechanisms and formats for the communication of identity information between the domains — the standard provides the insulating buffer. SAML defines just such a standard." [FAQ 2006]
May 2003 CS Overview: The Security Assertion Markup Language (SAML) is being developed by the OASIS XML-Based Security Services Technical Committee (SSTC). The Security Assertion Markup Language (SAML) is "an XML-based framework for exchanging security information. This security information is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain. A typical example of a subject is a person, identified by his or her email address in a particular Internet DNS domain. Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources. Assertions are represented as XML constructs and have a nested structure, whereby a single assertion might contain several different internal statements about authentication, authorization, and attributes. Note that assertions containing authentication statements merely describe acts of authentication that happened previously. Assertions are issued by SAML authorities, namely, authentication authorities, attribute authorities, and policy decision points. SAML defines a protocol by which clients can request assertions from SAML authorities and get a response from them. This protocol, consisting of XML-based request and response message formats, can be bound to many different underlying communications and transport protocols; SAML currently defines one binding, to SOAP over HTTP. SAML authorities can use various sources of information, such as external policy stores and assertions that were received as input in requests, in creating their responses. Thus, while clients always consume assertions, SAML authorities can be both producers and consumers of assertions."
Why SAML?
Why is SAML required? There are four 'drivers' behind the creation of the SAML standard:
- Limitations of Browser cookies: Most existing Single-Sign On products use browser cookies to maintain state so that re-authentication is not required. Browser cookies are not transferred between DNS domains. So, if you obtain a cookie from www.abc.com, then that cookie will not be sent in any HTTP messages to www.xyz.com. This could even apply within an organization that has separate DNS domains. Therefore, to solve the Cross-Domain SSO (CDSSO) problem requires the application of different technology. All SSO products solve the CDSSO problem by different techniques.
- SSO Interoperability: How products implement SSO and CDSSO are completely proprietary. If you are an organization and you want to perform SSO across different DNS domains within the same organization or you want to perform CDSSO to trading partners, then you will have to use the same SSO product in all the domains.
- Web Services: Security within Web Services is still being defined. Most of the focus has been on how to provide confidentiality and authentication/integrity services on an end-to-end basis. The SAML standard provides the means by which authentication and authorization assertions can exchanged between communicating parties.
- Federation: The need to simplify identity management across organizational boundaries, allowing users to consolidate many local identities into a single (or at least a reduced set) Federated Identity..." [excerpted from the Security Assertion Markup Language (SAML) 2.0 Technical Overview, Working Draft 01 22-July-2004.]
Publication Highlights
In September 2003, OASIS announced the membership approval of SAML Version 1.1 as an OASIS Standard. See the text of the announcement in: "Security Assertion Markup Language (SAML) Version 1.1 Ratified as OASIS Standard. Baltimore Technologies, BEA Systems, Computer Associates, Entrust, Hewlett-Packard, Netegrity, Oblix, OpenNetwork, Reactivity, RSA Security, SAP, Sun Microsystems, Verisign, and Others Collaborate on Authentication and Authorization."
[June 22, 2001] Security Assertion Markup Language (SAML) is an "XML security standard for exchanging authentication and authorization information." SAML is being developed within the OASIS XML-Based Security Services Technical Committee (SSTC).
[June 22, 2001] SSTC Charter: "The purpose of the XML-Based Security Services TC (SSTC) is to define an XML framework for exchanging authentication and authorization information. The TC will produce set of one or more Committee Specifications that cover use cases and requirements, core assertions, protocols, bindings, and a conformance suite, all of the aforementioned to be examined with respect to security considerations. The work will take the S2ML specification and the intended submission of AuthXML, along with any other relevant and timely submissions, into consideration. The goal (subject to revision) is to publish a substantially complete set of Committee Specifications by 1 June 2001, and submit a Committee Specification to the OASIS membership for its approval by 1 September 2001... The TC has agreed to call its specification Security Assertion Markup Language (SAML, pronounced 'sam-l').
From the Version 0.9 "Security Assertions Markup Language. Core Assertion Architecture" document: "This document contains two sections. Section 1 contains the text proposed by the Core Assertions and Protocol group for the Core Assertions section of the SAML. Section 2 contains references to the material cited in the text. SAML specifies several different types of assertion for different purposes, these are: (1) Authentication Assertion: An authentication assertion asserts that the issuer has authenticated the specified subject. (2) Attribute Assertion: An attribute assertion asserts that the specified subject has the specified attribute(s). Attributes may be specified by means of a URI or through an extension schema that defines structured attributes. (3) Decision Assertion: A decision assertion reports the result of the specified authorization request. (4) Authorization Assertion: An authorization assertion asserts that a subject has been granted specific permissions to access one or more resources. The different types of SAML assertion are encoded in a common XML package, which at a minimum consists of: (1) Basic Information: Each assertion must specify a unique identifier that serves as a name for the assertion. In addition an assertion may specify the date and time of issue and the time interval for which the assertion is valid. (2) Claims: The claims made by the assertion. This document describes the use of assertions to make claims for Authorization and Key Delegation applications. In addition an assertion may contain the following additional elements. An SAML client is not required to support processing of any element contained in an additional element with the sole exception that an SAML client must reject any assertion containing a 'Conditions' element that is not supported. (3) Conditions: The assertion status may be subject to conditions. The status of the assertion might be dependent on additional information from a validation service. The assertion may be dependent on other assertions being valid. The assertion may only be valid if the relying party is a member of a particular audience. (4) Advice: Assertions may contain additional information as advice. The advice element may be used to specify the assertions that were used to make a policy decision. The SAML assertion package is designed to facilitate reuse in other specifications. For this reason XML elements specific to the management of authentication and authorization data are expressed as claims. Possible additional applications of the assertion package format include management of embedded trust roots [XTASS] and authorization policy information [XACML]..."
Principal References
SSTC Resources:
- "XML and Security": General references
- OASIS Security Services (SAML) TC web site
- SSTC FAQ document. "This document helps to answer frequently asked questions about SAML (Security Assertion Markup Language)."
- SSTC IPR declarations
- SSTC TC comment list archive
- SAML document archive. See this listing for the most recent document version URLs.
- Security Assertion Markup Language (SAML) 2.0 Technical Overview. February 20, 2005. [source PDF]
- SAML Executive Overview. Produced by the OASIS Security Services TC. Revised Version 2.0 Draft. March 10, 2005. [source PDF]
- SAML Implementation Guidelines. August 27, 2004. [source PDF]
- SAML 2.0 files, available from the OASIS Open Library
Mailing list archives:
- SAML-DEV mailing list archives
- 'security-use' list. Use Cases and Requirements
- 'security-services' list. Main Focus Subcommittee work.
- 'security-bindings' list. Bindings subcommittee.
- 'security-conform' list. Conformance subcommittee
- 'security-consider' list. Security and Privacy Considerations
Related Activity
- Security, Privacy, and Personalization
- Liberty Alliance Specifications for Federated Network Identification and Authorization
- Extensible Access Control Markup Language (XACML). See the announcement.
- XML and Encryption
- XML Digital Signature (IETF/W3C)
- XML Key Management Specification (XKMS)
- Security Services Markup Language (S2ML)
- XML Access Control Language (XACL)
- AuthXML Standard for Web Security
- Intrusion Detection Message Exchange Format
- Blocks eXtensible eXchange Protocol Framework (BEEP)
- Shibboleth
News, Specifications, Articles, Commentary
[April 23, 2008] "Internet2 Community Releases Shibboleth Version 2.0. New Major Release of Open Source Federated Authentication Suite Provides Enhanced Functionality, Enables More Seamless Installation and Operation." Announcement 2008-04-21. "Internet2 today announced that it has released Shibboleth 2.0, the latest major version of the most widely-deployed federated authentication implementation. Developed by the Internet2 community and its partners around the world, the latest release greatly enhances several key elements of Shibboleth in an effort to ensure interoperability with other commercial and open-source federated identity solutions; to improve personalization and security; as well as to ease installation, management and operation processes. The goal is to provide a more robust and interoperable platform that will help catalyze the worldwide growth of higher education and research federations like the InCommon Federation which serves the U.S. higher education sector and provides a framework for participating organizations to collaborate and share resources using Shibboleth technology... Shibboleth 2.0 adds an open source implementation of the OASIS SAML 2.0 standard to the suite of protocol implementations available in previous releases. The software provides a secure, single-sign on mechanism for institutions to enable their users to access protected online resources within their campuses and from their external service provider partners while at the same time protecting individual user privacy. Shibboleth leverages an institution's login and directory systems to authenticate users at their home institution (or "identity provider") and then passes only the relevant information, or "attributes," to the service provider to enable the user access to its online resources. Attributes can include a wide range of information that characterize the user, e.g. identity, permissions at the service provider, employee or student status at the university, class enrollment, age, graduating class, etc. The service provider and institution make agreements on which attributes are needed to make that user eligible to access specific resources. Shibboleth 2.0 enhances the ability for identity providers to use and manage "anonymous identifiers" to protect user privacy but still allow for personalization. The identity provider assigns a persistent unique identifier to a specific user which allows service providers to tailor and improve services based on the needs of that user without knowing their specific identity. For instance, a medical student searching for articles on a specific disease or treatment via an online medical journal could save his or her searches using the anonymous identifier and then build on their research over time. For the user, this is a transparent process; no knowledge of the identifier is needed..."
[February 27, 2008] "Holder-of-Key Web Browser SSO Profile." Edited by Nathan (Nate) Klingenstein (Internet2). Status: Working Draft 01. Date: 27-February-2008. A SAML TC 'Post-V2.0 Working Document'. 16 pages. Posted to the SAML TC document repository. Editor's note: "As part of my work for the National Institute of Informatics and the UPKI initiative, I've been working on a modified Web Browser SSO profile for SAML 2.0 that uses holder-of-key confirmation for the client rather than bearer authentication. The keys for this confirmation are supplied through TLS using client certificates. This results in a more secure sign-on process and, particularly, a more secure resulting session at the SP. There is no need for the SP to do PKI validation or know anything about the client certificate itself."
"This specification is an alternative to the SAML V2.0 Web Browser SSO Profile in the SAML V2.0 Profiles specification [Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0]. A conforming implementation of a service provider and an identity provider must support holder-of-key assertions and the acquisition of client keys from TLS connections, for validation and issuance of these assertions, respectively. Some likely discussion points are: (1) What piece of keying material to include in the holder of key assertion (fingerprint, public key, certificate, or any of the above); (2) Whether this should be HTTP user agents only; (3) To what extent this profile should be compatible with standard web browser SSO at the risk of inducing a false sense of security." Abstract: "This profile allows for transport and validation of holder-of-key assertions by standard HTTP user agents with no modification of client software and maximum compatibility with existing deployments. Most of the flows are as in standard Web Browser SSO, but an x.509 certificate presented by the user agent supplies a valid keypair through client TLS authentication for HTTP transactions. Cryptographic data resulting from TLS authentication is used for holder-of-key validation of a SAML assertion. This strengthens the assurance of the resulting authentication context and protects against credential theft, giving the service provider fresh authentication and attribute information without requiring it to perform successful validation of the certificate...
In the scenario addressed by this profile, which is an extended version of the Web Browser SSO Profile in 4.1 of Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, a principal uses an HTTP user agent to either access a web-based resource at a service provider or access an identity provider such that the service provider and desired resource are understood or implicit. In either case, the user agent needs to acquire a SAML assertion from the identity provider. The user agent makes a request to the identity provider using client TLS authentication. The X.509 certificate supplied in this transaction is used primarily to supply a public key that is associated with the principal. The identity provider authenticates the principal by way of this TLS authentication or any other method of its choice. The identity provider then produces a response containing at least an assertion with holder-of-key subject confirmation and an authentication statement for the user agent to transport to the service provider. This assertion is presented by the user agent to the service provider over client TLS authentication to prove possession of the private key matching the holder-of-key confirmation in the assertion. The service provider should rely on no information from the certificate beyond the key; instead, it consumes the assertion to create a security context. The TLS key may then be used to persist the security context rather than a cookie or other application-layer session. To implement this scenario, a profile of the SAML Authentication Request protocol is used in conjunction with the HTTP Redirect, HTTP POST and HTTP Artifact bindings. It is assumed that the user is using an HTTP user agent capable of presenting client certificates during TLS session establishment, such as a standard web browser..." [source PDF]
[January 23, 2008] "Microsoft's Token Participation: Company Backs Another Set of XML Protocols." By Joab Jackson. From Government Computer News (January 21, 2008). "If you look over the General Services Administration's list of interoperable Security Assertion Markup Language (SAML) products, you'll notice that one name is conspicuously absent: Microsoft. The federal government is home to an overwhelming number of Microsoft Active Directory installations, which do the authentication within each agency... The good news is that the federated version of Active Directory, called Active Directory Federation Services, does have the ability to produce and consume SAML tokens. The current version of ADFS can do SAML 1.1 tokens, and the next version will support SAML 2.0 tokens, said Don Schmidt, principal program manager for Microsoft's Federal Identity. However, ADFS sends and receives these assertions not via the SAML protocol but another Extensible Markup Language-based set of secure transaction standards, called WS-* or WSFederation. This is a set of Web services protocols and includes WS-Security, WS-Federation and others. This is the group of standards Microsoft is backing. So in order to speak SAML with an ADFS implementation, the other party's gear must be able to speak in these WS-* formats. Many federated identity products do this, and even in cases where that support isn't available, there are a growing number of products that can do the translation fairly easily, Schmidt said. Microsoft threw its weight behind WS-* over SAML because it saw a greater flexibility, Schmidt said. A potential downside of SAML is that the protocol and message format are intertwined as a single unit. If a better protocol or format comes along down the road, SAML users may not be able to take advantage of the improvement. Schmidt also said that everything that can be done in SAML (such as adding attributes) can be asserted in one of the WS-* specs, such as WS-Trust...
[January 22, 2008] "SAML: The Master Key?." By Joab Jackson. From Government Computer News (January 21, 2008). 'GSA pushes the identity protocol for sharing credentials across organizational lines.' "Imagine a day when instead of setting up an account with each organization you do business with, you set up a single account, which all the parties can consult. Such a setup could be useful for federal agencies for a number of reasons. For one, federal employees often need to access systems and data held by agencies other than their own. For another, e-government initiatives involve people who often hold no government-recognized credentials. How does the government authenticate their identities? The General Services Administration's E-Authentication Identity Federation initiative can meet these needs, said David Temoshok, director of identity policy and management at GSA's Office of Governmentwide Policy. The program is a central hub for facilitating interactions among different organizations. And one of the ways E-Authentication can offer this service is through an emerging Extensible Markup Language-based standard, called the Security Assertion Markup Language (SAML), which was first developed by OASIS and later adopted by the Liberty Alliance as the backbone for its efforts to offer tools for federated network identity... Perhaps an agency wants to grant an individual access to a protected resource and needs qualifications of some sort, in addition to standard authentication, to verify suitability. This is where GSA's E-Authentication program comes in. It relies on Version 2.0 of SAML, which allows systems to attach additional attribute information — such as certificates, licenses, training, level of education and privileges — to an identity assertion. Temoshok: 'Attribute information is built into the SAML standards; therefore, the SAML infrastructure that we've built for E-Authentication will allow identity assertions to include attribute information.' [...] Through the Liberty Alliance, GSA also maintains a list of SAML-based products that are interoperable. Like the common terminology, this streamlines the process of setting up an authenticating relationship with another party. In September [2007], GSA mandated that all products undergoing SAML interoperability testing be certified to be interoperable with Version 2.0 of SAML."
[December 27, 2007] "Technical Comparison: OpenID and SAML." By Jeff Hodges (NeuStar). Draft 05. December 17, 2007. NeuStar Whitepaper. This 'Draft 05' Updates "Comparison: OpenID and SAML - Draft 00". See also the summary in the author's blog. "This document presents a technical comparison of the OpenID Authentication protocol and the Security Assertion Markup Language (SAML) Web Browser SSO Profile and the SAML framework itself. Topics addressed include design centers, terminology, specification set contents and scope, user identifier treatment, web single sign-on profiles, trust, security, identity provider discovery mechanisms, key agreement approaches, as well as message formats and protocol bindings. An executive summary targeting various audiences, and presented from the perspectives of end-users, implementors,
and deployers, is provided. We do not attempt to assign relative value between OpenID and SAML, e.g., which is better; rather, it attempts to present an objective technical comparison... OpenID 1.X and 2.0, and SAML 2.0's Web Browser SSO Profile (and earlier versions thereof), offer functionality quite similar to each other. Obvious differentiators to a protocol designer are the message encodings, security mechanisms, and overall profile flows. Other differentiators include the layout and scope of the specification, trust and security aspects, OP/IDP discovery mechanisms, user-visible features such as identifier treatment, key agreement provisions, and security assertion schema and features..." [cache][December 18, 2007] Liberty Alliance Publishes SAML 2.0 Interoperability Testing Matrix. Announcement: "Liberty Alliance Announces First Companies to Pass Full-Matrix SAML 2.0 Interoperability Testing. November Liberty Interoperable Event First to Test Over the Internet and Against US GSA SAML 2.0 Profile Requirements." — Liberty Alliance announced that products from Hewlett-Packard, IBM, RSA (The Security Division of EMC), Sun Microsystems, and Symlabs, Inc. have passed Liberty Alliance testing for SAML 2.0 interoperability. The Security Assertion Markup Language (SAML) Specification Version 2.0 was approved as an OASIS Standard in March 2005. Products and services passing SAML 2.0 interoperability testing included: Hewlett-Packard's HP Select Federation 7.0; IBM's Tivoli Federated Identity Manager, version 6.2; RSA's Federated Identity Manager 4.0; Sun Microsystems' Java System Federated Access Manager 8.0; Symlabs Inc's Federated Identity Suite version 3.3.0. The vendors participated in the November 2007 Liberty Interoperable event administered by the Drummond Group Inc. and are the first to pass full-matrix testing Liberty Alliance incorporated into its interoperability program this year. All of these vendors also passed Liberty Alliance testing against the US GSA SAML 2.0 profile, meeting the prerequisite interoperability requirements for participating in the US E-Authentication Identity Federation. Liberty Alliance continually enhances the Liberty Interoperable program to meet cross-industry demands for proven interoperable identity solutions. The November event was the first to conduct Internet-based and full-matrix testing. Internet-based testing allows vendors to participate in the same interoperability event from anywhere in the world. Full-matrix testing requires each vendor to test with every other participant to ensure testing mirrors real word identity federation interoperability requirements. The breadth and depth of these testing procedures provides deploying organizations with assurances that products have proven to interoperate with each other across the widest possible range of deployment scenarios..." See also the Matrix.
[November 19, 2007] "A Document Format for Expressing Authorization Policies to Tackle Spam and Unwanted Communication for Internet Telephony." By Hannes Tschofenig (Nokia Siemens Networks), Dan Wing (Cisco), Henning Schulzrinne (Columbia University), Thomas Froment (Alcatel-Lucent), Geoffrey Dawirs (University of Namur, Belgium). Reference: IETF SIPPING Working Group, Internet Draft 'draft-tschofenig-sipping-spit-policy-02.txt'. Date: November 19, 2007; expires May 22, 2008. I-D Tracker. "The problem of SPAM for Internet Telephony (SPIT) is an imminent challenge and only the combination of several techniques can provide a framework for dealing with unwanted communication. The responsibility for filtering or blocking calls can belong to different elements in the call flow and may depend on various factors. This document defines an authorization based policy language that allows end users to upload anti-SPIT policies to intermediaries, such as SIP proxies. These policies mitigate unwanted SIP communications. It extends the Common Policy authorization framework with additional conditions and actions. The new conditions match a particular Session Initiation Protocol (SIP) communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by SIP itself, by the SIP identity mechanism, by information carried within SAML assertions... A SPIT authorization document is an XML document, formatted according to the schema defined in RFC 4745. SPIT authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml. As described in RFC 4745, this document is composed of rules which contain three parts -- conditions, actions, and transformations. Each action or transformation, which is also called a permission, has the property of being a positive grant to the authorization server to perform the resulting actions, be it allow, block etc . As a result, there is a well-defined mechanism for combining actions and transformations obtained from several sources. This mechanism therefore can be used to filter connection attempts thus leading to effective SPIT prevention... Policies are XML documents that are stored at a Proxy Server or a dedicated device. The Rule Maker therefore needs to use a protocol to create, modify and delete the authorization policies defined in this document. Such a protocol is available with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP), per RFC 4825..." See also: (1) IETF Session Initiation Proposal Investigation (SIPPING) Working Group Charter; (2) Session Initiation Proposal Investigation Status Pages.
[July 9, 2007] "Authentication, Authorization, Accounting and Billing of Roaming Users using SAML." ['AAA and Billing of Roaming Users'.] By Silvana Greco Polito (Columbia University) and Henning Schulzrinne (Columbia University). IETF Network Working Group, Internet Draft 'draft-greco-sipping-roaming-01'. Date: July 9, 2007; expires January 10, 2008. Intended status: Standards Track. I-D Tracker. Earlier title: SIP and SAML Roaming Profile. IETF announced the publication of an updated Internet Draft previously issued under the title "SIP and SAML Poaming Profile" — "Authentication, Authorization, Accounting and Billing of Roaming Users using SAML." Abstract: "Roaming services allow users that have a contract with a voice service provider to use access resources owned by other providers known as internet access providers. This draft proposes a token-based Authentication, Authorization, Accounting (AAA) and billing model for roaming users supporting the Session Initiation Protocol (SIP). It also introduces a protocol solution for the proposed model that is based on the Security Assertion Markup Language (SAML) protocol and the Hypertext Transfer Protocol (HTTP)... While clearinghouses are used for authorizing users' calls, the guarantor provides authorization for the use of access network resources. One of the main protocols for clearinghouse-based models is the Open Settlements Protocol (OSP). OSP inroduces a token-based authorization model for interdomain calls in which telephony operators can ask a clearinghouse for tokens proving the right of their users to place calls toward some destination. In this draft, we extend the concept of tokens introduced by OSP, focusing on the authorization and authentication of roaming users instead of the authorization of calls... SAML is an OASIS protocol for the description and exchange of security information between partners. SAML defines a framework for the exchange of security information about a subject between partners called requesting, asserting and relying parties. The asserting party is the entity that produces an authentication and authorization assertion about a subject when required by the requesting party, while the relying party uses the assertion for authorizing the subject. This draft defines a new SAML profile, called roaming SAML profile. It defines a set of specifications that allows to use SAML for the description of the token and the token building request and response introduced above. In the SAML roaming profile, the VSPs assume the role of SAML requesting parties, the guarantor the one of asserting party, and IAPs the one of relying parties. See also: (1) IETF Session Initiation Protocol (SIP) Working Group; (2) Session Initiation Protocol Status Pages.
[June 11, 2007] "SIP SAML Profile and Binding." By Hannes Tschofenig (Nokia Siemens Networks), Jeff Hodges (NeuStar, Inc), Jon Peterson (NeuStar, Inc), James Polk (Cisco), and Douglas C. Sicker (University of Colorado at Boulder). Produced by members of the IETF Session Initiation Protocol (SIP) Working Group. May 28, 2007, expires November 29, 2007. 46 pages. Intended status: Standards Track. See the issues list and I-D Tracker. "This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in Trait-based Authorization Requirements for the Session Initiation Protocol (SIP). Trait-based authorization is where one is authorized to make use of some resource based on roles or traits rather than ones identifier(s). Various means of providing trait-based authorization exist: authorization certificates (RFC 3281), SPKI (RFC 2693), or extensions to the authenticated identity body (RFC 3893). The authors selected SAML due to its increasing use in environments such as the Liberty Alliance, and the Internet2 project, areas where the applicability to SIP is widely desired. The goal of this endeavor is to specify a SIP profile of SAML (aka a 'SIP SAML profile') such that a subject's profile attributes, and their domain's certificate, can be conveyed to a relying party using SAML. Employing SAML in SIP necessitates devising a new SAML profile(s) and binding(s) because the those already specified in the SAMLv2 specification set are specific to other use contexts, e.g., HTTP-based web browsing. Although SIP bears some similarity to HTTP, it is a seperately distinct protocol, thus requiring specification of SIP-specific SAML profile(s) and binding(s). This is technically straightforward as both SAML and SIP are explicitly extensible. The 'Authenticated Identity Management in SIP' specification (RFC 4474) facilitates the composition of SAML and SIP in that it defines a 'mediated authentication architecture' where verifying endpoints verify SIP identity assertions signed by an Authentication Service (AS). The semantic being that the AS is vouching that it did indeed authenticate the calling party. Such an Authentication Service, which likely has access to various pieces of information concerning the calling party, could also act as a SAML Authority, and make such information available to the callee via SAML. Since RFC 4474 stipulates that the AS must make its certificate available for retrieval and convey the availability and access mechanism via a URI, in the Identity-Info header, we have an opportunity to compose SIP Identity and SAML. Such composition can be accomplished by having the resource referred to by the URI in the Identity-Info be a SAML assertion conveying both the AS's certificate and user profile attributes. We reuse the SIP term 'Authentication Service' to refer to a network element that authenticates and authorizes a user and creates a 'SIP identity assertion'. This system entity is the logical equivalent of a 'SAML Authority' in the SAML terminology..." Note: Draft -03 update.
[May 8, 2007] "Enrolled User Policy Profiles Attribute." By Mark Wahl (Informed Control Inc). IETF Network Working Group, Internet Draft 'draft-wahl-schema-eupp-attribute-01'. May 8, 2007. Intended status: Standards Track. See the I-D Tracker. "This document defines an attribute of a user identity which contains a list of the identifiers of enrollment policy profiles for that user. This attribute is generated by an identity provider that manages the user's identity. An encoding of the attribute is defined for transport in the Lightweight Directory Access Protocol (LDAP), in the Security Assertion Markup Language (SAML), the OpenID Attribute Exchange Protocol, and as an Information Card claim...
[March 12, 2007] "Lightbulb is Dead: Long Live OpenSSO Extensions!" By Pat Patterson. Blog. March 12, 2007. In October 2006, OpenSSO developers released the first SAML 2.0 implementation in PHP, codenamed 'Project Lightbulb' (because Lightbulb fits into LAMP). Lightbulb was initiated as an Open Web Single Sign-On (OpenSSO) subproject, designed to achieve federated identity for LAMP (Linux, Apache, MySQL, PHP, Python, and Perl) and MARS (MySQL, Apache, Ruby, and the Solaris Operating System). Lightbulb offered a service provider (SP) written in PHP with Security Assertion Markup Language (SAML) 2.0. In the few months since then, other folks have proposed similar extensions to OpenSSO, and the 'Lightbulb' name has looked increasingly anachronistic, particularly since the core OpenSSO project has always fully supported LAMP with its Apache HTTP Server and Tomcat policy agents. "Today, we launch OpenSSO Extensions, OpenSSO's code incubator, with three initial modules: (1) The SAML 2.0/PHP relying party formerly known as Project Lightbulb (2) An OpenID Identity Provider for OpenSSO, contributed by long-time OpenSSO committer, Paul Bryan (3) A PHP Client SDK for OpenSSO, contributed by Francesco Chicchiricco. To come: SAML 2.0 Ruby Relying Party. So: what is an OpenSSO Extension? Well, it's any piece of code that either extends OpenSSO to provide new functionality, for example, the OpenID identity provider, or interfaces with OpenSSO, extending other systems, such as the PHP Client SDK and SAML 2.0 relying party. OpenSSO Extensions is an incubator for modules that build on the access control, single sign-on and federation technology in OpenSSO, but are not part of the core project..."
[February 27, 2007] SAML Single Sign-On (SSO) Service for Google Apps. Google Staff. Technical Documentation. "Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content. Google Apps offers a SAML-based Single Sign-On (SSO) service that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar. Using the SAML model, Google acts as the service provider and provides services such as Gmail and Partner Start Pages (PSP). Google partners act as identity providers and control usernames, passwords and other information used to identify, authenticate and authorize users for web applications that Google hosts. It is important to note that the SSO solution only applies to web applications. Google offers two tools to help partners understand and implement a SAML-based SSO service. (1) The SAML-based SSO Static Demo demonstrates the SAML transaction process. The demo uses static files to simulate the transactions that Google and the partner company would conduct to log a user into a hosted Google application (Gmail). (2) The Web-based Reference Implementation is an interactive Java application that allows partners to view the XML generated for SAML requests and responses. The documentation for the tool explains how the partner could modify the tool to submit SAML requests to an internal application that actually authenticates a user. Both of these tools display a similar interface. However, the static demo does not actually execute any code whereas the web-based reference implementation provides Java code that demonstrates the functionality a partner will need to perform to process SAML requests and generate SAML responses..." See the demo.
[February 20, 2007] "It's a Saml World, After All." By Eve Maler. 'Pushing String' Blog. "Nope, that's not a typo. I kept thinking about that silly tune when I saw the panel assembled for an RSA conference session called 'SAML 2.0 -- Standard-of-Choice in the Public Sector', hosted by Brett McDowell. The speakers represented identity management initiatives in the US, Denmark, Finland, and the UK. I thought it would be interesting to share what I heard... [excerpts] (1) Soren Peter Nielsen, representing the Denmark State Services Commission - 'Based on these requirements, picking SAML 2.0 really was a slam-dunk decision. The fact that the US GSA E-Authentication Initiative chose SAML was one factor in Denmark's choice.' (2) Tero Pernu, representing the Finnish Board of Taxes - 'The Finnish case study is a bit more broader than the Danish one. This one includes also the Liberty Identity Web Service Framework. SAML2 was attractive partly because of its layered security model: transport and message security. It also has a strong developer community, which welcomed Finnish tax board participation. Katso is the nickname for the nationwide Finnish authentication system.' (3) Brett McDowell (BMcD)- 'This panel will discuss why governments are deploying SAML2 for federation, and we'll explore the use of open standards to meet regulatory requirements. Governments are one example of an enterprise. SAML2 was the result of convergence of SAML V1.x, Liberty ID-FF, and Internet2 Shibboleth. The market has been growing around SAML. One clear driver has been the Liberty Interoperable program, with about 80 certifications made through it so far. Deployers can request Liberty Interoperable certification in their RFPs. Over 1 billion identities and devices are Liberty-enabled.'..."
[February 13, 2007] "An Integrated Approach to Federated Identity and Privilege Management in Open Systems." By Rafae Bhatti (IBM Almaden Research Center, San Jose, CA); Elisa Bertino and Arif Ghafoor (Purdue University, West Lafayette, IN). In Communications of the ACM Volume 50, Issue 2 (February 2007), pages 81-87, with 12 references. "Online partnerships depend on federations of not only user identities but also of user entitlements across organizational boundaries... Here, we discuss the shortcomings of federated identity mechanisms and their integration with privilege management mechanisms. We also present an integrated approach to federated identity and privilege management specifically designed for Web-based platforms. Any such mechanism should first satisfy several requirements: (1) Single sign-on (SSO), which implies the persistence of user identity and entitlement across multiple enterprise domains. (2) Effective access control: the access control model and should support a fine-grain, context-aware access control that manages user access to dynamically evolving enterprise resources. (3) Decentralized model, so that the system does not rely on a centralized or single point for accessing user authentication and authorization information. (4) Authentication for strangers, because Internet service providers cannot assume advance knowledge of the identities or capabilities of all users. (5) Trust, anonymity, privacy — as privacy protection is increasingly important to overall business collaboration, especially from a social and legal perspective. (6) Standardized approach, because it is only prudent for organizations to take an incremental, 'integrateable' approach, designing new solutions that complement existing standards. A basic requirement our authorization model must satisfy is suitability to Web-based applications. To do so, we chose X-GTRBAC as the access control specification language; it has been shown to be effective in enabling access control in dynamic Web-service applications due to its XML-based modular and flexible context-aware policy specification. The central idea is that the X-GTRBAC system uses credentials supplied by users to assign them to roles, or authentication, subject to assignment constraints. Users might subsequently access resources according to their role memberships, or authorization, subject to access constraints... Our X-GTRBAC-based specification provides one, designed to accept SAML-encoded assertions as a form of credential. However, this straightforward integration is not sufficient for our purposes — integrating privilege management with existing federated identity mechanisms. SAML assertions are inherently subject to the same name-binding problem that exists in the protocols (such as Kerberos and X.509) it is designed to work with. Our specification works with property-based TM credentials, creating a SAML profile for X-GTRBAC involving the feature set from the SAML specification (v2.0). Using a SAML profile in the X-GTRBAC system requires a translation from SAML encoding to the X-GTRBAC format, and vice versa, using Extensible Stylesheet Language Transformations, a standard for syntax-oriented XML document transformation. This framework is a novel attempt to address the identity and entitlement federation issues we've discussed here. It integrates two security standards (RBAC and SAML) in order to create an access-management specification for open systems. It complements other efforts in this direction aimed at allowing interoperable access management using standard protocols. Our grammar specification supports federated identity and privilege management while meeting the requirements we've outlined. Future challenges include integrating our specification with existing directory schemes to support property-based credentials, trust negotiation protocols for incremental attribute collection, and state information for anonymous users to ensure proper accountability..." See the publications listing.
[January 16, 2007] "Comparison: OpenID and SAML - Draft 00." By Jeff Hodges (NeuStar). A SAML Whitepaper. January 16, 2007. "This document presents a brief comparison of OpenID and SAML. For the most part, the comparison is between OpenID 2.0 and SAML 2.0, although there are some mentions of prior versions of each. The comparison addresses technical features, breadth of addressed use cases, and attributes of the specification sets... OpenID, both 1.X and 2.0, and SAML 1.X and 2.0, offer functionality quite similar to each other. Obvious differentiators are the message encodings, security mechanisms, and overall profile flows -- OpenID specifies a flow that no present single SAML profile congruently matches. However, we note that it is distinctly possible to relatively easily craft a new SAML profile that incorporates the deltas between OpenID and, say, the SAML Web Browser SSO profile. See: "OpenID SAMLv2 Lightweight SSO Profile" — specifies a SAMLv2 lightweight Web Browser Single Sign-On Profile that matches the functionality in OpenID. SAMLv2 Lightweight Web Browser SSO Profile, and the SAML HTTP POST SimpleSign binding. Note: See the Draft 05 update, December 17, 2007. [cache v-00]
[October 13, 2006] "How to Study and Learn SAML." By Jeff Hodges [WWW] (Neustar). Draft SAML Whitepaper. Published via Identitymeme.org, being JeffH's musings on identity, security, protocols, SDOs, and tussles thereof. Audience: The target audience is other protocol designers and/or protocol implementors. "This brief whitepaper provides a functional introduction to the SAMLv2 specifications tailored to protocol designer and developer's perspectives. First a conceptual introduction is presented, next suggestions on how to study and learn SAML are given, and then more detailed aspects are discussed. SAML defines an XML-based framework for crafting 'security assertions', and exchanging them between entities. In the course of creating, or relying upon such assertions, SAML system entities may use SAML protocols, or other protocols, to convey an assertion itself, or to communicate about the 'subject' of an assertion. Thus one can employ SAML to make statements such as: 'Alice has these profile attributes and her domain's certificate is available over there, and I'm making this statement, and here's who I am.' Then one can cause such an assertion to be conveyed to some party who can then rely on it in some fashion for some purpose, for example input it into a local policy evaluation gating access to some resource. Such applications of SAML are done in a particular 'context of use'. A particular context of use could be, for example, deciding whether to accept and act upon a SIP-based invitation to initiate a communication session. The specification of just how SAML is employed in any given context of use is known as a 'SAML profile'. The specification of how SAML assertions and/or protocol messages are conveyed in, or over, another protocol is known as a 'SAML Binding'. Typically, a SAML profile specifies the SAML bindings that may be used in its context. Both SAML profiles and SAML bindings in turn reference other SAML specifications, especially the SAML Assertions and Protocols, aka 'SAML Core', specification. Note that the SAML Assertions and Protocols specification, the SAML Core, is conceptually 'abstract'. It defines the bits and pieces that make up SAML Assertions, and their nominal semantics, but does not define how to actually put them to use in any particular context. That, as we've said, is left to SAML Profiles, of which there can be many..." See the author's note. An updated version may be available from the author's home page. [source]
[October 02, 2006] "SAML V2.0 Basics." By Eve Maler (Sun Microsystems, Inc). Updated 2-October-2006. 62 pages. "Focusing on SAML. The Security Assertion Markup Language in six words: 'The universal solvent of identity information'. The best supported and most thoroughly standardized, covering a wide range of distributed-identity scenarios. It reflects the convergence of several development streams, enables privacy along various dimensions. Many other specs and standards build on it... SAML in a technical nutshell. SAML in fifteen words: 'XML-based framework for marshaling security and identity information and exchanging it across domain boundaries': [1] It wraps existing security technologies rather than inventing new ones; [2] Its profiles offer interoperability for a variety of use cases, but you can extend and profile it further. At SAML's core: assertions about subjects (authentication, attribute, entitlement, or roll-your-own)..." Author's note: "This is an updated and improved version of my SAML Basics slides, which I had last revised (for V2.0) in May 2005. The OpenOffice.org version has a number of custom animations, which are of course flattened out in the PDF. It is okay to copy and reuse these slides with attribution..." [source PDF]
[September 19, 2006] "SIP and SAML Roaming Profile." By Silvana G. Polito (University of Palermo) and Henning Schulzrinne (Columbia University). IETF Internet Draft. Reference: 'draft-greco-sipping-roaming-00.txt'. September 15, 2006, expires March 19, 2007. "Roaming services allow users that have a contract with a voice service provider to use access resources owned by other providers known as internet access providers. This draft proposes a token-based Authentication, Authorization, Accounting (AAA) and billing model for roaming users. It also introduces a protocol solution for the proposed model that is based on the Assertion Markup Language (SAML) protocol and the Session Initiation Protocol (SIP). The SAML protocol defines a way for the exchange of security information about a subject between partners called requesting, asserting and relying parties. The asserting party is the entity that produces an authentication and authorization assertion about a subject when required by the requesting party. While the relying party uses the assertion for authorizing the subject. This draft defines a new SAML profile, called roaming SAML profile. The profile defines a set of specifications that allows to use SAML for the description of the token and the token building request and response. In the SAML roaming profile, the voice service providers (VSPs) assumes the role of SAML requesting parties, the guarantor the one of asserting party, and internet access providers (IAPs) the one of relying parties. Section 6. "XML schemas" defines the XML schemas of the elements and types defined in this draft to support the SAML roaming profile. As introduced in Section 4.1, the SAML Condition element is used for describing the token lifetime and the user profile. For the description of the token lifetime we use the Notbefore and NotOnOrAfter attributes of this element defined in SAML Core 2.0. For the description of the user profile, we define the condition_profileType. It extends the ConditionAbstractType of the Condition element defined in SAML Core 2.0 and adds the UserProfile element to it. We use the quality of service class for describing the user profile. The quality of service class is described using the values Gold, Bronze, Silver. Note: targetNamespace="http://www.tti.unipa.it/~silvana/".
[June 15, 2006] "Sun Microsystems Publishes Non-Assertion Covenant for SAML Implementations." On June 15, 2006, Sun Microsystems issued a 'SAML Non-Assertion Covenant' in connection with OASIS Security Assertion Markup Language (SAML) specifications being created by the OASIS Security Services (SAML) TC. Sun's unilateral, voluntary waiver of its right to enforce possibly relevant patent claims alleviates the burden upon implementers to negotiate license terms, eliminates paperwork, and creates a favorable environment for the develoment of open source software. Similar declarations have been made by Fidelity Investments, RSA Security, and America Online, Inc. in relation to the SAML specification(s). See further information in the main entry.
[June 12, 2006] SAMLv2: HTTP POST 'NoXMLdsig' Binding. Edited by Jeff Hodges Jeff Hodges (NeuStar) and Scott Cantor (Internet2). Reference: draft-hodges-saml-binding-no-xmldsig-00. rev -02. clarifies that assertions conveyed within SAML messages via this binding MAY be signed with XMLdsig. "This specification defines a SAML HTTP protocol binding, specifically using the HTTP POST method, and not using XML Digital Signature for SAML message and/or SAML assertion data origination authentication. Rather, a 'sign the BLOB' technique is employed wherein a conveyed SAML message, along with any content (e.g., SAML assertions) is treated as a simple octet string if it is signed. Security is optional in this binding..." Note from the posting: "Scott Cantor and I have concocted the attached new draft SAML binding. The central thesis is that for various implementation and deployment scenarios, reliance upon XMLdsig is an inhibitor. So this new binding, which we've tentatively entitled "", is an answer. It is HTTP POST-based, with an _optional_ signature mechanism. The signature is over the entire conveyed SAML message "blob" and any RelayState (and SigAlg ;)..." [source]
[May 11, 2006] RSA Security Issues Non-Assertion Covenant for SAML-based Technologies Robert Philpott. Communication to OASIS. On behalf of RSA Security, Robert Philpott communicated the text of a revised declaration about SAML-related patents. He notes that previously "RSA Security's IP declaration for SAML described a licensing process that required downloading a license from the RSA Security web site, getting it signed, and mailing it back to RSA's legal office. I've been working on getting this changed for quite a long time (months) and finally achieved success last week!" The new statement says, in part: "In the interest of encouraging deployment of SAML-based technologies, RSA hereby covenants, free of any royalty, that it will not assert any claims in the RSA Patents which may be essential to the SAML standard v1.0, 1.1 and 2.0 (hereinafter 'NECESSARY CLAIMS') against any other entity with respect to any implementation conforming to the SAML standard v1.0, 1.1 and/or 2.0. This covenant shall become null and void with respect to any entity that asserts, either directly or indirectly (e.g. through an affiliate), any patent claims or threatens or initiates any patent infringement suit against RSA and/or its subsidiaries or affiliates. The revocation of the covenant shall extend to all prior use by the entity asserting the claim." This declaration by RSA Security is similar to the IPR statement from Sun Microsystems relating to the OASIS OpenDocument Standard. Such public non-assertion declarations for standards help create in a zero-bureaucracy waiver model which makes patent searches irrelevant and license-transaction paperwork a non-issue. See also the source.
[April 28, 2006] "Assertion of Intent." By John Gotze. From Gotzeblogged e-Government (April 27, 2006). "IDABCs eGovernment Observatory brought this story out in English on 2006-04-25: 'The Danish IT Architecture Committee has decided to stand firm on SAML 2.0 as the recommended standard for federation'. Once broken into English, the story was quickly brought around internationally. SecureID News basically copied the IDABC-story, Danish Government says 'yes' to SAML 2.0 and encourages Microsoft to support those specifications.. Computer Business Review follow-up and talked to Liberty Alliance: Identity next public sector battleground for Microsoft? There is a bit more to the story than the international coverage caught. Basically, the committee decision was about an open letter to Microsoft. It was written by my former collegue, Soren Peter Nielsen from the IT-Strategic Office in the Danish Ministry of Science, Technology and Innovation; the letter to Microsoft was sent via Microsft Denmark to Don Schmidt, senior program manager for Microsoft's Identity and Access group. [The letter said in part:] "In the Danish Ministry of Science, Technology and Innovation we have the responsibility to select and recommend IT standards for public sector usage as also create shared services for public sector. This work is undertaken in an open process that involves all levels of public sector institutions. The Danish public sector decided early in 2005 to recommend using SAML 2.0 for federated identity and access management. This was among other based on the momentum for the standard in product support from various suppliers, plans for actual usage in public sector solutions worldwide, proofing og interoperability through testing, and also very important SAML 2.0 being a ratified OASIS standard..." See also the blog entries from Eve Maler: SAML in the News, More about the Danish government SAML situation.
[April 28, 2006] "Identity Next Public Sector Battleground for Microsoft?" By Kevin Murphy. From Computer Business Review Online (April 26, 2006). "Denmark's recent call for Microsoft Corp to support SAML for federated identity is just the tip of the iceberg when it comes to public and private sector demand for such a move, according to the executive director of the Liberty Alliance. Brett McDowell told us he thinks there are some similarities between the Danish call for SAML support and the recent decision by Massachusetts to standardize on the non-Microsoft OpenDocument Format. He said that Microsoft's decision to support its own WS-Federation spec, but not SAML, in the latest release of Windows Server 2003, will lead to more governments demanding that Microsoft support the OASIS-backed specs. SAML, for security assertions markup language, sets out ways to communicate security statements between separate access control systems, enabling federated identity and simplifying cross-domain single sign-on. Liberty, which contributed some earlier separate specs to the SAML initiative and has wholly embraced SAML 2.0, has been pushing Microsoft to back SAML for years, but Microsoft is more interesting in WS-Federation, built in conjunction with IBM. There have been demonstrations for about a year of interoperability between software that implement the two specs, notably at the Burton Group conference last July, but they have required a layer of translation between the two..."
[April 25, 2006] "OpenSAML 2.0, Java Edition, Technology Preview 1." By Chad La Joie. OIS-Middleware Announcement. "An announcement has been issued for the release of OpenSAML 2.0, Java Edition, Technology Preview 1. This release features: (1) the ability to parse, marshall, unmarshall, and build SAML 1.0, 1.1, and 2.0 messages; (2) metadata caching and filtering; (3) new documentation; (4) the ability to work with XML fragments, taking part of a SAML message and sticking it into another DOM document.... like a SOAP header or body). This release is not desceibed as production level code but does represents what the developers believe to be to the final design of the library for the components mentioned here. OpenSAML is a set of open-source libraries in Java and C++ which can be used to build, transport, and parse SAML messages. OpenSAML is able to store the individual information fields that make up a SAML message, build the correct XML representation, and parse XML back into the individual fields before handing it off to a recipient. OpenSAML supports the SOAP binding for the exchange of SAML request and response objects (C++ supports requesting only). It provides additional help in supporting the SAML browser/POST profile for web single sign-on. It does not currently provide any additional support for the artifact profile, but provides the machinery needed to implement it in other software. All core SAML constructs are now supported to some degree..."
[April 24, 2006] "Danish IT Architecture Committee and SAML 2.0." By [Staff]. From eGovernment News (April 24, 2006). "The Danish IT Architecture Committee has decided to stand firm on SAML 2.0 as the recommended standard for federation. The OASIS ratified SAML 2.0 standard has since April 2005 been the officially recommended standard for federation in the Danish public sector. Microsoft's recent decision to ship a federation service, as part of its Windows 2003 server operating system without supporting the SAML 2.0 standard challenges this recommendation because the WS-Federation specification implemented by Microsoft cannot interoperate with SAML 2.0. Denmark thinks Microsoft should support customer choice by implementing support for SAML 2.0 in their operating system on equal footing with the WS-Federation specification. Basing e-government on privately controlled specifications that may stifle innovation is not desirable from the Danish point of view. As a consequence the Danish IT Architecture committee has decided to stand firm on the SAML 2.0 recommendation. At the same time the committee has decided to try and work towards convergence in the area of federation standards through dialogue with EU, other governments, suppliers and standardizations bodies..."
[December 19, 2005] "SAML 2.0 Profile for SSO in Danish Public Sector." By Thomas Gundel (IBM Crypto Competence Center Copenhagen). DK-SAML Profile. Version 1.1. Date: 19.12.2005. Copyright (c) IBM CCCC and IT- and Telestyrelsen. 31 pages. "IT-og Telestyrelsen in Denmark has launched an initiative aiming for a common approach to authentication for E-Government in Denmark. The initiative is based on the E-Authentication Initiative from USA (http://www.cio.gov/eauthentication) which is part of the President's Management Agenda established to create trust and confidence in E-Government transactions. The goal of the Danish initiative is to enable government organizations to use external authentication services instead of developing their own, simplify Single Sign-On (SSO) across disparate systems and establish a foundation for federated identity management. This will hopefully result in cost-reductions through re-use of authentication services, faster development cycles for E-Government applications, consistent application of security technology, and improved user experiences (via Single Sign-On). To start the initiative, IT-og Telestyrelsen has produced a set of documents and published them for public hearing (which ended September 22, 2005). The base document ("Anbefaling om faelles arkitektur for tvaergaende autenticitetssikring") defines the overall architecture and the scenarios for Single Sign-On (SSO) to be supported. The architecture is based on the concept of federation and is technology-agnostic such that it can be implemented using different underlying technologies. This is a huge advantage since several different federation technologies currently exist in parallel and still undergo continuous development. Separate technical specifications are thus needed to define how the architecture should be implemented with current federation technology. These specifications should ensure that implementations from different vendors will interoperate in real life. A key area will be definitions of the data formats and mechanisms used to exchange information about an end user. IT-og Telestyrelsen has decided to base the initial version on a SAML 2.0 profile tailored to Danish E-Government needs. The purpose of this document is to describe exactly such a profile. It further needs to be supplemented by interface specifications defining the hand-off mechanisms (e.g. cookies and HTTP parameters) between the entities in the architecture not covered by the SAML profile itself. These interface specifications are however not in scope for the present document. This initial version of the SAML profile was created without supporting pilot implementations. It is however expected that subsequent pilot implementations could identify areas which need subsequent clarification or modification in order to achieve true interoperability by different commercial SAML implementations..." [cache[
[November 21, 2005] "Liberty Alliance Announces Latest Companies Passing SAML 2.0 Interoperability Testing. Products from IBM, NEC, NTT and RSA Security Join Liberty's Growing List of Interoperable Identity Solutions." - "The Liberty Alliance Project, a global consortium for open federated identity and Web services standards, today announced that products from IBM, NEC, NTT and RSA Security passed interoperability testing at Liberty's recent conformance event. These companies successfully demonstrated that their products meet interoperability standards for Liberty Federation and join nearly seventy other identity products and solutions from multiple vendors that have now passed Liberty interoperability testing. Liberty Alliance holds regular conformance events at varying locations around the world to test products for interoperability of Liberty identity specifications. After participating in a five-day testing event held in Tokyo earlier this month, IBM, NEC, NTT and RSA Security have demonstrated interoperability of products and solutions that incorporate Liberty Federation (Liberty ID-FF 1.2 and/or SAML 2.0) specifications. 'Liberty's Interoperable Program is about creating a global ecosystem of identity solutions that have been proven to work together in an open federated network environment,' said Roger Sullivan, chair of the Liberty Alliance conformance program and vice president of business development for Oracle's Identity Management. 'Since Liberty launched the program in 2003, identity products that have passed interoperability testing have been deployed extensively in a variety of industries and vertical market segments worldwide..."
[November 17, 2005] "Microsoft Says It Won't Support SAML 2.0. Microsoft Backs WS-Federation Protocols for Next Generation of Message-Based Apps." By Jeremy Kirk. From InfoWorld (November 17, 2005). "Microsoft will stick by the set of protocols it has picked for identity federation, a concept that includes single sign-on (SSO) for several different Web portals and secure transfers of data between partnered businesses. Microsoft has backed WS-Federation protocols for the next generation of message-based applications because it offers a full suite of security, message, and transaction protocols, said Don Schmidt, senior program manager for Microsoft's Identity and Access group. The company's stance is not about which protocol set is necessarily better but rather which offers a wider flexibility in accommodating federated identity... The WS-Federation protocols compete with the SAML (Security Assertion Markup Language) 2.0 specification, which so far has strong footing in the race to create secured identity federation across organizations. SAML 2.0 is backed by consortiums such as the Liberty Alliance and the Organization for the Advancement of Structured Information Standards (OASIS). SAML 2.0 protocols are fine for strictly Web single sign-on, Schmidt said. But the WS-Federation protocols are better equipped to deal with a distributed Web services environment for message reliability, transaction support and security, he said. SAML 2.0 does not have reliable messaging or transaction support, he said..." See WS-Federation Workshop. Note: WS-Federation (July 2003) was not among the specifications presented to the OASIS Web Services Secure Exchange (WS-SX) Technical Committee.
[September 15, 2005] "Identity Federation: Is it Time to Move Now? Businesses Need a Strong Case to Justify Investing Now, Gartner VP Says." By Jeremy Kirk. From InfoWorld (September 15, 2005). "While there is high interest in identity federation, the technology is still in flux and will likely be more expensive and time-consuming to implement immediately rather than three years from now, identity and access management expert [Roy Wagner] said. Most of the current identity federations are based on Web services protocol developed by Liberty Alliance, a consortium of companies working on identity federation, and the Organization for the Advancement of Structure Information Standards. Both have worked together to develop SAML (Security Assertion Markup Language). Another standard (WS-Federation, whose backers include Microsoft) is more general and more flexible but has not been offered to a standards body, Wagner said; he recommends using SAML 2.0, although there have been complaints that the protocols are too specific. Wagner predicts there may be some convergence on a standard, but 'at this point it is not likely to happen in the near future,' he said. The next step, which the technology will catch up soon to, is federated provisioning — combining identities held by a large company such a telecom but stored in several countries."
[September 2005] "Using XACML for Privacy Control in SAML-Based Identity Federations." By Wolfgang Hommel. The Munich Network Management Team, Leibniz Computing Center, Munich, Germany. Pages 160-169 in Proceedings of Communications and Multimedia Security (CMS 2005). Ninth IFIP TC-6 TC-11International Conference, Salzburg, Austria, September 19 - 21, 2005. Abstract. "With Federated Identity Management (FIM) protocols, service providers can request user attributes, such as the billing address, from the user's identity provider. Access to this information is managed using so-called Attribute Release Policies (ARPs)... In this paper, we first analyzed existing implementations of Attribute Release Policies (ARPs), which are the core privacy management tool in today's identity federation standards. We have found several shortcomings and described their consequences for real world applications and user acceptance. We then provided arguments to use XACML as base for ARPs, a well-established access control language standard, which has been successfully used in the field of distributed access control before. We presented an architecture for the integration of XACML ARPs into SAML-based identity providers, which remains fully compliant to the SAML standard. The syntax and semantics of XACML ARPs have been specified along with the policy evaluation workflow, which makes use of an out-of-the-box XACML policy decision point. Finally, we introduced our implementation, the way to integrate it into Shibboleth, a popular open source identity federation software, and outlined an algorithm which converts existing Shibboleth ARPs lossless to XACML ARPs. We are planning to integrate this ARP engine into the next major version of Shibboleth, but for use in a production environment, intuitive graphical user interfaces for the creation, testing and maintenance of these ARPs must be conceived and implemented to hide the complexity from the end users. We will also investigate the use of XACML for the so-called Attribute Acceptance Policies, which are the counterpart to ARPs on the service provider side; similar deficiencies such as yet another proprietary format can be found there presently. [cache 2006-08 from source PDF]
[September 07, 2005] "SSO: The Holy Grail of SOA." By Alice LaPlante. From SOA Pipeline (September 07, 2005). "SAML (Security Assertion Markup Language) was in the spotlight again last week. An XML-based framework developed by OASIS Security Services Technical Committee, SAML allows companies to securely and automatically share identity information on the Web. Computer Associates announced its plans to use SAML 2.0 with eTrust SiteMinder, its Web access management product. The access management support eliminates the need to re-authenticate at each site; the product will thus allow customers to federate as identity providers or as service providers with multiple partners. SAML 2.0 is important because it represents the coming together of two important SSO standards efforts. After all, as recently as this past winter, various groups were working on competing standards, including SAML 1.x, the Liberty Alliance's ID-FF, Internet2's Shibboleth, and Microsoft's Passport. The Liberty Alliance and Internet2 chose to provide input to the latest version of SAML and help consolidate the standards into SAML 2.0..."
[July 18, 2005] "Using SAML for SIP." By Hannes Tschofenig (Siemens), Jon Peterson (NeuStar, Inc), James Polk (Cisco), Douglas C. Sicker (University of Colorado at Boulder), and Marcus Tegnander (Letterkenny Institute of Technology). IETF SIP Working Group, Internet-Draft 'draft-tschofenig-sip-saml-04.txt'. July 18, 2005, expires January 19, 2006. 35 pages. "This document defines a mechanism for using the Security Assertion Markup Language (SAML) in concert with the Session Initiation Protocol (SIP). In particular, it provides a way for SIP to refer to SAML objects, and for recipients of SIP messages to use SAML in order to make more informed authorization decisions. A motivation for trait based authorization and some scenarios are presented in 'Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)'. Security Assertion Markup Language (SAML) is an XML extension for security information exchange that is being developed by OASIS. SAML is a XML-based framework for creating and exchanging security information. To provide trait-based authorization a few solutions are possible: authorization certificates, SPKI or extensions to the authenticated identity body ('SIP Authenticated Identity Body (AIB) Format'). The authors selected SAML due to its increasing use in environments such as the Liberty Alliance and the Internet2 project, areas where the applicability to SIP is widely desired. Source: http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-04.txt, see ID tracker.
[April 15, 2005] "Liberty Alliance Embraces SAML 2.0." By Jim Wagner. From InternetNews.com (April 15, 2005). "With the ink barely dry on the final Security Assertion Markup Language (SAML) 2.0 standard, officials at the Liberty Alliance are set to include the technology in its interoperability test bed Monday. The Liberty Interoperable Logo Program certifies software developers create products that interoperate with products from other vendors using a variety of specified profiles and schema. Officials at OASIS blessed the single sign-on technology for use in the industry Thursday. The technology fills in the gaps left by SAML 1.0, with improved metadata specifications to improve communications between companies using the technology within a federation, as well as new attribute profiles. Roger Sullivan, Liberty Alliance conformance expert group chairman and Oracle vice president for identity management solutions, said the organization has been working on getting SAML 2.0 into the interoperability program for some months... Several vendors have already included SAML 2.0 in their product line or are in the process of rolling out a version in the near future: Oracle, Computer Associates and RSA Security. Sullivan would not say which companies are going through the interoperability process, noting the identities of companies participating in the program are kept secret under non-disclosure agreements until several weeks after successful completion of the program. In order to gain program approval, the product must work with at least two other vendor implementations. The logo is good only for the specific version of the product that undergoes the testing, not the entire product line. According to officials, some 15 vendors and 30 products have already successfully participated in the program, the first in the industry to test and approve interoperability standards for federation, single sign-on and identity-based Web services..."
[March 24, 2005] "SAML Needs More Than OASIS Approval." By Ray Wagner, Charles Abrams, John Pescatore, David Mitchell Smith. Gartner Research Report, ID Number G00126835. March 21, 2005. ['Security Assertion Markup Language (SAML) is now an accepted industry standard. But it will need broad vendor support to deliver real-world business value.'] "OASIS approval [of SAML 2.0 as an OASIS Standard] is a positive step, but much more must be done before SAML can be considered anything more than just another security token format and yet another set of protocols. SAML has been in existence since 2001, and many vendors support it, but very few real-world production applications rely on it. SAML offers enterprises the promise of multivendor interoperability for authentication, authorization and access control products. Real-world business environments need ways to allow a customer to log in at one commerce site and have that customer's authentication and authorization attributes passed on to business partners, without requiring the customer to log in multiple times. This can potentially benefit business by reducing the costs of identity management systems, and by limiting customer abandonment of electronic commerce due to complexity issues. However, for this promise to be realized, all major vendors must support both SAML token formats and SAML protocols organically within their products. This certainly is not yet the case for most of the leading vendors, and not even the vendors that have developed SAML use it within the federation features of their own products. If those vendors did so, major platform vendors would have a much stronger incentive to focus on full SAML support..." Also available in PDF.
[March 10, 2005] SAML Executive Overview. Produced by members of the OASIS Security Services (SAML) Technical Committee. March 10, 2005. Version 2. draft 6. 5 pages. "SAML, developed by the Security Services Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS), is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. SAML is a flexible and extensible protocol designed to be used — and customized if necessary — by other by other standards.The Liberty Alliance, the Internet2 Shibboleth project, and the OASIS Web Services Security (WS-Security) committee have all adopted SAML as a technological underpinning for various purposes. SAML is also supported in major application server products and SAML support is also common among Web services management and security vendors. SAML V2.0 builds on that success. Many of these implementations have demonstrated succcessful interoperability at a series of events — the latest of which was held at the 2005 RSA Conference. The OASIS SAML Interoperability Lab, sponsored by the US Government's GSA, used three separate scenarios to demonstrate SAMLbased interaction between a government or enterprise portal and sites from typical content or service providers. SAML V2.0 unifies the building blocks of federated identity in SAML V1.1 with input from both higher education's Shibboleth initiative and the Liberty Alliance's Identity Federation Framework. As such, SAML V2.0 is a critical step towards full convergence for federated identity standards. XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized in OASIS. XACML describes both an access control policy language and a request/response language. The policy language is used to express access control policies ('who can do what when'). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries (responses). The newest versions of XACML and SAML have been designed to complement each other; for example, an XACML policy can specify what a provider should do when it receives a SAML assertion, and XACML-based attributes can be expressed in SAML..." [source PDF]
[February 16, 2005] "OASIS Federated Identity Lab Demonstrates SAML 2.0 Interoperability for GSA E-Gov's E-Authentication Initiative. Computer Associates, DataPower Technology, Entrust, Hewlett-Packard Company, Oracle, RSA Security, Sun Microsystems, and Others Showcase Authentication and Authorization Standard at RSA Conference." - "Thirteen vendors from around the world teamed with the U.S. General Service Administration (GSA) E-Gov E-Authentication Initiative to demonstrate interoperability of the Security Assertion Markup Language (SAML) 2.0, a security specification developed by the OASIS standards consortium. SAML enables secure exchange of authentication, attribute, and authorization information between disparate security domains, making secure Internet e-business transactions possible. The OASIS Federated Identity InterOp Lab, co-sponsored by GSA E-Authentication Initiative, Enspier, and RSA Security, demonstrated a combination of web single sign-on, and single logout scenarios. 'SAML 2.0 brings together SAML 1.x, Liberty Alliance and Shibboleth functionality to provide a logical convergence point for new products and deployments in the coming months,' said Dan Blum, Senior Vice President and Research Director, Burton Group. 'This OASIS InterOp demonstration offers an important proof-of-concept for the new specification.' According to Stephen Timchak, GSA Program Executive, 'The E-Authentication Initiative is committed to helping drive the evolution of federated identity management, and that's why we are excited to sponsor the OASIS Federated Identity InterOp on SAML 2.0 at RSA 2005. I believe that the E-Authentication-sponsored SAML 1.1 interoperability event at last year's RSA conference helped speed the evolution of the SAML standard, and we look forward to being enthusiastic adopters SAML 2.0 when it qualifies for inclusion in the E-Authentication architecture'..."
[February 16, 2005] OASIS Federated Identity Interoperability Lab. "The OASIS Federated Identity Interoperability Lab will feature companies from around the globe demonstrating interoperability using the OASIS Security Assertion Markup Language Standard (SAML) v2.0 specification. SAML enables secure exchange of authentication, attribute and authorization information between disparate security domains, which makes vendor-independent web single sign-on and secure e-business transactions possible. The Interop Lab will demonstrate vendor interoperability and the practical application of SAML v2.0 technology to solve real-world business problems." Note: The U.S. General Services Administration (GSA) announced that the E-Gov E-Authentication Interoperability lab's technical architecture is being expanded to support of a new SAML version 2.0, expected to be ratified as an OASIS Standard. 'Once the SAML 2.0 specification is officially released and is supported in the marketplace by at least 3 interoperable technology products, it is expected to be adopted by E-Authentication; the E-Authentication Interoperability Lab will begin testing products that support the SAML 2.0 specification shortly'..." See the OASIS Interop data sheet.
[January 12, 2005] "SAML 2: The Building Blocks of Federated Identity." By Paul Madsen. From XML.com (January 12, 2005). "As web services promise to enable integration between business partners through loose-coupling at the application and messaging layer, federation does so at the identity management layer by insulating each domain from the details of the others identity management infrastructure. SAML provides the federated identity building blocks on which other federated architectures can be constructed. With SAML 2.0 now providing a stable and full-featured federated identity security infrastructure, focus can now shift to this work. For instance, the Liberty Alliance's ID-Web Services Framework (Liberty ID-WSF) defines a framework for identity-based web services that leverages the SAML layer. Liberty ID-WSF uses SAML as the mechanism by which the authentication status of a user and the identity and authorizations of web sites can be communicated as part of a SOAP request for some piece of that user's personal information (e.g., their online calendar). Upon ratification as an OASIS Standard, expected in early 2005, SAML 2.0 is expected to become the primary standard for federated identity... SAML defines an XML-based framework for communicating security and identity (e.g., authentication, entitlements, and attribute) information between computing entities. SAML promotes interoperability between disparate security systems, providing the framework for secure e-business transactions across company boundaries. By abstracting away from the particulars of different security infrastructures (e.g., PKI, Kerberos, LDAP, etc), SAML makes possible the dynamic integration necessary in today's constantly changing business environments." See also the SAML 2.0 Committee Drafts.
[December 04, 2004] "SAML: The Secret to Centralized Identity Management." By Hank Simon. From Intelligent Enterprise (December 04, 2004). ['Complicated by too many systems, too many applications, and too many passwords, identity management is a major headache for most organizations. Can an intelligent, Web-services approach employing new standards ride to the rescue?'] "Identity management refers to provisioning, password management, and access control. Typically, access rights are stored in different locations, with separate access-control lists for individual applications and resources. Identity management must control data, people, and resources that are distributed across different locations. SAML enables Web-based security interoperability functions, such as single sign-on, across sites that are hosted by multiple companies. SAML supports secure interchange of authentication and authorization information by leveraging the core Web services standards of XML, Simple Object Access Protocol (SOAP), and Transport Layer Security (TLS). Many vendors, such as RSA, Netegrity, IBM, Oracle, BEA, Oblix, and Jericho have committed to SAML and are implementing the specification in their products. A SAML assertion uses the header in a SOAP message to pass though HTTP, transferring security information between an assertion authority and a relaying party. For example, a user can login at one site; a SAML assertion transfers the user authentication token; and the transferred token provides authentication to a remote site. A SAML package can include the authentication token as well as user attributes that can be tested against the rules engine for authorization and access control. It's important to note that SAML doesn't perform the authentication; rather, it transports the authentication information. In addition, SAML can use different authentication authorities, such as LDAP, Active Directory, and Radius, allowing for different identification methods such as password, biometric, Public Key Infrastructure (PKI), Secure Socket Layer (SSL), Kerberos, and so on. Then, as the transport, SAML passes the assertion information that the user is authenticated. In contrast, SAML doesn't perform authorization or transport access-control information..."
[December 02, 2004] Web Services Security: SAML Token Profile. Committee Draft, approved as an OASIS Standard. Reference: October 21, 2004. Edited by Phillip Hallam-Baker (VeriSign), Chris Kaler (Microsoft), Ronald Monzillo (Sun), and Anthony Nadalin (IBM). 31 pages. The WSS SAML Token Profile approved as an OASIS Standard describes how to use Security Assertion Markup Language (SAML) Version 1.1 assertions with the Web Services Security (WSS): SOAP Message Security specification. It defines how SAML assertions are carried in and referenced from <wsse:security> headers and describes how SAML assertions are used with XML Signature to bind the statements of the assertions (i.e., the claims) to a SOAP message. [source PDF]
[November 01, 2004] "Using SAML for SIP." By Hannes Tschofenig (Siemens), Jon Peterson (NeuStar, Inc), James Polk (Cisco), Douglas C. Sicker (University of Colorado at Boulder), and Marcus Tegnander (Siemens). IETF SIP Working Group. Internet Draft. Reference: 'draft-tschofenig-sip-saml-01.txt' October 25, 2004, expires: April 25, 2005. 36 pages. IETF ephemeral source URL: http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-01.txt. Previous version: http://xml.coverpages.org/draft-tschofenig-sip-saml-00.txt. ['This document describes how to use the Security Assertion Markup Language (SAML) to offer trait-based authorization. As such, it provides an alternative to existing authorization mechanisms for SIP.'] "This document proposes a method for using the Security Assertion Markup Language (SAML) in collaboration with SIP to acommodate richer authorization mechanisms and enable trait-based authorization where you are authenticated using roles or traits instead of identity. A motivation for trait based authorization and some scenarios are presented in J. Peterson, "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)." Security Assertion Markup Language (SAML) is an XML [language] for security information exchange that is being developed by OASIS. SAML enables users to gain access to multiple website resources without having to re-authenticate every time the domain changes. The first authentication would be transferred to subsequent domains using SAML. To provide trait-based authorization a few solutions are possible: authorization certificates, SPKI or extensions to the authenticated identity body (J. Peterson, "SIP Authenticated Identity Body (AIB) Format"). The authors selected SAML due to the amount of work done in the area of SAML which provides some assurance that this technology is mature enough..."
[June 29, 2004] "McNealy: Sun, Microsoft To Unveil Phase One of Partnership in Late Summer. Directory Interoperability for Single Sign-On Will Be Tackled First." By Elizabeth Montalbano. In CRN (June 29, 2004). "Sun and Microsoft plan to detail Phase One of their historic partnership in late summer, Sun Chairman and CEO Scott McNealy said Tuesday at JavaOne. The first phase of the partnership will be to 'solve single sign-on' and facilitate interoperability between the LDAP model of the directory and identity management products in Sun's Java Enterprise System and Microsoft ActiveDirectory, McNealy told attendees in his morning keynote at Sun's annual Java developer confab in San Francisco. Once Sun and Microsoft make their software interoperable, 'users can log into the network once without having to remember multiple passwords and have their authentication travel across software infrastructure from both Sun and Microsoft,' McNealy said. Applications that run on both systems also can take advantage of the same infrastructure for network identity. 'This should make for more efficient consumer and enterprise use,' he said. Enabling single sign-on for users across multiple Web sites, particularly for e-commerce users, has been a tricky issue. Sun and a group of partner companies initiated and supported the Liberty Alliance, which leverages the Security Assertion Markup Language (SAML) specification to enable single sign-on, while Microsoft for a time planned its own project, HailStorm, to collect user information and authenticate users across multiple sites. But users were uncomfortable with the idea of Microsoft owning all of their personal information, so HailStorm didn't fly as expected..."
[June 16, 2004] "application/saml+xml Media Type Registration." By Jeff Hodges (Sun Microsystems). IETF Network Working Group. Internet Draft. Reference: 'draft-hodges-saml-mediatype-00'. June 13, 2004, expires December 12, 2004. "The SAML specification sets, SAML V1.0 and SAML V1.1, are work products of the OASIS Security Services Technical Committee (SSTC). The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. For example, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party. This document defines a MIME media type 'application/saml+xml' for use with the XML serialization of SAML (Security Assertion Markup Language) assertions, or other SAML-defined objects..."
[June 10, 2004] "Federation Acceleration." By Dan Farber. In ZDNet Tech Update (June 08, 2004). "Federated identity is beginning to gain some traction among corporations, according to a survey conducted by Ping Identity, a provider of federated identity management solutions and the founding sponsor of SourceID, an open source community focused on federation efforts, such as SAML, Liberty Alliance and WS-Federation. The survey, gleaned from nearly 100 responses by registered downloaders of SourceID, showed a strong increase of federations in production, rising from 1 percent to 7 percent between the first and second quarters of this year. Over 50 percent of those surveyed thought they would engage in between 1 and 3 federations within the next 24 months. Only 6 percent surveyed anticipated participation in more than 10 federations in the same period. Ease-of-integration and vendor interoperability were cited as the most important characteristics of federation products, with single-sign on (SSO) amongst partners cited as the primary use case desired. Currently, SAML 1.1 is the dominant protocol used for federation. Vendors have announced support for the Liberty Alliance Liberty ID-FF 1.1, but few are shipping in a substantial way, according to Eric Norlin, senior vice president of marketing at Ping Identity. The survey indicated that interest in SAML 2.0 and WS Federation will begin to ramp up significantly in the latter part of 2004 and continue throughout 2005..."
[Febuary 20, 2004] "Netegrity to Discuss Next Generation of SAML at RSA Conference." - "Netegrity, Inc., a leading provider of identity and access management solutions, today announced that Prateek Mishra, Director of Technology and Architecture at Netegrity and co-chair of the OASIS SAML Committee, will deliver a presentation at the RSA Conference discussing the next version of SAML (Security Assertion Markup Language). Mishra's presentation titled 'SAML 2.0: Unified Foundation for Federated Security' will be presented as part of the RSA Conference Standards Track on Tuesday, February 24th at 4:15 pm PT. Netegrity will also be exhibiting at the RSA Conference (Booth #1421) where the company will showcase its identity and access management solutions, including Netegrity's provisioning solution, Netegrity IdentityMinder eProvision. Mishra's presentation will discuss the new features of SAML 2.0 and how it brings together disparate efforts in order to create a single federated security umbrella. SAML 2.0 will build upon SAML 1.0 deployments and integrate with the enhanced functionality of the Liberty ID-FF (Identity Federation Framework) layers. In addition, Mishra will discuss the relationship between SAML 2.0 and other proposed standards, such as WS-Security, and how they jointly provide or