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
- Dashboard: OASIS Security Services (SAML) TC
- SSTC FAQ document. "This document helps to answer frequently asked questions about SAML (Security Assertion Markup Language)."
- SAML TC Ballots
- 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
[February 23, 2010] Federal Identity, Credentialing, and Access Management: Security Assertion Markup Language (SAML) 2.0 Profile. Version 0.1.0. Status: Draft. Date: February 17, 2010. 31 pages. Edited by Terry McBride, Matt Tebo, John Bradley, and Dave Silver. Document posted to the OASIS Security Services (SAML) TC discussion list ['[email protected]'] by John Bradley. ""This is the first draft of the U.S. Federal ICAM SAML 2.0 Profile. This is a work in progress, as such it is pre-decisional. It is submitted to the SSTC for feedback. This Profile is based on existing SSTC SAML 2.0 profiles... It is not a final ICAM specification. It has also been submitted to the Kantara eGov Working Group for comment..." [Source .doc, and cache]
"Security Assertion Markup Language (SAML) 2.0 Profile as described in this document has been adopted by Federal Identity, Credential, and Access Management (ICAM) for the purpose of Level of Assurance (LOA) 1, 2, and 3 identity authentication and holder-of-key assertions for binding keys or other attributes to an identity at LOA 4. Proper use of this Profile ensures that implementations: (1) Meet Federal standards, regulations, and laws; (2) Minimize risk to the Federal government; (3) Maximize interoperability; (4) Provide end users (e.g., citizens) with a consistent context or user experience at a Federal Government site...
This Profile is a deployment profile based on the Organization for the Advancement of Structured Information Standards (OASIS) SAML 2.0 specifications, and the Liberty Alliance eGov Profile v.1.5. This Profile relies on the SAML 2.0 Web Browser SSO Profile to facilitate end user authentication. This Profile does not alter these standards, but rather specifies deployment options and requirements to ensure technical interoperability with Federal government applications. Where this Profile does not explicitly provide guidance, the standards upon which this Profile is based take precedence. In addition, this Profile recognizes the eGov Profile conformance requirements , and to the extent possible reconciles them with other SAML 2.0 Profiles. The objective of this document is to define the ICAM SAML 2.0 Profile so that persons deploying, managing, or supporting an application based upon it can fully understand its use in ICAM transaction flows...
In general, the SAML 2.0 protocol facilitates exchange of SAML messages (requests and/or responses) between endpoints. For this Profile, messages pertain primarily to the exchange of an identity assertion that includes authentication and attribute information. Message support for additional features is also available. In ICAM, the endpoints are typically the Relying Party (RP) and the Identity Provider (IdP). SAML 2.0 Profile defined herein includes the following features: single sign-on, session reset, and attribute exchange. In addition, this Profile defines two main SAML 2.0 use cases: the end user starting at the RP, and the end user starting at the IdP. Use case diagrams and sequence diagrams are provided to illustrate the use cases. Privacy, security, and end user activation are also discussed. Programmed trust (a mechanism to indicate to RPs which IdPs are approved for use within ICAM) is also discussed, and a high-level process flow diagram is provided to illustrate the concept.
The Profile concludes with detailed technical guidance that scopes SAML 2.0 for ICAM purposes. Like most specifications, SAML 2.0 provides options. Where necessary, ICAM specifies or removes options in order to achieve better security, privacy, and interoperability. The Technical Profile section addresses the authentication request and response, metadata, and transaction security. This Profile does not recommend Single Log-out and IdP Discovery. .."
[January 15, 2010] "A SASL Mechanism for SAML." Edited by Klaas Wierenga (Cisco Systems, Inc) and Eliot Lear (Cisco Systems GmbH). IETF Network Working Group, Standards Track Internet Draft. January 15, 2010, expires July 19, 2010. "This memo specifies a SASL mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL." Details: "Security Assertion Markup Language (SAML) is a multi-party protocol (or rather set of protocols) that provides a means for a user to offer identity assertions and other attributes to a relying party (RP) via the help of an identity provider (IdP). Simple Authentication and Security Layer (SASL) is a generalized mechanism for identifying and authenticating a user and for optionally negotiating a security layer for subsequent protocol interactions. [Simple Authentication and Security Layer (SASL) IETF Standards Track RFC #4422, edited by Alexey Melnikov and Kurt D. Zeilenga.] SASL is used by application protocols like IMAP, POP and XMPP. The effect is to make modular authentication, so that newer authentication mechanisms can be added as needed. This memo specifies just such a mechanism. As currently envisioned, this mechanism is to allow the interworking between SASL and SAML in order to assert identity and other attributes to relying parties. As such, while servers (as relying parties) will advertise SASL mechanisms (including SAML), clients will select the SAML SASL mechanism as their SASL mechanism of choice. The SAML mechanism described in this memo aims to re-use the available SAML deployment to a maximum extent and therefore does not establish a separate authentication, integrity and confidentiality mechanism. It is anticipated that existing security layers, such as Transport Layer Security (TLS), will continued to be used..."
[August 11, 2008] SAML V2.0 Metadata Interoperability Profile. Edited by Scott Cantor (Internet2). Working Draft Version 01. August 09, 2008. 12 pages. Notice posted to the SAML TC discussion list by Scott Cantor on August 10, 2008. See also the Call For Profiling Intentions and listing of (proposed) SAML profiles. Summary: "This profile describes a set of rules for SAML metadata producers and consumers to follow such that federated relationships can be interoperably provisioned, and controlled at runtime in a secure, understandable, and self-contained fashion."
Excerpts:
The SAML V2.0 metadata specification (Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0) defines an XML schema and a set of basic processing rules intended to facilitate the use of SAML profiles, and generally any profile or specification involving SAML. Practical experience has shown that the most complex aspects of implementing most SAML profiles, and obtaining interoperability between such implementations, are in the areas of provisioning federated relationships between deployments, and establishing the validity of cryptographic signatures and handshakes. Because the metadata specification was largely intended to solve those exact problems, additional profiling is needed to improve and clarify the use of metadata in addressing those aspects of deployment.
This profile is the product of the implementation experience of several SAML solution providers and has been widely deployed and successfully used in furtherance of the goal of scaling deployment beyond small numbers into the hundreds and thousands of sites, without sacrificing security. Experience has shown that the most frustrating part of using SAML (and many similar technologies) is that products approach the use of cryptography and trust in wildly inconsistent ways, and often the libraries that such products depend on do the same in their own domains. Key management is hard, and often relies on complicated tools with cryptic output. Standards only help insofar as they can be understood and widely implemented; this has generally not occurred above a basic level of cryptographic correctness. A formal PKI is a tremendously complex, and some would say intractable, goal; it could be argued that SAML itself is a reaction to this. Often, the security of deployments is based on a presumption that required practices like revocation checking are being performed, when in fact they are not.
The purpose of this profile is to guarantee that in a correct implementation, all security considerations not deriving from the particular cryptography used (i.e. algorithm strength, key sizes) can be isolated to metadata exchange and acceptance, and not affect the runtime processing of messages. If a deployment can be shown to rely solely on metadata to derive trust, it can be reasoned about in a much simpler way, and the security exposures can be well understood..." [Source: PDF and ODT]
[August 11, 2008] SAML V2.0 Information Card Token Profile. Edited by Scott Cantor (Internet2). Working Draft Version 02. August 08, 2008. 13 pages. Notice posted to the SAML TC list by Scott Cantor on August 08, 2008. Draft version 02 incorporates feedback, refines the Recipient/Audience rules, adds a signing requirement, and enumerates assertion validation processing rules. Summary: "This profile describes a set of rules for identity providers and relying parties to follow when using SAML V2.0 assertions as managed information card security tokens, so that interoperability and security is achieved commensurate with other SAML authentication profiles." Excerpts:
Microsoft has defined a set of profiles for acquring and delivering security tokens, collectively referred to as "Information Card" technology. These profiles are agnostic with respect to the format and semantics of a security token, but interoperability between issuing and relying parties cannot be achieved without additional rules governing the creation and use of the tokens exchanged. This document describes a set of rules for the use of SAML V2.0 assertions, as defined in SAML2 Core, as security tokens within the Information Card architecture... Identity providers and relying parties employing the Identity Selector Interoperability Profile (ISIP) [A. Nanda, Identity Selector Interoperability Profile V1.0, Microsoft, April 2007] to request and exchange security tokens are able to use arbitrary token formats, provided there is agreement on the token's syntax and semantics, and a way to connect the token's content to the supported protocol features. This profile provides a set of requirements and guidelines for the use of SAML V2.0 assertions as security tokens that, where possible, emulates existing SAML V2.0 authentication profiles so as to limit the amount of new work that must be done by existing software to support the use of Information Cards. It also provides for the use of SAML assertions in this new context that is safe, and consistent with best practices in similar contexts. This profile does not seek to alter the required behavior of existing identity selector software, or conflict with the profiles defined by ISIP...
2.4.5 Relying Party Requirements, Assertion Validity: "Relying parties SHOULD evaluate assertions using the rules defined by SAML2Core [Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0] (and SAML2Prof [Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0] in the case of the defined subject confirmation methods). Invalid assertions SHOULD NOT be used to authenticate clients that present them. In assessing validity, a relying party MUST verify the signature over the assertion, evaluate any conditions present, and successfully evaluate at least one 'saml:SubjectConfirmation' element in the assertion based on the presentation of the assertion. This may include verifying that the 'NotOnOrAfter' attribute in the 'saml:SubjectConfirmationData' (if present) has not passed, subject to allowable clock skew between it and the identity provider. If the 'saml:SubjectConfirmationData' includes an Address attribute, the relying party MAY check the client address against it. In the case of the "holder-of-key" method, the relying party MUST establish proof of possession by the client of the key identified by the accompanying 'ds:KeyInfo' element, such as through the use of a message signature or authentication over a secure transport. The exact means are out of scope. In the case of the "bearer" method, the relying party MUST ensure that assertions are not replayed, by maintaining the set of used ID values for the length of time for which the assertion would be considered valid based on the NotOnOrAfter attribute in the 'saml:SubjectConfirmationData' element...
2.6 Security Considerations: "The Information Card model's support for hiding the identity of the relying party from the identity provider, combined with constraints on the implementation of the model for use with web browsers, leads to requests for 'unconstrained' bearer assertions with no audience or subject confirmation conditions on use. This is extremely dangerous and insecure, even if assertion validity is extremely short term. This profile recommends against such a practice and urges implementations, if they do support such behavior, to enable deployers to disable it by requiring requests for bearer assertions be accompanied by the identity of the relying party. Identity providers should generally make every attempt to encrypt the assertions they produce if a key for the relying party can be established. If encryption is not used, then the identity provider should be aware of the potential for exposure of the assertion's contents, both to the requester and potentially to network observers if TLS/SSL is not used (particularly between the requester and the eventual relying party)..." [Source: PDF, ODT, and PDF diff version]
[June 28, 2008] "Use of WS-TRUST and SAML to Access a CVS." By David Chadwick and Linying Su (University of Kent). 11-June-2008. Copyright © Open Grid Forum (2006-2008). See the associated posting. This OGF final draft document provides information to the Grid community about a proposed standards track protocol. It defines a protocol for an authorization component to access an external credential validation service (CVS) prior to calling a policy decision point (PDP). The protocol is a profile of a SAML attribute assertion carried by WS-Trust. The CVS is a necessary functional component in authorization which performs the task of validating the user's presented credentials before the valid attributes (extracted from the credentials) are used by the policy decision point (PDP) in order to make an access control decision. The protocol is a profile of a SAMLv2 attribute assertion carried by WS-Trust. It allows tokens/credentials in to be presented in any format to the CVS, but always returns tokens formatted as XACML attributes, so that they are ready for submission to the PDP. There are different ways in which the CVS access protocol might be used. The protocol might be called by the context handler in either the PEP or the PDP, and might carry the authenticated name of the subject with or without a bag of credentials, and with or without references to various CISs that should be contacted to pull credentials. The PEP may provide any arbitrary set of credentials, e.g., member of university X, member of grid project Y, registered doctor, certified engineer etc. issued by any arbitrary set of attribute authorities (AAs) or credential issuers, in any standard format; as well as any arbitrary set of references (meta-information) to credential issuing services. This document does not specify how the PEP obtains these credentials or CIS meta-information, but they might be provided by the end user, or the end user's client software, or by another component of the authorization infrastructure, such as an out of band meta-data transfer service. The target resource will only trust a limited set of CISs, and these trust relationships will be configured into its Credential Validation Service (CVS) in the form of a Credential Validation Policy. A CVS will validate the presented credentials according to its configured Credential Validation Policy, and will return the set of valid attributes (in XACML format) to the PEP. The PEP may then pass these to the PDP for it to make an access control decision... The CVS can operate in three ways — credential push mode, credential pull mode or both modes..." [source .doc, cache]
[June 22, 2008] "SAML V2.0 Information Card Token Profile." Edited by Scott Cantor (Internet2). Working Draft 01. June 22, 2008. 13 pages. Submitted to the OASIS Security Services (SAML) TC. See the associated TC announcement (for .odt format, also prepared in PDF format). "Microsoft has defined a set of profiles for acquring and delivering security tokens, collectively referred to as 'Information Card' technology. These profiles are agnostic with respect to the format and semantics of a security token, but interoperability between issuing and relying parties cannot be achieved without additional rules governing the creation and use of the tokens exchanged. This profile describes a set of rules for identity providers and relying parties to follow when using SAML 2.0 assertions as managed information card security tokens, so that interoperability and security is achieved commensurate with other SAML authentication profiles... Identity providers and relying parties employing the Identity Selector Interoperability Profile V1.0 (ISIP) (Microsoft) to request and exchange security tokens are able to use arbitrary token formats, provided there is agreement on the token's syntax and semantics, and a way to connect the token's content to the supported protocol features. This profile provides a set of requirements and guidelines for the use of SAML 2.0 assertions as security tokens that, where possible, emulates existing SAML 2.0 authentication profiles so as to limit the amount of new work that must be done by existing software to support the use of Information Cards. It also provides for the use of SAML assertions in this new context that is safe, and consistent with best practices in similar contexts. This profile does not seek to alter the required behavior of existing identity selector software, or conflict with the profiles defined by ISIP. While the SAML V2.0 specification defines an identity provider solely in terms of the SAML Authentication Request protocol, the term is generally applicable to an entity that issues authentication assertions by means of other, similar protocols. In this case, the identity provider functions as an IP/STS in the Information Card vocabulary, and issues assertions in response to 'wst:RequestSecurityToken' messages (WS-Trust). As defined by ISIP, the request contains information that provides input into the assertion creation process. The following sections outline requirements for interpreting this input and the resulting assertion content..."
[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..."
[October 29, 2004] "Proving a WS-Federation Passive Requestor Profile." By Thomas Gross (IBM Research Division, Rüschlikon, Switzerland) and Birgit Pfitzmann (IBM Research Division, Rüschlikon, Switzerland). Paper presented at the 2004 ACM Workshop on Secure Web Services. October 29, 2004. George W. Johnson Center at George Mason University, Fairfax, VA, USA. Held in conjunction with the Eleventh ACM Conference on Computer and Communications Security (CCS-11). Proceedings, pages 54-64. "Currently, influential industrial players are in the process of realizing identity federation, in particular the authentication of browser users across administrative domains. WS-Federation is a joint protocol framework for Web Services clients and browser clients. While browser-based federation protocols, including Microsoft Passport, OASIS SAML, and Liberty besides WS-Federation, are already widely deployed, their security is still unproven and has been challenged by several analyses. One reason is a lack of cryptographically precise protocol definitions, which impedes explicit design for security as well as proofs. Another reason is that the security properties depend on the browser and even on the browser user. We rigorously formalize a strict instantiation of the current WS-Federation Passive Requestor Interop profile and make explicit assumptions for its general use. On this basis, we prove that the protocol provides authenticity and secure channel establishment in a realistic trust scenario. This constitutes the first positive security result for a browser-based identity federation protocol..." See the Workshop summary: "The main security protocols for Web Services, such as XML Security, WS Security, SAML, and XACML are now available or close to completion. Soon, we will have a basic set of building blocks for securing Web services and GRID computing. However, a number of challenges are still to be met for Web services and GRID nodes to be fully secured and trusted. Also, the trend toward representing Web services semantics via Semantic Web standards such as RDFS and OWL is fostering the evolution of current security models and languages to deal with secure and trusted Web services orchestration. The SWS workshop explores these challenges, ranging from the advancement and best practices of building block technologies such as XML and Web services security protocols to higher level issues such as advanced metadata, trust establishment, risk management, and service assurance. This workshop continues the successful series of XML Security Workshop." [Source PDF via CiteSeer]
[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 organizations with a trusted model to enable secure Web services and federation. Netegrity was one of the original creators of the SAML specification and over the last three years has helped to drive industry adoption of SAML, including support for the SAML standard within both the Netegrity SiteMinder Web access management product and the Netegrity TransactionMinder Web services security product. The company also recently shipped Netegrity SiteMinder 6.0 which provides advanced federated security capabilities through enhanced support for SAML..."
[January 23, 2004] "SAML Tops Federation Projects Survey." By Dave Kearns. In Network World (January 09, 2004). Ping Identity, sponsor of the SourceID Web site, recently surveyed folks who downloaded its open-source Liberty Alliance tool kit. "When asked about the priority of federation protocols, it wasn't surprising that the Liberty Alliance protocols out-polled the WS-Federation protocol (favored by IBM and Microsoft) since the respondents were specifically those who downloaded a Liberty Alliance tool kit. But even adding together those who preferred Liberty phase II with those who preferred Liberty phase I (a total of 42% of the respondents) they were still outweighed (at 49%) by those who favored Versions 1.0, 1.1 and 2.0 of the Security Assertion Markup Language (SAML). SAML is the transport mechanism for the Liberty Alliance proposals, and one of the allowed transports for WS-Federation, but it appears that a number of projects are working directly with SAML and by-passing the 'higher' layers of the two competing standards. It might be that the projects being talked about are all early stage developments, with the SAML parts being worked on now while the developers look to see which of the two competing standards will emerge with an edge -- or, perhaps, a consolidation or merger might occur with one standard being created from the two we currently have. If you think that's a likely scenario, then it would be wise to put off any development at that upper level until the parameters of the eventual standard begin to take shape. Another of the survey questions asked downloaders what additional protocols were 'of interest' to them vis-à-vis federation. The big winner there was OASIS' Extensible Access Control Markup Language (XACML), with 49%, followed by Service Provisioning Markup Language (SPML) at 29%, and eXtensible Resource Identifier (XRI) with 14%. A scattering of other protocols took 8% of the responses. XRI could be considered a competitor to Universal Description, Discovery and Integration..." See also: (1) "Extensible Access Control Markup Language (XACML)"; (2) "XML-Based Provisioning Services"; (3) "OASIS TC Promotes Extensible Resource Identifier (XRI) Specification."
[December 16, 2003] "Security Analysis of the SAML Single Sign-on Browser/Artifact Profile." By Thomas Gross (IBM Zurich Research Laboratory). Paper presented Thursday, December 11, 2003 at the 19th Annual Computer Security Applications Conference (December 8-12, 2003, Las Vegas, Nevada, USA). With 21 references. "Many influential industrial players are currently pursuing the development of new protocols for federated identity management. The Security Assertion Markup Language (SAML) is an important standardized example of this new protocol class and will be widely used in business-to-business scenarios to reduce user-management costs. SAML utilizes a constraintbased specification that is a popular design technique of this protocol class. It does not include a general security analysis, but provides an attack-by-attack list of countermeasures as security consideration. We present a security analysis of the SAML Single Sign-on Browser/Artifact profile, which is the first one for such a protocol standard. Our analysis of the protocol design reveals several flaws in the specification that can lead to vulnerable implementations. To demonstrate their impact, we exploit some of these flaws to mount attacks on the protocol... We have deduced several recommendations for the design of browser-based protocols from our analysis. First of all, we strongly recommend that secure channels such as SSL 3.0 or TLS 1.0 with unilateral authentication for message transfer always be used. They outmatch normal transfer of signed and encrypted messages, as they provide authentication, freshness, and replay prevention. We also recommend including more explicitness measures into the messages. It is important to name protocol type, protocol step, source and destination of a message explicitly in the message. Such measures could for instance prevent attacks where multiple services of a site are involved.We recommend not only considering successful protocol runs, but also analyzing all states the protocol can reach. Especially error states may hide opportunities for attacks such as our referrer attack. We are convinced that the SAML Single Sign-on Browser/Artifact profile is in general a well-written protocol. In fact, it is one of the most carefully designed browser-based protocols in federated identity management. Nevertheless, several changes are required to improve its security and prepare for its broad application in industry..." [cache]
[October 20, 2003] "Navy Deploying Its Battle Plan: SAML." By Anne Chen. In eWEEK (October 20, 2003). "At the U.S. Navy's Space and Naval Warfare Systems Command, the battle plans to gain control of an it environment with an estimated 200,000 applications center on single-sign-on capabilities and the use of SAML... In 2001, Adm. William Fallon, vice chief of naval operations, created Task Force Web, an initiative to winnow the Navy's thousands of legacy applications. The program called for all Navy applications to be Web-enabled by next year and available to some 720,000 Navy users via the Navy Enterprise Portal. The task proved to be much larger than anyone thought. At the time, the Navy had about 200,000 applications in use, many of which were deployed at the department level and overlapped with those in other Navy units. To control that environment, the Navy decided to deploy a portal based on a Web services architecture. It was decided the portal would be based on open standards, so the Navy chose to build its Web services architecture using the J2EE (Java 2 Platform, Enterprise Edition) environment. The Navy spent about $1 million to develop internally a middleware layer that enables the agency to substitute standards or data definitions without forcing changes to user services or underlying databases. This portal connector links the Navy's disparate legacy applications and Web services... SPAWAR -- which acquires and deploys the technology used in ships and airplanes, as well as in network operating centers in the continental United States and overseas -- decided single sign-on would be the most effective way to handle identity management for users to access the Navy Enterprise Portal... Because of the Navy's need to support personnel and contractors stationed around the globe, SPAWAR chose to support single-sign-on capabilities that are managed as a reusable Web service. For identity management authorization, SPAWAR decided to use open standards, including SAML; XML; Simple Object Access Protocol; and Universal Description, Discovery and Integration. This led to the Navy's decision earlier this year to pilot Oblix Inc.'s NetPoint Identity Management and Access Control Solution 6.1 because Oblix supports SAML... In the initial phase of the program, SPAWAR deployed NetPoint to handle SAML-enabled, single-sign-on authentication of 5,500 users aboard the battleship USS Teddy Roosevelt, enabling them to access applications that do everything from tracking parts to pinpointing the location of enemy vessels. NetPoint handles the exchange of SAML security assertions between users on the ship and servers onshore, and it automatically logs users in to the Navy Enterprise Portal and its available applications. The deployment of the project was successful enough that the Navy is planning to use NetPoint to provide single-sign-on capabilities to all 720,000 naval users and civilian contractors who access the Navy Marine Corps Intranet. Eventually, that number could reach as high as 3 million because all users associated with the Navy will be able to have their identity managed this way..."
[September 22, 2003] "RSA Security Announces New Products to Deliver on Identity and Access Management Strategy. RSA ClearTrust V5.5 Software Enhances Identity Infrastructures with Tighter Integration with Microsoft Platforms and New User Management and Federated Identity Management Capabilities." - "RSA Security Inc., the most trusted name in e-security, today announced RSA ClearTrust v5.5 web access management software. Delivering advanced user management capabilities, web services support (including SAML v1.1-compliant federated identity management capabilities), robust transactional authorization functionality, and unparalleled integration with Microsoft platforms, RSA Security demonstrates progress in its Identity and Access Management strategy with this new release of RSA ClearTrust software. RSA Security's Identity and Access Management strategy includes an integrated architecture (codenamed NEXUS), new products and strategic alliances that enable organizations to quickly derive quantifiable business value -- including reduced costs, enhanced revenue opportunities and increased user productivity -- from their online applications by securely leveraging digital identities across their infrastructure. "Global enterprises are today faced with the increasing complexity of securely managing expanded populations of users accessing internal and external applications and systems," said Ray Wagner, research director, Gartner Inc. "To meet these challenges, it is critical that they implement a flexible identity management solution that integrates easily with existing technology, protocols and standards. Features like innovative user administration, support for federated identity initiatives, and strong out-of- the-box integration options increase the value of these solutions." ... RSA ClearTrust v5.5 software offers new functionality in the primary areas of concentration within RSA Security's Identity and Access Management strategy, including: (1) Identity Authority Services: The RSA ClearTrust Federated Identity Management Module provides the first commercially available Security Assertions Markup Language (SAML) functionality for generating and consuming SAML v1.1 assertions, enabling customers to leverage identities across business boundaries to drive new relationships and business models. Features of the implementation include full web-based administration, simple installation and configuration, a time-saving policy cloning feature and advanced built-in security capabilities, including digital signatures, certificate validation and authentication mapping between different sites. (2) Access Authority Services: Transactional Smart Rules extends the business rules and user properties of RSA ClearTrust software, enabling real-time dynamic authorization decisions based on attributes from multiple data sources, including databases, directories, XML, flat files or web services. This powerful capability allows customers to implement sophisticated authorization rules using real-time business data and processes..."
[September 22, 2003] "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." - "The OASIS standards consortium today announced that its members have approved the Security Assertion Markup Language (SAML) version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification. SAML provides an XML-based framework for exchanging authentication and authorization information, enabling single sign-on -- the ability to use a variety of Internet resources without having to log in repeatedly. 'SAML has gained widespread industry adoption as a basis for federated identity and security environments,' said James Kobielus, senior analyst at Burton Group. 'Clearly, SAML is a living, evolving standard, and OASIS has, with the new version 1.1, incorporated changes that reflect real-world experience with SAML version 1.0.' According to Prateek Mishra of Netegrity, co-chair of the OASIS Security Services Technical Committee, 'Prior to SAML, there was no XML-based standard that enabled exchange of security information between a security system (such as an authentication authority) and an application. SAML provides a way to specify authentication, attribute, and authorization decision statements. It also specifies a Web services-based request/reply protocol for exchanging these statements.' 'The SAML 1.1 standard introduces important enhancements that improve its interoperability and utility to other Web services security efforts in the industry. This can be seen through the adoption of SAML 1.1 as a foundation for the Liberty Alliance's Identity Federation Framework, the implementation of SAML 1.1 by the Internet2/MACE Shibboleth project, and the development of a SAML profile by the OASIS Web Services Security (WSS) Technical Committee for using SAML with WS-Security,' added Rob Philpott of RSA Security, co-chair of the OASIS Security Services Technical Committee. 'The growing participation of OASIS member companies in SAML's development and our committee's increasing collaboration with other security-related standards groups demonstrate the value of OASIS SAML standardization to the industry.' Liberty Alliance Management Board president, Michael Barrett, also vice president of Internet Strategy at American Express, commented, 'Collaboration between standards organizations is critical to industry momentum and to ensure new technologies like single sign-on and Web services succeed. Organizations looking to benefit from these new technologies need access to proven, interoperable, and secure standards that they can build on for the next new technology. Open standards like SAML and Liberty's specifications have been proven to meet that need.' Members of the OASIS Security Services Technical Committee include Baltimore Technologies, BEA Systems, Computer Associates, Entrust, Hewlett-Packard, Netegrity, Oblix, OpenNetwork, Reactivity, RSA Security, SAP, Sun Microsystems, Verisign, and other security software vendors, financial institutions, government agencies, and academia..."
[September 23, 2003] "OASIS Ratifies SAML 1.1. RSA Supports Latest Version in Products." By Paul Roberts. In InfoWorld (September 19, 2003). "The OASIS Internet standards consortium said Monday that its members ratified SAML (Security Assertion Markup Language) Version 1.1 as an official standard, approving changes to the specification will improve interoperability with other Web services security standards. The vote assigns the highest level of OASIS (The Organization for the Advancement of Structured Information Standards) ratification to SAML 1.1 and could open the door for wider adoption of the XML (Extensible Markup Language) framework for companies using Web services to conduct high value transactions, according to Prateek Mishra of Netegrity Inc., co-chair of the OASIS Security Services Technical Committee. SAML is a standard that supports so-called 'federated identity' systems in which user authentication and authorization information is securely exchanged between Web sites within an organization or between organizations. SAML enables a user to sign on once to Web-enabled services, instead of having to repeatedly log in when they move from one Web site or Web-enabled application to another... The new version of SAML includes a number of updates and fixes for problems identified in the 1.0 standard, he said. In particular, SAML 1.1 revised guidelines for the use of digital certificates to sign SAML user authentication exchanges, known as SAML assertions. SAML 1.0 standards were vague about how to digitally sign SAML assertions, creating interoperability problems between different companies implementing Web services using the 1.0 standard, Mishra said. Only a 'small group' of companies are currently interested in using digital certificates to sign SAML assertions. However, that group is growing, as companies look for ways to exchange sensitive data with employees and business partners while also verifying that digital transactions took place -- a capability known as nonrepudiation... Having handed off the SAML 1.1 standards, OASIS's Security Services Technical Committee is now at work on the SAML 2.0 specification, Mishra said. That version will come with major additions to the standard based on feedback from large companies. Among other things, the group is looking at ways to implement distributed log out, in which three or more Web sites that share a single login session will synchronize when a user terminates that session. OASIS also wants to harmonize SAML 2.0 with the Liberty Alliance's ID-FF layer, another federated identity, single-sign on standard..." See the announcement, "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."
[August 19, 2003] "Use of SAML in the Community Authorization Service." By Von Welch, Rachana Ananthakrishnan, Sam Meder, Laura Pearlman, and Frank Siebenlist. Working paper presented to the OASIS Security Services TC. August 19, 2003. 5 pages. "This document describes our use of SAML in the upcoming release of our Community Authorization Service. In particular we discuss changes we would like to see to SAML to address issues that have come up both with current and planned development. A virtual organization (VO) is a dynamic collection of resources and users unified by a common goal and potentially spanning multiple administrative domains. VOs introduce challenging management and policy issues, resulting from often complex relationships between local site policies and the goals of the VO with respect to access control, resource allocation, and so forth. In particular, authorization solutions are needed that can empower VOs to set policies concerning how resources assigned to the community are used -- without, however, compromising site policy requirements of the individual resources owners. The Community Authorization Service (CAS) is a system that we have developed as part of a solution to this problem. CAS allows for a separation of concerns between site policies and VO policies. Specifically, sites can delegate management of a subset of their policy space to the VO. CAS provides a fine-grained mechanism for a VO to manage these delegated policy spaces, allowing it to express and enforce expressive, consistent policies across resources spanning multiple independent policy domains. Both past and present CAS implementations build on the Globus Toolkit middleware for Grid computing, thus allowing for easy integration of CAS with existing Grid deployments. While our currently released implementation of CAS uses a custom format for policy assertions, the new version currently in development uses SAML to express policy statements. In this document we describe our use of SAML with some issues we have encounters with its use..." Note on CAS: "Building on the Globus Toolkit Grid Security Infrastructure (GSI), Community Authorization Service (CAS) allows resource providers to specify course-grained access control policies in terms of communities as a whole, delegating fine-grained access control policy management to the community itself. Resource providers maintain ultimate authority over their resources but are spared day-to-day policy administration tasks (e.g., adding and deleting users, modifying user privileges)... The second Alpha release (alphaR2) of the Community Authorization Service includes a CAS server, CAS user and administrative clients as well as a CAS-enabled GridFTP server. Other portions of the Globus Tookit (e.g., the Gatekeeper, MDS, replica management) are not CAS-enabled at this time and are not included in this release... The Globus Toolkit uses the Grid Security Infrastructure (GSI) for enabling secure authentication and communication over an open network. GSI provides a number of useful services for Grids, including mutual authentication and single sign-on... GSI is based on public key encryption, X.509 certificates, and the Secure Sockets Layer (SSL) communication protocol. Extensions to these standards have been added for single sign-on and delegation. The Globus Toolkit's implementation of the GSI adheres to the Generic Security Service API (GSS-API), which is a standard API for security systems promoted by the Internet Engineering Task Force (IETF)..."
[August 19, 2003] "Use of SAML for OGSA Authorization." From the Global Grid Forum OGSA Security Working Group. Submitted for consideration as a recommendations document in the area of OGSA authorization. GWD-R, June 2003. 16 pages. "This document defines an open grid services architecture (OGSA) authorization service based on the use of the security assertion markup language (SAML) as a format for requesting and expressing authorization assertions. Defining standard formats for these messages allows for pluggability of different authorization systems using SAML. There are a number of authorization systems currently available for use on the Grid as well as in other areas of computing, such as Akenti, CAS, PERMIS, and VOMS. Some of these systems are normally used in decision push mode by the application -- they act as services and issue their authorization decisions in the form of authorization assertions that are conveyed, or pushed, to the target resource by the initiator. Others are used in decision pull mode by the application -- they are normally linked with an application or service and act as a policy decision maker for that application, which pulls a decision from them... With the emergences of OGSA and Grid Services, it is expected that some of these systems will become OGSA authorization services as mentioned in the OGSA Security Roadmap. OGSA authorization services are Grid Services providing authorization functionality over an exposed Grid Service portType. A client sends a request for an authorization decision to the authorization service and in return receives an authorization assertion or a decision. A client may be the resource itself, an agent of the resource, or an initiator or a proxy for an initiator who passes the assertion on to the resource. This specification defines the use of SAML as a message format for requesting and expressing authorization assertions and decisions from an OGSA authorization service. This process can be single or multi-step. In single step authorization, all the information about the requested access is passed in one SAML request to the authorization service. In multi-step authorization, the initial SAML request passes information about the initiator, and subsequent SAML requests pass information about the actions and targets that the initiator wants to access. The SAML AuthorizationDecisionQuery element is defined as the message to request an authorization assertion or decision, the DecisionStatement element is defined as the message to return a simple decision, and the AuthorizationDecisionStatement the method for expressing an authorization assertion. By defining standard message formats the goal is to allow these different authorization services to be pluggable to allow different authorization systems to be used interchangeably in OGSA services and clients..."
[August 13, 2003] "Southwest Airlines Deploys Industry Leading SAML Implementation On Oblix NetPoint. NetPoint SAML Solution Enables User Authentication and Authorization Across Corporate Extranets." - "Oblix, a leading developer of identity-based security solutions, today announced that Southwest Airlines has successfully deployed the Oblix NetPoint Identity Management and Access Control Solution with comprehensive support for SAML. As a result of the deployment, Southwest has reduced administration costs associated with password resets and account expirations, while simultaneously promoting its 'family' corporate culture by helping more employees feel connected via easy access to business-critical information when they need it. Hundreds of Southwest engineers and mechanics can now access technical documentation and other proprietary content housed on its aircraft supplier's secure Web site by using SAML-enabled single sign-on. Oblix NetPoint facilitates a seamless and secure Southwest user experience by exchanging SAML assertions between Southwest and supplier's security systems, in effect forwarding a SAML security assertion that automatically logs the employee into the supplier's remote system. 'Southwest Airlines' history of success is built on giving our Customers a 'positively outrageous' level of service. Consistently getting them to their destination on-time is a big part of that,' said Brian Buege, manager of Application Frameworks, Southwest Airlines. 'By deploying Oblix NetPoint integrated with SAML, our mechanics can spend more time keeping our fleet airborne and our flights on-time rather than searching for lost passwords or related information. A SAML-integrated identity and access management infrastructure delivers significant business benefits, including reduced administrative costs and increased productivity.' SAML, Security Assertion Markup Language, is an XML-based security standard for exchanging user authentication and authorization information. By combining SAML with Oblix NetPoint's identity management functionality, Southwest now securely and cost-effectively manages its employee identity information across disparate corporate boundaries, and can also integrate with partner/supplier security systems..."
[July 24, 2003] "Eve Maler of Sun Microsystems Discusses the Future of Web Services Security." By Janice J. Heiss. From WebServices.org (July 24, 2003). In this article Janice J. Heiss speaks to Sun Microsystems' Eve Maler, vice-chair of the WS-I Basic Security Profile Working Group and currently coordinating editor of the SAML (Security Assertion Markup Language) Technical Committee, seeking an update on the development of Web services security. Maler: [As to when viable Web services security standards will be established] "It's best not to think in black and white terms. There are specifications appearing on the scene that attempt to secure different facets of Web services. As each specification becomes standardized and viable over time, the operation of Web services will be better protected... This may not be fully standardized until late in 2003 and it's important for this work to reflect a clear understanding of the problem space. And after that, there's going to be a lot more work on trust management. So improvements will occur as long as these processes take place in venues that allow the right experts to look at them... Traditional technologies won't always suffice [for Web services security]. First, the trust issues still haven't been fully solved in traditional computing; they haven't scaled to meet our expectations, and Web services present an opportunity to get this right. With Web services, end to end isn't the same as point to point. Messages are going between a requester and a responding service, but they may also pass through several intermediaries, and thus, several possible hubs. Therefore, a technology that focuses solely on securing the transport channel may not be sufficient. You need security technologies that persist past that transient part; without the XML security standards, they don't take advantage of the opportunities inherent in XML's granularity... Sun Microsystems is very concerned with the open specification of standards and the specification of systems that don't rely on a single hub to do all the jobs. We have heard some intimations that a system like Passport will ultimately be a federated system so that you won't always have to go through one Web site to start your journey online. That would be a good thing. The Liberty Alliance takes exactly this federated approach to managing and using your electronic identity. What's best is for all of the relevant security infrastructure for Web services to be standardized in an open venue to be seen by all the right eyes, and especially for the IPR (intellectual property rights) terms to be open enough so that implementations can be widely accepted. This is Sun's goal in participating in Web services security standardization, and it's the key for ensuring that no one company can create lock-in..."
[July 08, 2003] "Novell Helps Business Partners Securely Share Identity Information on the Web. Novell Ships the SAML Extension for Novell iChain, a Federated Identity Management Service." - "Novell today announced the general availability of the SAML extension for Novell iChain, a federated identity management service that allows companies to reach across the Internet to form secure, profitable relationships with business partners and customers. The concept of federated identity - securely sharing user information across organizational or geographic boundaries - is an important part of Novell Nsure secure identity management solutions, which not only address identity management within an organization but also beyond the firewall. 'The Internet has long held the promise of better, faster collaboration among business partners or customers; but often, establishing those connections raises serious concerns about security or is simply too complex,' said Justin Taylor, Novell's chief strategist for secure identity management. 'The advent of the SAML standard, and now the SAML extension for Novell iChain, changes that,' Taylor said. 'This new service from Novell allows user identity and attribute information to be shared securely over the Web, addressing a host of business problems - from establishing single sign-on between business partner Web sites to more sophisticated business relationships requiring the secure transmission of credit card information or home phone numbers.' The Security Assertion Markup Language (SAML) standard has emerged as the key element in establishing trusted business relationships over the Web. According to Burton Group analyst Phil Schacter, 'SAML is becoming a universal token format for applications to leverage a prior authentication event based on an open industry-wide standard. Both Liberty Alliance and the OASIS working group on WS-Security recognize and leverage SAML as part of the infrastructure for Web security. Early adopters are already taking advantage of SAML to deliver business services to partners based on a federated identity approach. By delivering a proxy-based SAML service, Novell is enabling its customers to more rapidly gain the operational and business benefits of federation strategies.' Securing business relationships using the SAML standard also helps lower development and administration costs. Without a standard method of authenticating and authorizing users, organizations would face costly, often non-reusable custom-coding projects. And the SAML extension takes those savings even further, thanks to the proxy-based architecture of Novell iChain. With it, customers can quickly deploy SAML-enabled services without having to make any changes to the actual Web servers..."
[May 13, 2003] "Web Services Security, Part 3." By Bilal Siddiqui. From O'Reilly WebServices.xml.com (May 13, 2003). "In the first article of this series, I explained why traditional network firewalls are inadequate to provide security to web service applications, which is why we need to implement web service security at the XML messaging layer. In the second article, I discussed signed and encrypted XML messages and a B2B scenario to elaborate the application of XML signature and encryption in web services. At the end of the second article, I introduced Web Services Security (WSS) and explained how WSS applies XML signature and XML encryption to SOAP messages. I also introduced the concept of security tokens and demonstrated the use of digital certificates as security tokens in WSS messages. In this article I discuss XML-based authentication and the sharing of authentication information across different applications, known as Single Sign-On (SSO). The Security Assertions Markup Language (SAML, often pronounced 'sam-ull') from OASIS helps reach this goal by wrapping authentication information in an XML format... For our purposes, authentication means verifying the identity of a user. When you check your e-mail, you enter your username and password to get authenticated. It is assumed that you have kept your password confidential. Therefore the knowledge of your password is used to make sure that you are the one who is trying to check your email. [An X509 certificate can be] a security token (just like a password) that the recipient of the WSS message can use in order to authenticate the user before allowing specially discounted rates for booking. A security token is presented to a gatekeeper in order for a user to get authenticated. Now imagine that the gatekeeper is guarding the main gate of a large building with many offices. Visitors are required to show their ID cards and get authenticated at the main gate. The gatekeeper checks the ID card by matching it with his internal record and then allows the visitor to enter the building... A possible solution to allow sharing of authentication information is to issue a temporary identification badge to a visitor at the main gate of the building. The gatekeeper at the main gate will issue a badge to each visitor after successful authentication. The identification badge will have a short expiry. The visitor will show the identification badge while entering each office. The office gatekeeper will check the validity of badge before allowing or disallowing a person to enter the office. Such scenarios are common in Enterprise Application Integration and B2B applications. Whether applications are running within or across the boundaries of an enterprise, the sharing of authentication information forms an important part of application integration effort. Naturally, the sharing of authentication information prevents each application from having to perform the entire authentication process... ... The next article of this series will put the pieces together and demonstrate various possibilities of using them to accomplish the goal of securing web services..."
[April 14, 2003] "Liberty Alliance Contributes Phase 1 Network Identity Specifications to OASIS for Consideration in SAML 2.0." - "The Liberty Alliance Project and OASIS today announced that the Liberty Alliance has contributed its version 1.1 federated network identity specifications to OASIS. The OASIS Security Services Technical Committee requested Liberty's contribution to permit possible incorporation of Liberty version 1.1 specification features in future versions of the OASIS Open Standard Security Assertion Markup Language (SAML). SAML, an XML-based security framework for authentication and authorization in Web services, serves as a key underpinning to the Liberty Alliance federated network identity architecture. In keeping with Liberty Alliance's philosophy to leverage existing open standards whenever possible and build new functionality only if needed, the Alliance incorporated SAML into its Phase 1 specifications introduced in 2002. The Liberty Alliance chose to extend SAML in version 1.1 to include additional security enhancements vital to identity management, such as opt-in account linking, simple session management and global log-out capabilities. For the benefit of SAML and Liberty implementers and the industry as a whole, Liberty Alliance is providing those extensions back to OASIS for future versions of SAML... 'Collaboration between standards groups enables the Web services industry to move forward at a pace that meets the needs of the market,' said Patrick Gannon, president and CEO of OASIS. 'As SAML evolves, it makes sense to leverage the work Liberty Alliance has already done in this area. Our mutual goal is to decrease time-to-market for new technology, enhance interoperability between products and drive broader adoption of open standards.' 'We will continue to work closely with OASIS as the Liberty Alliance federated identity architecture evolves,' said Michael Barrett, president of the Liberty Alliance Management Board and vice president for Internet strategy at American Express. 'The Alliance will continue to develop Liberty's Identity Federation Framework within the consortium, and plans to collaborate closely with OASIS on future enhancements'..." See "Liberty Alliance Specifications for Federated Network Identification and Authorization."
[April 11, 2003] "Liberty Alliance Submitting Spec to OASIS. Turning Work Over to Standards Body for First Time." By John Fontana. In InfoWorld (April 11, 2003). "Liberty will announce at next week's RSA Conference that the first phase of its work, which was completed in June 2002 and updated in January, will be turned over to the Organization for the Advancement of Structured Information Standards (OASIS). The first phase, which was renamed Identity Federation Framework (ID-FF) in March, is basically Liberty's Version 1.1 specification that outlines single sign-on and account sharing between partners with established trust relationships. The Liberty move may be a reaction to IBM Corp. and Microsoft Corp., who are not Liberty members, but are trying to create their own federated identity management framework built on WS-Security, an evolving Web services standard they created and submitted to OASIS... Draft specifications for Liberty's second and third phases of work, which now incorporate the WS-Security protocol for securing Web services messages, also will be introduced at RSA and will outline how to build a permission framework and sets of services for user identities that can be shared across the Internet. The second phase of Liberty 's work, called Identity Web Services Framework (ID-WSF), will allow islands of trusted partners to link to other islands of trusted partners and provide users with the ability to control how their identity information is shared. Phase 3, called Identity Services Interface Specifications (ID-SIS), will build services on top of ID-WSF. The two draft specifications are not being submitted to OASIS at this time but will be opened to the usual public review. 'I think it is significant that Liberty is ready to open up to a wider world than its own group,' says Prateek Mishra, co-chair of the Security Services technical committee at OASIS and director of technology and architecture at Netegrity, a Liberty Alliance member. Liberty 's Version 1.1 specification will become a foundation document to help create Version 2 of OASIS's Security Assertion Markup Language (SAML), according to sources. SAML 1.0 is a standard for exchanging authentication and authorization information and is incorporated into and extended by Liberty 's Version 1.1. The hope is that ID-WSF and ID-SIS will eventually extend SAML 2.0 to create a single standards-based environment for federated identity and sharing of identity credentials..." See also "Liberty Alliance Specifications for Federated Network Identification and Authorization."
[February 10, 2003] "Oblix Delivers Comprehensive SAML Integration to Provide Advanced Identity Management and Web Access Control. Oblix NetPoint 6.1 Enables Seamless User Authentication and Authorization Across Corporate Extranets Via Secure XML-Based Web Services Standard." - "Oblix, a leading developer of identity-based security solutions, today announced the shipping of the latest version of its identity management and access control solution, Oblix NetPoint 6.1 with comprehensive SAML integration. SAML, Security Assertion Markup Language, is an XML-based security standard for exchanging user authentication and authorization information. By combining SAML with Oblix NetPoint's identity management functionality, not only can companies securely and cost-effectively manage user identity information across corporate boundaries, they can now integrate their security systems as well. Oblix NetPoint's scalability to both internal and external users was one factor in Southwest Airlines' decision to choose Oblix NetPoint as a solution for identity management and Web access control... Oblix NetPoint's integration with SAML gives enterprises the ability to provide its users seamless access to business partners' online resources. For example, a company employee who has entered his or her user name and password into the corporate portal could have access to a Web-based application hosted by a partner's site without being required to enter his or her user credentials again. To achieve this seamless and secure user experience, Oblix NetPoint exchanges SAML assertions between the partners' security systems, in effect forwarding a SAML security assertion that automatically logs the employee into the remote system. Customers have already gained significant advantage from Web single sign-on combined with Oblix's unique identity management system, COREid, especially in large-scale deployments. By supporting SAML in Oblix NetPoint, customers now benefit from even tighter integration across disparate corporate extranets, further reducing the cost of doing business and increasing user satisfaction and productivity... Oblix has consistently focused on building interoperability and support for industry-wide standards into its products, and the incorporation of SAML into Oblix NetPoint furthers this strategy. In addition to its comprehensive SAML support, Oblix NetPoint also supports standards from key organizations, including OASIS, Web Services Interoperability (WS-I), Microsoft .NET and the Liberty Alliance. Because Oblix NetPoint is built to support existing and future standards for authentication and authorization, customers know that Oblix NetPoint will interoperate with their standard of choice. In addition to expanded SAML support, Oblix NetPoint now includes support for Critical Path InJoin Directory Server and a NetPoint Connector for WebSphere. The NetPoint Connector for WebSphere enables tight integration of Oblix NetPoint's single sign-on and identity management functionality with J2EE applications developed on the IBM WebSphere e-business platform..."
[February 10, 2003] "Netegrity Delivers SAML Affiliate Agent to Lower Cost and Complexity of Federated Security Across Partner Sites. Enables Companies to Securely Partner in Order to Provide Enhanced Services to Users." - "Netegrity, Inc., a leading provider of identity and access management solutions, today announced that it has delivered the Netegrity SAML (Security Assertion Markup Language) Affiliate Agent. Companies, especially in today's economy, are leveraging the expertise and services of their partners in order to drive down costs while providing greater value and enhanced services to customers, employees, suppliers, and partners. Previously, there were barriers to enabling this online partnership including security concerns as well as the costs associated with development and interoperability. The Netegrity SAML Affiliate Agent is designed to address these challenges by providing an out of the box solution to enable companies to leverage SAML in order to securely exchange user identities across partner sites, regardless of the infrastructure in place. 'Harvard Pilgrim needed a way to securely exchange identity information with external companies that provide content and transactions for Harvard Pilgrim Online,' said Lawrence Rapisarda, CTO at Harvard Pilgrim Health Care. 'The Netegrity SAML Affiliate Agent is going to enable us to provide a seamless user experience across these affiliates in a cost effective federated environment.' SAML, which became a standard within OASIS in October of 2002, provides a standard way to securely exchange user information across partner sites. Netegrity SiteMinder 5.5 currently supports the SAML specification, enabling a company to create a SAML based identity and share that SAML identity with a partner site. With the new Netegrity SAML Affiliate Agent, Netegrity is now enabling the partner to more easily recognize and authenticate the SAML identity. Now, for example, Company X can seamlessly and securely work with its 401k provider. An employee of Company X logs on to the Company's Intranet, which is protected by Netegrity SiteMinder technology, and then decides to change the funds within their 401K account. The Netegrity SAML Affiliate Agent is designed to allow Company X to securely pass the employee's credentials to the 401K provider without having the employee log in again. The notification capability in the Netegrity SAML Affiliate Agent is designed to allow the 401K provider to automatically send notification back to Company X to alert them of the modifications and adds this action to their audit logs. The Netegrity SAML Affiliate Agent enables single sign-on across partner sites and the sharing of pertinent user information to personalize the user's experience. In addition, the Netegrity SAML Affiliate Agent extends the SAML specification to meet the needs of its enterprise customers by adding: (1) Single Sign-Off: As the user travels from partner site to partner site, it is important to ensure that their session is terminated at each site once they logout, preventing unauthorized access; (2) Notification: The original site from which the user came may require that the partner site send a report back to the company when the user performs certain sensitive transactions. This is especially important in regulated industries such as healthcare and financial services, which require audit and reporting logs..."
[January 14, 2003] "Sun Microsystems Delivers Industry's First Liberty-Enabled Web Single Sign-On Product. Sun ONE Identity Server 6.0 Delivers Easy Access to Applications and Services Through Single User-Login, Reduces Administration Overhead and Provides Increased Revenue Opportunities." - "Delivering on its commitment to customers and the Liberty Alliance organization, Sun Microsystems, Inc. today announced the general availability of the Sun ONE Identity Server 6.0, the industry's first open-standards based network identity solution. Increasingly, organizations require the ability to enable their employees, business partners and customers to easily and seamlessly access information and services via the Web in a secure, privacy-protected, non-proprietary, cost-effective manner. The Sun ONE Identity Server 6.0 provides a standards-based, future-proofed implementation that leverages Java technology, the Liberty Alliance, Security Assertion Markup Language (SAML), and XML specifications. By providing a foundation based on SAML standards, Sun provides a complete identity and access management foundation that helps secure the delivery of business information today through open standards such as Liberty and provides organizations with the ability to adapt to changing business requirements. The Sun ONE Identity Server 6.0 is the first commercial-grade identity management solution that fully integrates access management, delegated administration, directory and federation services into a single product. A key component of Sun's overall identity management solution, it is built on top of the market-leading Sun ONE Directory Server and leverages the consolidation capabilities of the Sun ONE Meta Directory... A key capability of the Sun ONE Identity Server is the ability to federate identities, via either SAML or the Liberty Specification, both internal and external to the organization's firewall. Increasingly, customers are choosing Sun to provide them with a scalable, highly available solution that leverages existing directory and name space investments, while providing a path forward to new business ventures... The Sun ONE Identity Server 6.0 integrates the Sun ONE Directory Server and includes the following core services: (1) Access Management: Delivers single sign-on for Web-based resources and centrally controlled access services. Flexible authentication mechanisms including LDAP, RADIUS, X.509v3 certificates, SafeWord token cards, and UNIX platform authentication services. APIs in C, Java, and XML allow customization and easy integration for policy, authentication, auditing/reporting, and client interfaces. (2) Identity Administration: Provides centralized administration of identities, policies, and services. (3) Federation: These services enable shared authentication with affiliate organization Websites and are supported through the Liberty Alliance and SAML (Security Assertions Markup Language) specifications. These specifications will help establish an open, single sign-on standard with decentralized authentication and authorization. (4) Service Management: These capabilities help manage configuration data of external applications and services and provide a solution for customizing and registering management parameters for external applications, such as service-delivery via a portal or mail quota on an e-mail server..."
[December 09, 2002] "SAML Unlocks Door to Web Services." By Jim Rapoza. In eWEEK (December 09, 2002). "Early last month, a key element in using Web services for business applications reached a milestone when SAML 1.0 was released as a standard by the XML consortium OASIS, or Organization for the Advancement of Structured Information Standards. Security Assertion Markup Language, which is based on XML, provides a framework for authentication and authorization in Web services -- something that has been sorely missing. SAML also makes it possible to provide single-sign-on capabilities, one reason that it is a core technology behind the Liberty Alliance's ID management effort. Although not all security and access control applications may be up to the final standard specification, many already incorporate some form of SAML support. This isn't surprising, given that the SAML working group comprises representatives from most of the leading authentication vendors. However, even if your business isn't using one of these applications, incorporating SAML into your Web services is not difficult. eWeek Labs found the SAML specification to be simple and straightforward. If you can write an XML-based Web service, you can easily define authentication using SAML. In its most basic form, SAML associates an identity (such as an e-mail address or a directory listing) with a subject (such as a user or system) and defines the access rights for this, subject to a specific domain. One of the biggest strengths of SAML is how well it can interoperate with any kind of system. For example, when it comes to authentication, SAML supports almost everything, from passwords to hardware tokens to public keys to secure certificates. SAML also has built-in support for XML signatures, making it possible to handle not only authentication but also message integrity and nonrepudiation of the sender... SAML can handle single-sign-on capabilities because a SAML authentication authority can receive and send authentication assertions. This means that as a user authenticates and takes actions in a domain, the SAML authority is aware of past authorizations and assertions..."
[November 22, 2002] "The 19th Annual Awards for Technical Excellence. 'Protocols' Winners: SAML and WS-Security." By the Editors of PC Magazine. In PC Magazine (November 19, 2002). "Securing Web services is no easy task. The same virtues that make Web services so promising for e-business -- they're platform-independent, text-based, and self-describing -- create major security concerns, giving pause to businesses considering a move to the hot new interoperability technology. Two standards are emerging to secure Web services: Security Assertion Markup Language (SAML) and WS-Security, both proposals submitted to the Organization for the Advancement of Structured Information Standards (OASIS). To protect confidentiality, WS-Security relies on XML Encryption, while SAML uses the slower HTTPS. WS-Security protects individual transactions, and the substantial infrastructure required by SAML pays off with single sign-on capability. The Liberty Alliance's authentication solution -- Liberty 1.0 -- builds on SAML, while Microsoft's competing technology, .NET Passport, uses WS-Security. No matter whether these two standards converge or remain separate, the success of Web services in e-business could depend on them..."
[November 20, 2002] "SAML 1.0 Signals Next Step in Evolution of Web Services Security. Industry Analysts Provide Insight on SAML's Role Among Other Prominent Security Standards." By Matt Migliore. In Enterprise Systems (November 20, 2002). ['SAML is an XML-based framework for Web services that allows the exchange of authentication and authorization information among independent networks. Through it, enterprises can enable a number of Web-based security functions -- such as single sign-on and role-based access control (RBAC) -- across sites hosted by multiple companies. Furthermore, SAML provides security functionality for more complex Web services integration, whereby Web services have the intelligence to reach out to a number of other components to perform a given task. Prior to its official 1.0 release, SAML had been receiving significant support among the vendor community. However, on the user side, SSL (Secure Sockets Layers) was being implemented to secure Web services, and another emerging standard, WS-Security, was also gaining momentum. Now that SAML 1.0 has been approved, it's unclear how these standards and others, such as Public Key Infrastructure (PKI), will fit into the Web services equation. To help answer some of these questions, Security Strategies held a brief Q&A session with James Kobielus, a senior analyst with Burton Group, and Ray Wagner, a research director with Gartner Inc.'] Excerpts from Kobielus: "...As an open Web services security standard with broad vendor support, SAML 1.0 will stimulate use of Web services for external integration among organizations' line-of-business applications (such as ERP and procurement). SAML 1.0 is one of the most fundamental interoperability standards for Web services security. Even in advance of the standard's formal ratification by OASIS, SAML 1.0 had already gained broad acceptance, adoption, and implementation by many vendors of Web services security products, especially vendors of Web access management platforms, including vendors such as IBM, Sun, Netegrity, Oblix, Entrust, Entegrity, and Novell... SAML 1.0 will not necessarily reinvigorate interest in or implementation of PKI beyond PKI's limited role in today's Web services environment. PKI is primarily used today to enable server-side SSL, and SAML will primarily leverage server-side SSL for secure sessions among SAML-enabled Web security platforms. Consequently, PKI will play a role -- albeit limited to server-side SSL -- in SAML implementations. But SAML does not require new or enhanced PKI capabilities, such as client-side SSL or digitally signed SAML assertions. And it's very unlikely that SAML implementors will layer these additional PKI capabilities on SAML-based Web services security environments when server-side SSL is sufficiently secure for most real-world applications, internal or external to organizations... SAML uses server-side SSL to support encryption of content flowing over HTTP/S sessions between SAML-enabled servers that are doing Web SSO and RBAC. What SAML offers over and above SSL is a SOAP-based messaging protocol for Web SSO, plus XML-based data structures -- known as SAML assertions -- that are exchanged between SAML-enabled servers over this messaging protocol, plus implementation profiles describing how users can transparently access SAML-based Web security services through standard Web browsers..." See "Security Assertion Markup Language (SAML) Version 1.0 an OASIS Open Standard."
[November 11, 2002] "SAML Approval Brings Secure Web Services a Step Closer." By Ray Wagner, John Pescatore, and Terry Allan Hicks. From Gartner News Analysis. Gartner FirstTake, #FT-18-7741. 7-November-2002. ['The standards body OASIS approved Security Assertion Markup Language (SAML). Its widespread use will aid the creation of secure, interoperable Web services, but remaining challenges will require significant investments.'] "OASIS announced that it has approved SAML, an XML security standard. SAML enables cross-domain authentication and authorization and single sign-on, and forms the technical basis for the Liberty Alliance federated identity initiative. The newly approved SAML standard will play a central role in Web services deployments because it supports complex workflow and new business models. In addition, SAML can encapsulate complex information for the multiple domains that characterize emerging Web services models. Most Web services vendors have announced plans to support SAML in the near future, and this widespread acceptance will simplify security integration across heterogeneous Web services environments. Although Gartner forecasts rapid adoption of SAML, enterprises implementing Web services will still face serious security challenges, particularly in managing the public and private keys required to implement signing and encryption. SAML and the other leading Web services security initiatives... all assume that keys or digital certificates and the infrastructure to manage them are readily available. This is not yet the case for most enterprises, however. The XML Key Management Specification (XKMS) does offer a simplified approach to integrating public key management capabilities with applications. However, enterprises and vendors must still create the infrastructure for effective long-term management of keys and certificates within the enterprise. The failure of public-key infrastructure to achieve significant market penetration means that enterprises typically lack the capacity to effectively use Web services platforms that apply the new standards. Enterprises should plan to make investments in the necessary base infrastructure and should demand that vendors' Web services offerings support XKMS public-key management capabilities as well as SAML, XML encryption and signing, and WS-Security (when approved)..." See the announcement: "Security Assertion Markup Language (SAML) Ratified as OASIS Open Standard. Authentication and Authorization Standard Enables Single Sign-On for Web Services."
[November 06, 2002] "Security Assertion Markup Language (SAML) Ratified as OASIS Open Standard. Authentication and Authorization Standard Enables Single Sign-On for Web Services." - "The OASIS interoperability consortium today announced that its members have approved the Security Assertion Markup Language (SAML) v1.0 as an OASIS Open Standard, a status that signifies the highest level of ratification. SAML is an XML-based framework for Web services that allows the exchange of authentication and authorization information among business partners. SAML enables Web-based security interoperability functions, such as single sign-on, across sites hosted by multiple companies. 'SAML 1.0 is an important industry standard for federating diverse security domains across Web services environments,' said James Kobielus, senior analyst at Burton Group. 'SAML 1.0 supports secure interchange of authentication and authorization information by leveraging the core Web services standards of Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), and Transport Layer Security (TLS). Most vendors of Web access management solutions have committed to SAML 1.0 and are currently implementing the specification in their products.' 'SAML lets companies implement single sign-on solutions that allow users to visit various Web sites without being repeatedly challenged for credentials,' explained Joe Pato of HP, co-chair of the OASIS Security Services Technical Committee. 'In addition, SAML makes it possible to include security information in documents used in business transactions. This is particularly relevant for Web services, where security is critical.' SAML incorporates industry-standard protocols and messaging frameworks, such as XML Signature, XML Encryption, and SOAP. The specification can be easily integrated in standard environments such as HTTP and standard Web browsers. Likewise, other security environments can use SAML as an authentication and authorization layer. SAML complements Web services standards, such as SOAP, which lack inherent security features. The OASIS Web Services Security Technical Committee, for example, is profiling SAML as one of its set of security tokens. 'SAML allows vendors to interoperate for the benefit of their customers,' said Jeff Hodges, Sun Microsystems, co-chair of the OASIS Security Services Technical Committee. 'The standard is easily implemented by companies in existing environments, and SAML-aware security applications are already being introduced. Related security initiatives, such as Liberty Alliance's Version One Specification, are leveraging SAML in order to more quickly realize their goals.' The SAML OASIS Open Standard was developed by Baltimore Technologies, BEA Systems, Computer Associates, Entrust, Hewlett-Packard Company, Hitachi, IBM, Netegrity, Oblix, OpenNetwork, Quadrasis, RSA Security, Sun Microsystems, Verisign, and other members of the OASIS Security Services Technical Committee..." See also "Digital Signatures."
[October 26, 2002] "What's Coming for SAML?" Part of the Case Study "Liberty, WS-Security Uniting Over SAML Standards." By Vance McCarthy. From Integration Developer News. October 21, 2002. "... SAML 1.1 will be released in 3-4 months, Hodges said. Most of the heavy lifting on the coming specification is just about done. 'The group is taking a little breather and cleaning up a few things in the current spec,' Hodges told IDN. But it's just the calm before the frenzy. 'We have an extensive laundry list of possible items that for a major revision to SAML for version 2.0,' he added. One key area of focus for SAML 2.0 will be setting standard and reusable profiles. 'There are several contexts where there is not yet a profile spec, such as B2B,'Hodges said. [SAML profiles are protocol specifications that detail how an interaction operates and what elements it needs for determining a secured identity. These profiles do not have to specify the SAML assertions being used -- or the identity mechanism.] 'Someone could use a proprietary use of SAML and not document what they did,' Hodges said. 'It could be SAML-compliant, but it wouldn't necessarily be interoperable [with other SAML users]. But, if that private scenario were profiled in an open spec, and implemented by multiple vendors and tested for interoperability, there would be a greater possibility to reuse that SAML profile.' Users are encouraged to draft their own SAML profiles, and submit them to the committee for broader publication, Hodges said. 'We wrote into the SAML spec how one registers a profile,' he told IDN [Integration Developer News]... So far there is only one profile: How to establish the security context in a SOAP message. Without that profile, developers needed to place information in the SOAP header and specify how that will use XML digital signature and encryption Other prospective items on SAML 2.0's laundry list include: (1) Multi-participant transaction workflow (2) Credentials collections (3) Baseline attribute namespaces (4) Sessions (5) SAML feature discovery using WSDL -- when/if there is a SAML authentication that is already done is there a way to use WSDL to discover how you concoct a query..."
[October 15, 2002] "Netegrity Addresses Web Services Security With Release of TransactionMinder. Enables Companies to Use Web Services to Unlock and Integrate Mission Critical Applications For Internal Users and External Partners." - Netegrity, Inc., leading "provider of application infrastructure for access, identity and portal management, has announced the release of Netegrity TransactionMinder. Companies are utilizing Web services to lower the cost and complexity of integrating applications and delivering services while improving customer and partner relations through real time access to business services. However, the lack of security for Web services has limited the scope of these Web services deployments. Netegrity TransactionMinder solves this problem by providing the first, enterprise scale solution for controlling access to Web services. With TransactionMinder, companies can now control who can access a Web service (authentication) and what can be done with the Web service (authorization)... Web services pose a new set of security challenges that traditional access control products were not designed to solve. Traditional access control solutions control users accessing applications on a Web site. With Web services, XML messages, not users, are now arriving at a Web site. These XML messages contain information that will be used to process a transaction at the Web site, such as a purchase order for buying steel or a request for a life insurance quote. In order to secure Web services, companies need a solution that can use the information inside these XML messages to determine (1) Who is requesting access to this Web Service (authentication) -- the solution must be able extract from the XML message information to determine who or what (application) is the originator of the message. Are they a trusted user or partner? (2) What can be done with this Web service (authorization) - the solution must determine if this person, application, or service is authorized to process this Web service transaction based on the information inside the XML message. (3) What reports or information should be recorded (auditing) - the solution must be able to provide detailed reports on the activity that has taken place with the Web service... TransactionMinder is based on industry standards. It is designed to work with standard Web services technologies such as SOAP messages and WSDL. The product also supports SAML and XML Digital Signatures for authentication and supports industry standard Web service frameworks such as Microsoft .NET, Apache, and Netscape servers..."
[October 10, 2002] "Communicator Inc Enables Identity Management Service with SAML Standard. Security Assertions Markup Language Capability Enables Faster Implementation of Single Sign-on." - "Communicator Inc, a leading provider of secure electronic communication services to Fortune 1000 companies, announced today that it has enabled its digital identity management service, Communicator Hub ID, to leverage the Security Assertions Markup Language (SAML) standard. This will allow companies that use SAML-enabled access and authorization products to join Hub ID's single sign-on service faster. Communicator Inc also announced that it has joined the Organization for Advancement of Structured Information Standards (OASIS), the body that oversees the SAML specifications... Communicator Inc pioneered a federated directory structure within Hub ID to enable single sign-on among various enterprises. This structure enables companies to maintain complete control over their customer, partner, supplier and employee lists even as authentication information is shared... SAML is an XML standard for exchanging security credentials between online business partners, regardless of the authorization product used by either partner. Communicator Hub ID will augment its proprietary Cooked URL (CURL) protocol for exchanging authentication credentials with SAML, thereby eliminating a key barrier to cross-enterprise single sign-on. The standard enables companies that use SAML-enabled access and authentication products to be up and running with Hub ID faster. 'SAML will make it easier and faster for our member companies to achieve single sign-on through Hub ID,' said Staunton Peck, president of SecuritiesHub, an online financial community that links securities dealers with institutional investors around the globe. 'When authentication information moves from one financial institution to another, there are numerous business rules and policies that must be implemented to securely exchange that information. While SAML makes that process easier, we still need a company like Communicator Inc to ensure that Jonathan Doe from one company is the same person as John A. Doe at another company'..."
[September 23, 2002] "Netegrity Ships SiteMinder 5.5 with SAML, Passport, and Kerberos Support. Enables Enterprises to Extend their Security Infrastructure with Federated Identity Services." - Netegrity, Inc., leading provider of application infrastructure for access, identity and portal management, today announced that Netegrity SiteMinder 5.5 is now shipping. SiteMinder 5.5 enables federated identity and security with support for SAML, Microsoft .Net Passport, and Kerberos. Federated security enables companies to standardize the sharing of identity information across applications within the enterprise as well as to partner companies outside of the enterprise. Federated security is key to enabling businesses to more easily and cost effectively leverage their partnerships in order to provide customers with seamless and personalized access across a network of connected services... Netegrity's federated security model enables companies to leverage a single unified authentication, single sign-on, authorization, and auditing model to provide shared security services, regardless of whether the application is hosted locally within the organization or remotely by a partner. This enables users to log in just once, using a broad range of authentication services. Netegrity is providing support for SAML, Passport and Kerberos in SiteMinder 5.5 to provide customers with a standards based approach to allowing authentication and identity information to be shared among multiple organizations and servers. SiteMinder 5.5 provides support for: (1) SAML (Security Assertion Markup Language): SiteMinder 5.5 enables a SiteMinder identity to be mapped to a SAML based identity. SiteMinder creates a SAML assertion for a user and makes it available to a partner site. Now, companies can securely exchange information about authenticated users without having to change their existing security infrastructures, reducing costs, creating more efficiencies, and providing a better user experience. (2) Microsoft .Net Passport: SiteMinder integration with Microsoft .NET Passport enables users to log-in just one time using their .NET Passport user name and password, and access all .NET Passport enabled Web sites as well as enterprise applications protected by SiteMinder and configured to trust Passport authentication. In addition, for more sensitive applications, companies can implement a policy that challenges users for additional credentials beyond their Passport identities. (3) Kerberos: With support for Kerberos, users are able to log into their Microsoft desktop using Windows credentials and are then provided with single sign-on to the SiteMinder protected environment, without having to sign on again. Now, an employee can log onto their desktop in the morning and gain access to the company's SiteMinder protected portal, without having to log on multiple times..."
[August 26, 2002] "SAML Secures Web Services." By Linda Rosencrance. In ComputerWorld August 26, 2002. ['The Security Assertions Markup Language (SAML) is an XML-based framework for Web services that enables the exchange of authentication and authorization information among business partners.'] 'If an emerging security specification for Web services from the Organization for the Advancement of Structured Information Standards (OASIS) consortium succeeds, the days of multiple sign-ons could be over for companies and their business partners. OASIS is a worldwide not-for-profit consortium that drives the development, convergence and adoption of e-business standards. Its Security Assertions Markup Language (SAML) Specifications Set 1.0 is a vendor-neutral, XML-based framework for exchanging security-related information, called 'assertions,' between business partners over the Internet. OASIS is scheduled to adopt SAML by the end of November, according to Jeff Hodges, co-chairman of the OASIS Security Services Technical Committee, which developed the specification. SAML is designed to deliver much-needed interoperability between compliant Web access management and security products. The result: Users should be able to sign on at one Web site and have their security credentials transferred automatically to partner sites, enabling them to authenticate once to access airline, hotel and rental car reservations systems through Web sites maintained by associated business partners, for example. SAML addresses the need to have a unified framework that is able to convey security information for users who interact with one provider so they can seamlessly interact with another, according to Hodges. SAML doesn't address privacy policies, however. Rather, partner sites are responsible for developing mutual requirements for user authentication and data protection. The SAML specification itself doesn't define any new technology or approaches for authentication. Instead, it establishes assertion and protocol schemas for the structure of the documents that transport security. By defining how identity and access information is exchanged, SAML becomes the common language through which organizations can communicate without modifying their own internal security architectures..."
[August 07, 2002] "Getting Started With XML Security." By Frederick Hirsch. July 31, 2002. With 32 references. From a collection of referenced papers. "Meeting security requirements for privacy, confidentiality and integrity is essential in order to move business online. With the growing acceptance of XML technologies for documents and protocols, it is logical that security should be integrated with XML solutions. The XML Security standards define XML vocabularies and processing rules in order to meet security requirements. These standards use legacy cryptographic and security technologies, as well as emerging XML technologies, to provide a flexible, extensible and practical solution toward meeting security requirements. The XML Security standards include XML Digital Signature for integrity and signing solutions, XML Encryption for confidentiality, XML Key Management (XKMS) for public key registration, location and validation, Security Assertion Markup Language (SAML) for conveying authentication, authorization and attribute assertions, XML Access Control Markup Language (XACML) for defining access control rules, and Platform for Privacy Preferences (P3P) for defining privacy policies and preferences. Major use cases include securing Web Services (WS-Security) and Digital Rights Management (eXtensible Rights Markup Language 2.0 - XrML)... [Conclusion:] The XML Security standards define XML languages and processing rules for meeting common security requirements. For the most part, these standards incorporate the use of the other XML Security standards, especially the core XML Digital Signature and XML Encryption standards. Another example is the sharing of policy statements by SAML and XACML. This set of interlocking standards has emerged quickly, and, since it is based on a foundation of accepted practices and technologies, should mature quickly. This article has presented a brief introduction to the set of standards and how they work together. XML Security standards will be essential to moving business online as XML technologies are adopted for Web Services, Digital Rights Management and other emerging applications. Understanding of how XML may meet authentication, authorization, confidentiality, integrity, signature and privacy requirements will be essential..." (1) "Security, Privacy, and Personalization" and (2) "XML and Digital Rights Management (DRM)." [cache 2002-08-07]
[July 19, 2002] "Catalyst 2002 SAML InterOp." By Prateek Mishra (Netegrity). July 15, 2002. Document used as part of a press-briefing at Catalyst2002, San Francisco. It provides a (very)-short overview of SAML and the interOp event. Provides a SAML Introduction, Report on SAML Status, SAML InterOp Details, Relationship of SAML to other efforts. SAML (Security Assertion Markup Language) is a framework for exchange of security-related information e.g., assertions. These assertions about authentication and authorization are expressed as XML documents. SAML solves two problems: (1) Identity Federation: Provides technology to allow a business to securely interact with users originating from its vendors, suppliers, customers etc. (2) Fine Grained Authorization: Users may authenticate at one site and be authorized by another. A SAML 'profile' describes how SAML should be used to solve some business problem, e.g., Web browser profiles for Single-Sign On (part of SAML 1.0) or WS-Security profile for securing web services (currently under development by the SSTC). SAML is NOT A new form of authentication, an alternative to WS-Security, limited to legacy applications, limited to web browser applications, limited to web services security..." Details: see "Burton Group's Catalyst Conference Features SAML Interoperability Event."
[July 17, 2002] SAML and Liberty. Posting by Jeff Hodges (Sun). 2002-07-17.
[July 17, 2002] "Microsoft Warms to SAML." By Cathleen Moore. In InfoWorld (July 17, 2002). "Microsoft revealed plans on Tuesday [2002-07-16] to support an emerging security standard that also forms the technology underpinnings for rival Liberty Alliance's federated identity management specification. In a talk here at the Burton Group Catalyst Conference 2002, Praerit Garg, Microsoft group program manager, detailed the company's vision for federated security, which will in the future include room for SAML (Security Assertion Markup Language). Meanwhile, Liberty Alliance on Monday announced Version 1.0 of its federated identity management specification, which is based on SAML. SAML allows authentication and authorization information to be exchanged among multiple Web access management and security products, according to OASIS (Organization for the Advancement of Structured Information Standards) officials. The specification also addresses secure single sign on, and leverages Web services standards such as XML and SOAP (Simple Object Access Protocol). In addition to its support for X509 certificates and Kerberos, Microsoft will support SAML in the WS-Security paradigm, Garg said. WS-Security is an OASIS security specification backed by Microsoft, IBM, and Verisign. 'WS-Security is a very simple model that lets you carry multiple assertions, SAML and Kerberos,' Garg said. 'It reduces friction.' SAML is just another security token format, Garg said, and WS-Security provides the common envelope to carry multiple tokens... In response to questions from the audience about what took the company so long to embrace SAML, Garg said that last year Microsoft did not really understand what SAML was about. Also, he added that the company wanted to protect existing investments in X509 and Kerberos. Garg added that Microsoft should have participated more actively in the standards development process. With a common SAML-based bridge erected, the gap between Microsoft's identity efforts and the Liberty Alliance may be shrinking. In fact, Microsoft gave its strongest indication yet that it may join forces with the Liberty Alliance..."
[July 15, 2002] "Accent on Access Control. Conference to highlight SAML, an emerging standard for identity management." By John Fontana. In Network World (July 15, 2002). "Industry heavyweights this week will throw their support behind a developing standard that promises to help network executives build centrally managed, easily sharable user identity systems. At the annual Burton Group Catalyst Conference, a parade of vendors, including RSA Security, Netegrity, Oblix and Novell, will announce support for Security Assertion Markup Language (SAML), an emerging XML-based standard for exchanging authentication and authorization information. Also at the conference, those vendors will join Baltimore Technologies, Crosslogix, Sun, IBM's Tivoli Systems and others in a SAML interoperability demonstration. The biggest shot in the arm, however, will come from the Liberty Alliance, a group of vendors and corporate users who have spent the past six months creating a single sign-on specification. The group will release its work, and announce it is supporting SAML and adding nearly 20 new members... The wave of support for SAML likely will stamp it as a de facto standard, although it won't get official approval from the Organization for the Advancement of Structured Information Standards (OASIS) until fall at the earliest. The only snag could be that Microsoft has yet to commit to SAML, instead focusing on Kerberos as a way to pass authentication information. But Microsoft's commitment to WS-Security, a set of proposed standards it created with IBM and VeriSign and now under review by OASIS, could eventually bring the company into the fold. SAML is but one important step in creating user authentication and authorization information that is portable across corporate networks so a user authenticated on one company's network can be recognized on another and granted or denied authorization to access resources based on that authentication. This sharing of user identity is being referred to as federated identity management and is emerging as a key technology for distributed e-commerce and Web services... SAML does not specify any policy for using identity information. The Liberty Alliance specification will build on top of SAML, adding some policy protocols. Also, SAML does not incorporate a way to establish trust between business partners exchanging identity information. And SAML, which has strong authentication services, will need the help of another emerging XML-based protocol called XML Access Control Markup Language to solve the more complex issue of authorization. A third protocol - the Services Provisioning Markup Language - also will have to be incorporated. There are other, competing efforts. Microsoft is working on integrating its Passport service with Kerberos, as opposed to SAML, to create a single sign-on credential similar to Liberty's work. Microsoft also is developing TrustBridge, another product to unify sign-on across Microsoft environments, and focusing on Extensible Rights Markup Language, an authorization protocol similar to XACML..."
[July 01, 2002] "SAML Promises Web Services Security." By James Kobielus. In Network World (July 01, 2002). "Security Assertion Markup Language 1.0 is a new proposed standard for interoperability among Web services security products. As corporations increasingly deploy access management solutions and other security products in Web services environments, SAML 1.0 has the potential to be a critical interoperability standard for securing these online environments from end to end, both within organizations and from business to business. SAML 1.0, nearing ratification by the Organization for the Advancement of Structured Information Standards, works with XML and Simple Object Access Protocol (SOAP). SAML 1.0 defines SOAP-based interactions among security and policy domains, supporting Web single sign-on (SSO), authentication and authorization. The standard defines request and response 'assertion' messages that security domains exchange to vouch for authentication decisions, authorization decisions, and attributes that pertain to named users and resources. SAML 1.0 also defines functional entities such as authentication authorities, attribute authorities, policy decision points and policy enforcement points. In a SAML-enabled Web SSO scenario, users log on to their home or 'source' domains through authentication techniques such as ID/password. The source domain communicates this authentication decision, plus other information that provides a security context for that decision, to one or more affiliated or federated destination domains through messages that contain SAML 'authentication assertions' and 'attribute assertions.' See also "SAML Gains Steam."
[June 26, 2002] "The Web's Future Passkey." By Lawrence M. Walsh. In Information Security Magazine (June 2002). ['SAML supporters say the standard could provide ubiquitous, transparent Web authorization.'] "Baltimore Technologies recently designed its security management suite, SelectAccess 5.0, as an XML-based application to leverage its access control functions for the emerging world of Web services. A key element of SelectAccess is the Security Assertion Markup Language (SAML), a relatively new standard that's rapidly becoming the de facto means for exchanging user credentials between trusted environments... Developed by the Organization for the Advancement of Structured Information Standards, SAML could be the success story for the next generation of online computing. As Web services and trusted online relationships continue to evolve, many see SAML as the mechanism that will bring single sign-on (SSO) to B2B and B2C environments... SAML's infrastructure is rather simple. To make it work, a Web-based network must have a SAML server deployed on its perimeter. The server sits alongside the Web server and interacts with its back-end access control database. Once a user authenticates to the site, the SAML server will transparently transmit his credentials to every partner site. The SAML server on the other end will automatically accept him as being a trusted user... Given the extent of a partner community, users can transparently pass from site to site without ever touching an access control or authorization mechanism. This transparency, developers believe, will facilitate greater use of online services and information sharing, since users won't have to remember and enter a myriad of authentication information... Granting trust between SAML servers isn't done blindly. SAML doesn't grant users access, say how they should be authenticated or enable automated provisioning for new services. Essentially, it's nothing more than an exchange of information between trusted, known parties. That's where things get a little tricky. While an enabled SAML system will create transparent exchanges of authorization information, the establishment of those trusted relationships must still be done out of band... SAML typically uses digital certificates to authenticate servers to one another--preventing a rogue SAML server from spoofing access rights--and encrypts all data passed between networks. However, the standard doesn't authenticate users; rather, it relies on existing access control and authentication solutions. It also does nothing to protect user identification information stored locally. All of this means partner sites must develop mutual requirements for user authentication and data protection... In addition to Baltimore, other security vendors are incorporating SAML in their products. Waveset and Netegrity are each integrating SAML in their access control products, and Netegrity has already released a toolkit for making existing SiteMinder applications SAML-compliant..."
[June 04, 2002] "Burton Group's Catalyst Conference to Showcase First Demonstration of SAML 1.0 Industry Standard. OASIS-Sponsored Demo Features Standards-Based Interoperability. Burton Schedules SAML 1.0 TeleBriefing for June 12, 2002." - "Burton Group, a technology-industry pioneer of network research and consulting, will showcase the first public demonstration of standards-based interoperability among SAML 1.0-conformant security software products on July 15 at its annual Catalyst Conference. Sponsored by the Organization for the Advancement of Structured Information Standards (OASIS), the industry standards group that developed the proposed Security Assertion Markup Language (SAML) standard for Web services security, the demonstration will feature products from several network security software vendors. SAML 1.0 is a proposed OASIS standard for exchanging authentication and authorization information among disparate Web access management and security products. SAML 1.0, which will soon come up for a vote by the full OASIS membership, addresses the need for secure single sign-on (SSO) across diverse Web access management environments implemented across various organizations, applications, Web sites and portals. The proposed standard defines standardized exchanges of identity and access management (IAM) information, leveraging such Web services standards as XML and SOAP... The SAML interoperability demonstration will involve several current and future commercial software solutions that support Web SSO, access management and other network security services. As of May 15, 2002, vendors who have indicated their intention to participate in the event are Baltimore Technologies, Crosslogix, Entegrity Solutions, ePeople, Novell, OverXeer, Netegrity, Oblix, RSA Security, Sigaba, Sun Microsystems and Tivoli Systems. The SAML 1.0 demonstration will feature cross-enterprise SSO across several vendors' Web access management products, which will support consistent vendor implementations of the SAML 1.0 Web Browser profile. In particular, the event will demonstrate the following scenarios: (1) IAM interoperability: Businesses using different vendors' Web access management products establish trust relationships for the purpose of sharing authentication, attribute and authorization decision information; (2) Cross-enterprise Web single sign-on: Browsers/users authenticate at 'portal' sites and then are able to access Web resources managed under other 'content' sites..."
[June 04, 2002] "Oblix Announces Availability of the NetPoint FEDERATEDid Layer for Enhanced Identity Management Within the Enterprise. Oblix Delivers Industry's Most Comprehensive Set of Federated Identification Services Including Full Support of Security Assertion Markup Language (SAML)." - "Oblix, a leading developer of identity-based security solutions, today announced the immediate availability of the NetPoint FEDERATEDid Layer -- an integration layer within Oblix NetPoint that allows an enterprise to identify users from multiple authentication sources while maintaining tight control over access to Web-based applications and resources. The NetPoint FEDERATEDid layer enables enterprise customers to accept user identifications from a third-party such as Microsoft .NET Passport and rely on Oblix NetPoint to seamlessly provide authorization and identity management actions. The NetPoint FEDERATEDid Layer enhances an enterprise's identity management capabilities and increases the user experience, as users authenticated by a third-party will not have to log-in again when accessing protected applications... Oblix reiterates its support for SAML and other emerging industry standards and will be one of the first vendors to deliver a 100% SAML-compliant product. The company is an active member of the OASIS Security Services Technical Committee (SSTC) working on the ratification of SAML 1.0, and the company plans to participate in a SAML interoperability demonstration at Burton Catalyst in July. Ratification of the SAML 1.0 specification is expected by the end of this month. The NetPoint FEDERATEDid Layer can be used in cooperation with SAML and does not mandate customers use SAML. Instead, the NetPoint FEDERATEDid Layer gives customers the choice in deciding how they will implement SAML or use other options for interoperable authentication such as the Liberty Alliance or .NET Passport..."
[May 07, 2002] "SAML Gains Steam." By John Fontana. In Network World (May 06, 2002). "An XML protocol that appears on its way to becoming a key building block for standards-based security picked up momentum last week as vendors introduced products and vowed to provide free access to their patents to advance the cause. The efforts are in support of the Security Assertions Markup Language (SAML), a framework for exchanging authentication and authorization credentials over the Web, which promises to give IT executives a way to tie together disparate security systems internally and with business partners. Last week, RSA Security announced that it would offer royalty-free use of two patents it owns that are similar to how SAML functions, therefore quashing concerns that the patents may hamper the acceptance of SAML. Also, Quadrasis, a business unit of Hitachi, introduced a developer tool for building SAML support into connectors that work with its Security Unifier. The product is similar to enterprise application integration software in that it provides a routing and transformation hub and a set of connectors that allow disparate security systems such as authentication systems, single sign-on software and encryption products to work together... SAML is gaining steam as it moves through the standards track at the Organization for the Advancement of Structured Information Standards. Ratification is expected in June. Experts say SAML will make it easier for users to cross security boundaries, especially those between companies that have established trust relationships. Combined with another emerging standard for digital signatures called XML Signatures, companies can exchange signed SAML assertions that confirm a particular user is authenticated and authorized to access certain network services. RSA, which is building SAML into its Web Access Management product called ClearTrust, is offering royalty-free access to U.S. patents that cover one type of SAML assertion called Browser/Post Profile, which basically delivers a digitally signed SAML assertion through an HTML form stored on a browser. Most vendors today, however, are implementing a simpler type of SAML assertion called Browser/Artifact Profile..."
[April 19, 2002] "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)." Edited by Phillip Hallam-Baker (VeriSign) and Eve Maler (Sun Microsystems). For the OASIS XML-Based Security Services Technical Committee (SSTC) Maturity level: Committee Specification. Publication date: 19-April-2002. One of the 'final' SAML 1.0 Committee Specification "00" documents. Posted by Eve Maler. "This specification defines the syntax and semantics for XML-encoded SAML assertions, protocol requests, and protocol responses. These constructs are typically embedded in other structures for transport, such as HTTP form POSTs and XML-encoded SOAP messages. The SAML specification for bindings and profiles provides frameworks for this embedding and transport. Files containing just the SAML assertion schema and protocol schema are available... 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..." See the official Word .DOC source.
[April 30, 2002] "RSA Removes Patent Block to SAML Uptake." By [ComputerWire Staff]. In The Register (April 30, 2002). "RSA Security Inc yesterday said it will grant royalty-free licenses to any developer that wants to use the Securities Assertions Markup Language (SAML) in their products. The company revealed last month that it has two US patents it believes cover aspects of the XML access control standard. The only caveat RSA is imposing on the royalties is that any other companies which claim to have intellectual property covering parts of SAML must also grant RSA a royalty-free license to use their technology. No other company has yet to disclose an IP interest in any other parts of SAML, but should one come forward, RSA's terms leave it open for them to levy royalties against firms other than RSA. Also, any developer that makes an SAML product using tools from companies that have licensed from RSA, must also license from RSA under the same royalty-free terms, so RSA can keep track of where its IP is being used. The patents in question are 6,085,320 and 6,189,098, both entitled "Client/Server Protocol for Proving Authenticity". RSA disclosed the patents after a direct request from the SAML working group, part of the OASIS XML interoperability group Eve Maler, one of Sun Microsystems Inc's engineers in the working group, said the RSA patents "appear to be essential to the implementation of the SAML specification." She added that RSA's decision to go royalty-free is a good one for the encouraging uptake of standards in the emerging digital identity space..." See "Committee Specification Level Documents for the Security Assertion Markup Language (SAML)."
[April 29, 2002] "Web Services Security Tightens." By Darryl K. Taft and Dennis Fisher. In eWEEK (April 29, 2002). "Since security remains among the key challenges that must be met before Web services can become pervasive, some companies are moving to answer the call. Baltimore Technologies plc. and Hitachi Computer Products Inc.'s Quadrasis business unit this week will each deliver tools to help meet Web services' security challenge. At the heart of these technologies is SAML (Security Assertions Markup Language), an XML-based standard for exchanging security credentials among online business partners. Nearing ratification by OASIS, or the Organization for the Advancement of Structured Information Standards, SAML enables users to sign on to one site and have their security credentials and information transparently transferred across affiliated sites... Quadrasis this week will announce its Enterprise Application Security Integration Developer Tool. It enables users to link security solutions via SAML wrappers and combine them to form a front-line defense for Web services security. The EASI tool is part of the company's EASI Security Unifier, which is based on SAML. Bret Hartman, chief technology officer of Quadrasis in Waltham, Mass., said the EASI Developer Tool is like 'enterprise application integration for security'..."
[April 25, 2002] "Baltimore to Release SelectAccess 5.0 with SAML." By Sam Costello. In InfoWorld (April 24, 2002). "Baltimore Technologies will announce version 5.0 of its SelectAccess Web access management product on Monday, a release that includes easier configuration, better reporting and support for the SAML (Security Assertions Markup Language) standard. The addition of SAML to the product is perhaps the most important new feature in version 5.0. SAML is an emerging Web standard that should allow different Web access management products to interoperate and exchange security, authentication and permission information about users... Version 5.0 of SelectAccess simplifies the process of adding new users and components to a system, allows user information to be drawn from different directories simultaneously, offers deeper reporting and alerting options and adds support for the authentication of wireless users, she said. The new version of the software allows administrators to more easily and quickly deploy new SelectAccess components by storing configuration details in an LDAP (Lightweight Directory Access Protocol) directory, she said. That configuration data can then be automatically applied to new components -- such as servers and directories -- as they are added to a network, speeding installation of the new component. The new feature also cuts down on the time needed to upgrade configurations, as the new configuration can be created once and then published to all affected components, she said. SelectAccess 5.0 also allows information about users and policies to be extracted from different LDAP directories at the same time, according to Fai. This feature is needed as companies may use separate directories for different groups of users, she said. The new software also offers administrators more detailed and searchable reports, allowing them to be viewed by date, server, user, administrator and other criteria, she said. Administrators can also be notified of events in SelectAccess in more ways in version 5.0, with SNMP (Simple Network Management Protocol) and pager forwarding options, Fai said. Alerts can also be sent to trigger other events, rather than immediately alerting an administrator... Users of WAP (Wireless Application Protocol) devices are also supported in SelectAccess 5.0, she said. Another new protocol supported by the software is SAML, an emerging standard for Web access management products that will allow authentication and access control data to be handed off among Web access management products, she said. SAML support will help SelectAccess users extend Web single-sign-on capabilities beyond their corporate boundaries to partners who may not be using the same Web access management software... Despite the impending ratification, other details still need to be worked out among Web access management vendors. Those include how the data about access control will be described, he said. As as result, initial SAML deployments are likely to offer only a single sign-on to a variety of Web resources, rather than the full capability of the standard..." See also the announcement, "Baltimore Introduces the First Commercially Available Implementation of SAML-based Services for Online Partnerships with SelectAccess 5.0. SelectAccess 5.0 Eases Administration, Extends Usability, and Leverages Existing IT Investment."
[December 13, 2001] "SAML Basics. A Technical Introduction to the Security Assertion Markup Language." By Eve Maler (XML Standards Architect, XML Technology Center, Sun Microsystems, Inc.). Presentation delivered at the Java in Administration Special Interest Group (JA-SIG) Conference, December 3, 2001. 51 slides. The session was designed to "provide a technical overview of SAML, the XML-based Security Assertion Markup Language being standardized at OASIS. It discusses how SAML enables Single Sign-On and other security scenarios, and provides details about the authentication, attribute, and authorization information that SAML can convey. The presentation also covers the protocol by which security information can be requested from SAML Authorities and the practical realities of how this information can be transported securely across domains... With XML, you often see standards that are simply wire protocols; no API is mandated, and in some cases no binding to some transport mechanism (such as HTTP or SMTP or whatever) is provided. We felt that the latter is definitely needed so that proprietary mechanisms don't creep in. What's needed is (1) A standard XML message format [It's just data traveling on any wire; No particular API mandated; Lots of XML tools available]; (2) A standard message exchange protocol [Need clarity in orchestrating how you ask for and get the information you need]; (3) Rules for how the messages ride 'on' and 'in' transport protocols, for better interoperability. SAML is an XML-based framework for exchanging security information: (1) XML-encoded security 'assertions'; (2) XML-encoded request/response protocol; (3) Rules on using assertions with standard transport and messaging frameworks..."
[March 22, 2002] "SAML Advances Single Sign-On Prospects." By Andy Patrizio. In XML Magzine Volume 3, Number 2 (March 2002), pages 10-11. ['Promising a standard means of authentication and authorization, SAML passes an important OASIS milestone.'] "The Organization for the Advancement of Structured Information Standards (OASIS) has completed the heavy lifting on its latest XML standard, the Security Assertion Markup Language (SAML), a standard for exchanging authentication and authorization information between domains. SAML (pronounced 'sam-el') is designed to offer single sign-on for both automatic and manual interactions between systems. It will let users log into another domain and define all of their permissions, or it will manage automated B2B exchanges between two parties. SAML addressed the need to have an industry standard way of representing assertions of authentication and authorization for users and interactions, according to Jeff Hodges, co-chair of the Security Services Technical Committee (SSTC) at OASIS that developed the spec and principal engineer at Oblix... SAML replaces two previous efforts by OASIS to create an authorization and authentication protocol, called S2ML and AuthXML. These efforts were being carried out by separate camps, but the SSTC decided it was in everyone's best interests to get all of the camps under one spec and combined the two efforts, because they handled two separate functions. What does pass for Web-based single sign-on is proprietary, the most well known being Microsoft's Passport. SAML is meant to be vendor neutral and is based on XML encoding rather than ASN.1 protocol, which is used in other areas of network sign-on and permissions, such as LDAP. For various reasons, people are gravitating toward using XML rather than ASN.1, according to Hodges. One reason is that XML is textual while ASN.1 is compiled into a binary language. The Web world to a fair degree expects things to be textually based, he said. Another reason is the knowledge level out there. There's a lot more available in terms of learning for XML over ASN.1. SAML is designed not only for user logon to a system, but also for automated B2B transactions that require a secure transaction between the two parties. Again, the automated services run the same as the manual, human-driven functions. The connecting party gives the authorization to access the system and specifies the tasks it can perform -- in this case, a data exchange..."
[March 08, 2002] "Securing Web Services with Single Sign-On." By Zdenek Svoboda. In TheServerSide.com (March 2002). "In this part of the Web services tutorial we will learn how to secure applications with a single sign-on utlility. We will introduce the simple scenario where the client gets the authentication token from the SSO service and appends it to the outcoming request. The receiving party can validate the incoming token by calling the SSO service. We will also shown how SAML, the standard format for the security information exchange, can enhance the SSO architecture... The basic idea of the single sign-on security architecture is to shift the complexity of the security architecture to the so-called SSO service and thus release other parts of the system from certain security obligations. In the SSO architecture, all security alghorithms are found in the single SSO server which acts as the single and only authentication point for a defined domain. Thus, there is a second benefit to an SSO approach to autnentication/registration: a user has to sign-on only once, even though he may be interacting with many different secure elements within a given domain. The SSO server, which can itself be a Web service, acts as the wrapper around the existing security infrastructure that exports various security features like authentication and authorization... An advanced approach permits the token itself to contain some valuable security information that allows validation without having to call the SSO server each time. The token contains the authentication or authorization information. This information is 'signed' by the SSO server, so provided the token recipient trusts this server, it doesn't have to do any further verification... There is a new standard for exchanging security-related information in XML called Security Assertions Markup Language (SAML). This is currently being completed at OASIS and its first release is expected at the time of this article's publishing. Basically, the security information described by SAML is expressed in the form of assertion statements about security subjects (e.g. users, machines or services). SAML defines the protocol by which the service consumer issues the SAML request and the so-called SAML authority returns the SAML response with assertions. There are three kinds of assertions: The Authentication statement informs about the authentication of a particular subject in a specific time and scope. The Authorization decision allows or denies a subject access to a specific resource. The Attributes further qualify the subject (e.g. credit line info, citizenship etc.). The use of SAML isn't limited to the SSO scenario. It can be used in a much broader sense. If our Web services applications understand SAML it shouldn't be difficult to flexibly reconfigure the security architecture without lenghty re-coding. You can take a look at a the SAML authorization request below. Notice that it contains the user credentials (username and encrypted password in our case) and some descriptions like response requirements, credentials types, etc...."
[December 13, 2001] "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)." Reference: draft-sstc-core-21. Interim draft. 10-December-2001. 39 pages. From members of the OASIS XML-Based Security Services Technical Committee (SSTC). Contributors include: Carlisle Adams (Entrust), Nigel Edwards (Hewlett-Packard), Marlena Erdos (Tivoli), Phillip Hallam-Baker (VeriSign, editor), Jeff Hodges (Oblix), Charles Knouse (Oblix), Chris McLaren (Netegrity), Prateek Mishra (Netegrity), RL "Bob" Morgan (University of Washington), Eve Maler (Sun Microsystems, editor), Tim Moses (Entrust), David Orchard (BEA), and Irving Reid (Baltimore). "This specification defines the syntax and semantics for XML-encoded SAML assertions, protocol requests, and protocol responses. These constructs are typically embedded in other structures for transport, such as HTTP form POSTs and XML-encoded SOAP messages. The SAML specification for bindings and profiles provides frameworks for this embedding and transport. Files containing just the SAML assertion schema and protocol schema are available. .. An assertion is a package of information that supplies one or more statements made by an issuer. SAML allows issuers to make three different kinds of assertion statement: (1) Authentication: The specified subject was authenticated by a particular means at a particular time. (2) Authorization decision: A request to allow the specified subject to access the specified object has been granted or denied. (3) Attribute: The specified subject is associated with the supplied attributes. Assertions have a nested structure. A series of inner elements representing authentication statements, authorization decision statements, and attribute statements contains the specifics, while an outer generic assertion element provides information that is common to all the statements..." SSTC WG documents supportive of the Core Assertion Architecture specification inclued (1) SAML Profile of XML Digital Signature; (2) Assertion Schema Discussion; (3) Protocols Schema Discussion; (4) Assertion XML Schema 'draft-sstc-schema-assertion-21.xsd'; (5) Protocol Schema 'draft-sstc-schema-protocol-21.xsd'. Other Committee Drafts from the SAML working group include: Use Cases and Requirements Document, Domain Model, Bindings Model, Sessions, Security Considerations, Conformance Specification, Glossary, and Issues List. [source]
"OASIS Security Services Technical Committee Glossary.". Reference: 'draft-sstc-ftf3-glossary-00' (incorporates draft-sstc-glossary-00). 20-June-2001. 23 pages.
[October 23, 2001] Web Services Security Assertions. Java Specification Request (JSR) #155. Specification Lead: Krishna Sankar (Cisco Systems). Goal: "To provide a set of APIs, exchange patterns & implementation to securely (integrity and confidentiality) exchange assertions between web services based on OASIS SAML." Detail: One of the important pieces in the web services space is the exchange of assertions securely between web services. The OASIS SAML is defining the assertions and this JSR adds the assertions capabilities to Java. The assertions would include credential assertions, authentication assertions, authorization assertions, session assertions, attribute assertions et al as defined by SAML. This JSR would leverage the other JSRs on messaging, SOAP & security. It is the plan of this JSR not only to provide the Java Apis for assertions but also to provide the system patterns to achieve the exchange of assertions between web services. The patterns would include req/response, sync/async patterns, firenforget et al. These patterns would be based on the JAXM and Java-RPC JSRs. Underlying technology or technologies include: XML, XML Signature, XML ENcryption, SOAP, messaging. The assertions of course is based on XML and XML Schema. The SAML TC is also defining how assertions would be signed using XML Signature. For this JSR, the primary binding of the assertions would be SOAP, again as defined in the SAML specification. The messaging would be used to develop the assertion exchange patterns. The good thing is that there are already XML Signature, XML Encryption, SOAP-RPC and JAXM APIs being developed. This JSR would use those APIs as the technology substrate... This JSR would leverage on the JAXM,JAX-RPC and the three Java security JSRs."
'SAML Specification'. June 20, 2001. 'draft-sstc-ftf3-saml-spec-00' version for use at FTF3. This document contains material on the SAML domain model (description of the SAML problem space), a glossary, core assertions, alternate assertion model, protocol models, and conformance. [source: PDF and .DOC]
SAML Specification Version 00 65 pages.
SAML Core Assertion Architecture. Version 09. 20-June-2001. By P. Hallam-Baker.
Oasis Security Services Use Cases And Requirements Consensus Draft. 30-May-2001. 'draft-sstc-saml-reqs-01'. By Darren Platt, Evan Prodromou, and TC members. "This document describes the consensus of the Security Services Technical Committee as to the requirements and use cases for the Security Assertions Markup Language (SAML) to be created by the Oasis Security Services TC. This is a draft committee specification document and as such will continue to be maintained and updated to reflect the work and decisions of the TC throughout the process of designing SAML."
A SOAP 1.1 Protocol Binding for SAML Messages. 12-June-2001. By Evan Prodromou. 'draft-prodromou-soap-binding-00'. "This document describes a SOAP 1.1 protocol binding for SAML messages. It is intended as a submission for consideration by the OASIS Security Services Technical Committee Bindings Group for inclusion in the bindings section of the Security Assertions Markup Language (SAML) 1.0 specification.
SAML Conformance Program Specification. Version 04. 20-June-2001. By K. Sankar and R. Griffin.
SAML Domain model. Version 05. June 21, 2001. By Dave Orchard and Hal Lockhart.
Security Services Bindings Model. Version 04. 14-Jun-2001. By P. Mishra, C. Ferris, J. Hodges, E. Prodromou.
Orchard-Maler Assertion Proposal. June 15, 2001. By David Orchard and Eve Maler. "This document offers a proposal for SAML assertions and the XML structure that conveys them to and from SAML Authorities. The structure is simple, easily implementable, and intuitive to XML Schema-aware developers, allowing for faster time to development. Many parts of this proposal borrow concepts that are much more fully defined in the core-07 proposal."
[February 01, 2002] "SAML Brings Security to XML." By Edmund X. DeJesus. In XML Magzine Volume 3, Number 1 (January 11, 2002), pages 35-37. ['SAML uses XML to distribute authentication and authorization information across platforms, organizations, and vendors.'] "Who can you trust? That's the major problem with security -- and one of the major obstacles both within organizations and in cross-organization transactions like B2B. If system A trusts you, does that mean that system B should too? If so, how can A and B exchange security information to perform transactions? Security Assertions Markup Language (SAML) is a new standard that uses XML to encode authentication and authorization information. That information can then be moved between systems within an organization, or between organizations in a transaction. Because its basis is XML, SAML (pronounced 'sam-el') is platform-independent and can move around as simply as text. SAML can be the solution for a variety of security problems facing many organizations today... How SAML achieves the transfer of authentication is fairly straightforward. SAML eschews the kind of hierarchical trust relationship necessary for systems such as Public Key Infrastructure (PKI) and instead uses a peer-to-peer trust model. Two organizations must first agree on the authentication and authorization attributes they require and how they will handle authentication and authorization procedures when the information arrives. For example, if system B trusts system A automatically, then anyone authenticated by A is authenticated for B. In this situation, SAML would pass to B the user credentials that satisfy A. Of course, B may not trust A perfectly. Perhaps A's authentication satisfies only part of what B requires for trust. In this case, A uses SAML to pass to B user credentials that include all of A's criteria and possibly more information, as well. This extra information may be sufficient to satisfy B -- in which case the user is authenticated on B automatically and transparently -- or else B may need to request additional information from the user to complete its authentication. This interaction is more awkward for the user, but can still be less intrusive than entering manually the full authentication information B requires. Although a hierarchical trust system is not required, such a system is still possible with SAML and may be useful in certain circumstances... OASIS working groups are now finalizing SAML. 'The first public version is expected to be ready by the end of 2001,' said Joe Pato, principal scientist at HP Labs and cochair of the OASIS Security Services Technical Committee. The folks at OASIS want to get comments during another quarter to see if they need to address any major problems. Getting that feedback requires a certain critical mass of adopters to incorporate early versions of SAML into their software. Companies including Oblix and Netegrity already have plans to include SAML in the next versions of their products..."
[January 24, 2002] "Top Web Services Worry: Security." By John Fontana. In Network World Volume 19, Number 3 (January 21, 2002), pages 1, 10. "The absence of security and reliability is proving to be a major stumbling block in convincing companies that Web services can thrive outside of corporate firewalls. IT executives are finding that Web services technology can ease internal application integration. But for business-to-business integration, the technology is lacking key standards for enterprise-class transactions, according to experts attending last week's Next Generation Web Services Conference, which drew about 700 participants... The vision is that Web services from any number of sources could be dynamically combined over the Internet into hybrid applications for business-to-business commerce... Web services specifications that begin to solve those problems are being developed now, including the Extensible Access Control Markup Language (XACML), Security Assertions Markup Language (SAML), XML Key Management (XKMS), XML Encryption, Web Services Flow Language, XML Digital Signature, Business Transaction Protocol and extensions to the Simple Object Access Protocol (SOAP). Meanwhile, IBM has proposed HTTP-R for reliable transport of SOAP messages. And Microsoft is working on a Global XML Architecture, which includes proposed standards called WS-Security and WS-Routing. The Organization for the Advancement of Structured Information Standards is developing ebXML, which includes models for security and standardizing electronic business processes. Others are proposing extensions to SOAP, which can carry directives in the header fields of its messages... Eduardo Fernandez [Department of Computer Science and Engineering at Florida Atlantic University] says XACML and SAML don't follow classic maps for security and might eventually produce errors, and XML Encryption and XKMS overlap in many places. In the interim, a handful of vendors, including IBM, Microsoft, Kenamea, Sonic, Iona, Tibco, Flamenco Networks and Grand Central, are using a collection of standard and proprietary technology in middleware software or services that use security, reliable delivery of messages and transactional integrity of business processes exposed using Web services..."
[December 10, 2001] "XTAML: XML Trust Axiom Markup Language." By Phillip Hallam-Baker (Verisign). Draft Version 0.12. October 17, 2001. 25 pages. Published by the Verisign XML Trust Center as a Research Note. "The XTAML specification is intended to complement other XML security standards and proposals, in particular XML Signature, XML Encryption, XML Key Management, and Security Assertion Markup Language (SAML). The XML Trust Axiom Markup Language (XTAML) defines SAML Trust Assertions that support the management of trust axioms. A trust axiom is analogous to a root certificate in a certificate based PKI. An important application of trust axioms is managing the trust relationship between a client and a trust service... XTAML is layered on the Security Assertion Markup Language (SAML). XTAML defines statement elements for specifying axiomatic and delegate keys and for asserting the validity status of another assertion. A new condition element is defined that makes the validity status of an assertion dependent on online verification. Two new advice elements are defined to allow an assertion to provide advice on the reissue of the assertion and for issue of related assertions... " See also the W3C XML Key Management Working Group and "XML Key Management Specification (XKMS)." [cache]
[December 11, 2001] "Authenticating Web Services." By Brian Fonseca and Tom Sullivan. In InfoWorld Issue 49 (November 30, 2001), pages 32-33. "Secure web services authentication that not only recognizes users but also grants access to particular systems is becoming a thorny and contentious issue with few signs of clarity in the near term. With security so high in enterprises' minds, a storm is brewing over standards to ensure that Web services via the Internet can be combined without compromising authentication methods. Microsoft is at the center of the maelstrom, with Sun Microsystems and a cadre of third-party providers attempting to pose XML-based alternatives to Microsoft's controversial Passport authentication. Without many security standards in place, security vendors Netegrity, Oblix, and OpenNetwork are also readying products that allow users to pass along and manage user credentials among what may turn out to be disparate Web services environments. Even as vendors jockey for position, users say the absence of robust authentication and interoperability could be a stumbling block for nascent Web services technologies... XML standards consortium Oasis is steering plans to create a universal security standard to deliver authentication and authorization regardless of platform or vendor. Led by Patrick Gannon, president and CEO of Billerica, Mass.-based OASIS, the group is pushing for adoption of SAML (Security Assertion Markup Language). Developed within the OASIS XML-based Security Services Technical Committee, SAML will provide a basic and interoperable mechanism for exchanging authentication and authorization among applications and parties, Gannon says. 'The key paradigm of Web services is really extending application interaction outside of corporate boundaries. You want to have a standard way of receiving that,' he explains; SAML will help provision services by eliminating the need for users to log in each time to access 'second [level] and third level' application entitlements. A completed SAML draft is expected by early 2002. Oasis will accept specs for approval during the second quarter of 2002. CUNA Mutual Group, the Madison, Wis.-based provider of financial services to credit unions, chose Oblix's offerings due to its level of SAML involvement, says Steve Devoti, directory service manager at CUNA. 'We know to deliver the type of services to [customers], we're going to have to federate with people,' Devoti explains. 'We need [a standard] to ensure there's a smooth hand-off to other directions to ensure what [ID] credentials are.' Third-party security companies are looking to provide some of that interoperability, too, although offerings are still in the works..."
[October 03, 2001] "Sign-On-And-Go Security." By Brian Ploskina. In InteractiveWeek (October 1, 2001). "The technology exists today to deploy a single sign-on Web services marketplace, even as Microsoft and Sun Microsystems duel to build competing identification systems. Security Assertion Markup Language is an almost completed standard by the Organization for the Advancement of Structured Information Standards, a nonprofit consortium for the creation of interoperable industry standards. Based on XML, SAML allows a single sign-on for Web applications across the multitude of Web access management platforms available today. Leaders in Web access management - such as Access360, Baltimore Technologies, Entrust, Hewlett-Packard, IBM, Netegrity, Oblix and VeriSign - have committed to the standard. When it's ratified early next year, these companies can incorporate SAML in their software, enabling an interoperable infrastructure for identity and access management. Many of them have already incorporated early versions of the standard in the software they sell today, with free upgrades promised when SAML is complete... Examples of how the technology could be used include business-to-employee portals that provide employees access to their health benefits, time sheets, expense reports and 401(k) portfolios, all using a single user profile; and a business-to-consumer portal in which a credit card company partners with several online retailers to allow customers to shop from site to site without ever having to re-enter their ID numbers. 'The value to the end user is convenience,' said Enrique Salem, Oblix's senior vice president of products and technology. SAML will allow companies to know a customer has permission to conduct business on various participating networks, said Bill Bartow, Netegrity's vice president of marketing. 'SAML is the language used to describe this communication.' SAML does have obstacles. No. 1 is that Microsoft's Passport and Windows platforms so far don't support it. Instead, Microsoft is using Kerberos - a standard protocol developed by the Massachusetts Institute of Technology that runs on the Unix platform - as its authentication mechanism..."
"JSAML Toolkit. Netegrity's Java Implementation of the Security Assertions Markup Language (SAML) Specification." Netegrity White Paper. September 28, 2001. 10 pages. "JSAML is Netegrity's Java implementation of SAML, the Security Assertions Markup Language. SAML defines an eXtensible Markup Language (XML) framework for exchanging security information between business partners over the Internet. SAML is being standardized at OASIS, the Organization for the Advancement of Structured Information Standards, an international consortium that creates interoperable industry specifications based on XML. JSAML is a standards-based toolkit designed for developers to build secure solutions for: (1) distinct business partners who exchange profile and entitlement information over the Internet, (2) single-sign on between vertical applications (such as SAP, Oracle, and Peoplesoft) and enterprise infrastructures. JSAML delivers the following benefits: (1) Self-contained security package - JSAML allows developers to build browser-based single sign-on and XML messaging solutions without the use of any other proprietary products. (2) Standards-based toolkit - JSAML is based on Java and uses standard, widely available cryptographic libraries and transport-level security packages. (3) Flexible developer solution - JSAML provides the source code for example solutions that developers can easily modify to adapt to their specific environment requirements. (4) Available at no cost - The JSAML toolkit is freely downloadable from Netegrity's Web site. The JSAML toolkit includes executables packaged in a Java Archive (JAR) file together with example source code that can be modified by the developer to accommodate a particular security application..."
[September 24, 2001] "Netegrity Introduces First JSAML Toolkit-Company to Deliver Industry's First SAML Implementation to Enable Rapid Deployment of SAML Solutions Across E-Business Networks." - "Netegrity, Inc., a leading provider of solutions for securely managing e-business, today announced a freely available JSAML toolkit to make it easier for corporate developers and independent software vendors (ISVs) to quickly create and deploy SAML-ready solutions. With Netegrity's JSAML toolkit, developers can enable their applications and security products to become solutions that securely exchanging user identity and entitlement information with partners using the SAML language. Netegrity is the first company to provide a reference implementation of SAML based on the OASIS group's proposed Security Assertion Markup Language (SAML) standard... To realize the true benefits of e-business networks, the industry needs new standards, new tools and new products to solve the problem of sharing security related information across a network of companies with very heterogeneous and proprietary infrastructures. Netegrity has taken a leadership position in this emerging market. Several months ago, Netegrity worked with its partners to create the foundation specification for the SAML language and is now a major driver of the SAML committee at OASIS. Netegrity recently announced its AffiliateMinder product for securely managing affiliate user networks. "TransactionMinder" was also introduced as a new product line for securing the emerging web services platforms. Both of these products are based on the SAML specification and will enable security across e-business networks. Netegrity is now delivering the tools that companies need to begin the development and deployment of SAML solutions across their own security solutions. With the JSAML toolkit, companies can accelerate their adoption and implementation of SAML. Netegrity's JSAML Toolkit Netegrity JSAML Toolkit is a light-weight toolkit that comes with complete documentation and use-case examples (including source code) to get developers, corporations, ISVs and partners productive quickly. The toolkit is designed to be used with e-business applications and existing homegrown or industry standard security solutions to enable them to be share security information through SAML..."
[July 24, 2001] "Netegrity Unveils Product Strategy for Web Services. New TransactionMinder Product First to Address Need for Securing and Managing Web Services." - "Netegrity, Inc., a leading provider of solutions for securely managing e-business, today announced its product strategy to provide the industry with the first comprehensive platform for securing and managing Web services. One of the challenges holding back the adoption of Web services today is a company's inability to secure the Web services being made available over the Internet. With today's announcement, Netegrity addresses this complex issue with a new product for securing Web services, code named TransactionMinder. TransactionMinder provides a centralized, policy based platform for securing Web service discovery and consumption, Web service publication, and delegated administration of Web services deployment. TransactionMinder will integrate XML security standards, such as SAML and XKMS, with leading Web service architectures, such as the Sun Open Net Environment (Sun ONE) and Microsoft.NET, to provide a secure environment in which to deploy these services... Netegrity's new TransactionMinder product line is designed to provide the market with the first, centralized, policy based platform for securing and managing XML based Web services. With TransactionMinder, companies are no longer limited to very basic transport level authentication, which is inadequate for securing Web services. TransactionMinder provides a broad range of shared security services that are needed to secure XML documents and messages that are the foundation of Web services. TransactionMinder builds on Netegrity's shared services vision to provide companies with a set of services for centralizing Web service security. Netegrity's centralized security platform will integrate with the new and emerging Web service architectures such as Sun ONE and Microsoft.NET and integration platforms from companies such as BEA, Bowstreet, Oracle, and webMethods. This centralized approach eliminates the need to build proprietary and non-scalable security across multiple Web service platforms and in multiple Web service applications. TransactionMinder delivers the following capabilities: (1) Policy Based Security for Web Services: TransactionMinder enables companies to define policies for determining the appropriate authentication and authorization rules to apply to the Web service based on the contents of the XML document. New authentication schemes that TransactionMinder will leverage include SAML (Security Assertion Markup Language), XML digital signatures, and extraction of credentials from the document. Authorization rules can now be established that will extract relevant information from the XML document to determine the authorization for that web service. (2) Authorization for UDDI registries and WSDL profiles: With TransactionMinder, companies can publish their Web services and WSDL profiles in public and private UDDI registries and then control access to these services from policies that determine the user's role and relationship with the company. (3) Non-repudiation Services: All Web service transactions can be digitally signed and stored in a tamper-evident audit. All transactions can also be fully traced and profiled. (4) Delegated Management Services: As more and more companies deploy Web services in UDDI registries, the need to manage changes and updates to these services becomes critical. DMS for Web services will enable companies to delegate management of the UDDI registry to their partners for more rapid self-service of Web service updates. (5) Open and Standards Based: TransactionMinder is designed to work with industry standards such as SAML, UDDI, WSDL and messaging frameworks such as SOAP, ebXML and RosettaNet..."
[May 20, 2001] "Security Assertions Markup Language (SAML). The standard XML framework for secure information exchange." Netegrity White Paper. May 20, 2001. 7 pages. "SAML, the Security Assertions Markup Language, defines an eXtensible Markup Language (XML) framework for exchanging security information between business partners over the Internet. SAML is being standardized at OASIS, the Organization for the Advancement of Structured Information Standards, an international consortium that creates interoperable industry specifications based on XML. In December 2000, Netegrity originally created an OASIS industry-wide Technical Committee (TC) called Security Services (www.oasis-open.org/committees/security), which is responsible for submitting a draft specification of SAML to the OASIS Board members in the second half of 2001. SAML is modeled after Netegrity's work in XML-based security for authentication and authorization, defined in the S2ML (Security Services Markup Language) specification, which was submitted to the OASIS Security Services TC as a base document for discussions. SAML reuses S2ML's principles and architecture, with a few minor differences in scope and purpose to meet as many industry requirements and use cases as possible. The primary goal of SAML is to enable interoperability between different systems that provide security services. The SAML specification does not define any new technology or approaches for authentication or authorization. Rather, it simply defines a common language for describing the information or outputs generated by these systems in XML..."
[June 22, 2001] "Shibboleth Specification." DRAFT v1.0. Shibboleth Working Group Specification Document. 'draft-internet2-shibboleth-specification-00'. May 25, 2001. "This document provides the specifications for the Shibboleth system, including interfaces, message specifications, etc. This document should define Shibboleth in sufficient detail that (1) someone can implement the system without having to guess or interpret what was intended, and (2) separate but compliant implementations are guaranteed to interoperate.... The Shibboleth Model differs from the SAML model in a several key ways. It can be described as: (1) The SHIRE uses the WAYF Service to locate the User Home Organization. The WAYF produces a BLAH. (2) The SHIRE will send an Attribute Query Handle Request to the Handle Service (HS) to obtain a reference to the user. The HS will use the local web authentication mechanism to authenticate the browser user. However, instead of generating a Name Assertion, the HS will generate an attribute query handle (AQH - an opaque user handle), and return it in an Attribute Query Handle Response. Only the Attribute Authority will be able to map the AQH to a specific user. (3) The SHAR will send an Attribute Query Message to the Attribute Authority. The SHAR cannot ask for specific attributes; rather, the query should be understood to mean "give me all the attributes you can for this user for this target". The Attribute Authority will return an Attribute Query Reponse, containing assertions for all of the attributes it is authorized to release for this target. The Attribute Authority will likely obtain the attributes from the origin site's pre-existing Attribute Repository (e.g., Directory). (4) The Resource Manager will make an access decision, based on the supplied attributes, the target resource, and the requested operation. It will then either grant or deny access. It will not produce an Authorization Decision Assertion..." See the "Definition and explanation of SHAR/AA attribute request and response messages" with W3C XML Schema: "This document describes possible XML message formats for Shibboleth attribute request and response messages passed directly or indirectly between the SHAR and AA components of the Shibboleth architecture. The formats are expressed in the XML Schema Definition language." [Shibboleth, a project of MACE (Middleware Architecture Committee for Education), is investigating technology to support inter-institutional authentication and authorization for access to Web pages. Our intent is to support, as much as possible, the heterogeneous security systems in use on campuses today, rather than mandating use of particular schemes like Kerberos or X.509-based PKI. The project will produce an architectural analysis of the issues involved in providing such inter-institutional services, given current campus realities; it will also produce a pilot implementation to demonstrate the concepts."]
