Re: [security-services] New draft of SAML FAQ

["Eve L. Maler" <eve.maler@sun.com>]

Thanks for the comments!  Updated version attached. (V2.0 goal statement 
unchanged so far; please see my other message about this.)

	Eve

Philpott, Robert wrote:

> Thank you for pulling this together folks... nice job.  A couple of 
> minor comments:
> 
> 1. *Q: *Will SAML PDPs need to be configured to understand only selected 
> authentication decision queries?
> 
> [Rob] This should be "authorization", not "authentication"
> 
>  
> 
> 2. In the answer to "*Q: *What is the connection between acts of 
> authentication and SAML authentication assertions?", "public key 
> associated with signature on a document" should be "public key 
> associated with ***a*** signature on a document".
> 
>  
> 
> 3. The answer to "*Q: *How does SAML protect against "man-in-the-middle" 
> and "replay" security attacks in general?" starts with "SAML doesn't 
> really do anything "in general".".  The initial impression is that they 
> weren't taken into account, which isn't true.  The specs provides 
> guidance on things that deal with attack detection/avoidance such as 
> uniqueness of identifiers, a requirement that requests by artifact must 
> be received from the site for which the artifact was generated, etc. I 
> think it is accurate to say something like "The SAML assertions and 
> protocol schemas were developed with various types of security attacks 
> in mind and include several mechanisms useful in mitigating such 
> attacks."  And then continue with the "Profiles..." sentences.
> 
>  
> 
> That's it for now...  Now back to my vacation deck project...
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com
**********************************************************************
SunNetwork 2003 Conference and Pavilion  http://www.sun.com/sunnetwork
September 16-18, 2003                    Moscone Center, San Francisco
An unparalleled event in network computing! Make the net work for you!

Title: SAML FAQ - 25 August 2003

OASIS SAML TC FAQ

25 August 2003

This document helps to answer frequently asked questions about SAML, the Security Assertion Markup Language. If you have a question that is not answered here, or if you have questions or comments on any of the answers provided, feel free to contact the editor.

1. General

Q: What is SAML?

Q: What is the need for this specification?

Q: What has the SAML TC produced to date and what is the roadmap ?

Q: Who should be involved in this effort ?

Q: Who will benefit from this work and how?

Q: How does this work compare with related efforts at other standard organizations?

2. Technical

Q: What is the connection between acts of authentication and SAML authentication assertions?

Q: How does SAML protect against "man-in-the-middle" and "replay" security attacks in general?

Q: How is trust established between a client and a SAML authority?

Q: Will SAML PDPs need to be configured to understand only selected authentication decision queries?

Q: I don't currently use SOAP. Do I need to invent my own protocol for requesting and getting SAML assertions?

---

1. General

Q: What is SAML?

A: SAML is the Security Assertion Markup Language, a standard XML-based framework for the exchange of authentication and authorization information. The Security Services Technical Committee (SSTC or SAML TC) is in charge of defining, enhancing, and maintaining the specifications that define SAML. You can visit the TC's public home page here, and see its charter here.

Q: What is the need for this specification?

A: One of the greatest values of a security infrastructure is its ability to integrate with intra- and inter-enterprise applications. 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 that trusts the security system. SAML provides a standard XML schema for specifying authentication, attribute, and authorization decision statements, and it additionally specifies a web services-based request/reply protocol for exchanging these statements.

Q: What has the SAML TC produced to date and what is the roadmap ?

A: SAML Version 1.0 is an OASIS Standard and Version 1.1 is currently in the voting stage. The TC has started work on Version 2.0.

Version	Stage	Files and Additional Information
1.0	OASIS Standard	Complete SAML V1.0 specification set in one zip file ( oasis-sstc-saml-1.0-pdf.zip) Assertions and Protocol ( oasis-sstc-saml-core-1.0) Assertion Schema ( oasis-sstc-saml-schema-assertion-1.0) Protocol Schema ( oasis-sstc-saml-schema-protocol-1.0) Bindings and Profiles ( oasis-sstc-saml-bindings-1.0) Security and Privacy Considerations ( oasis-sstc-saml-sec-consider-1.0) Conformance Program Specification ( oasis-sstc-saml-conform-1.0) Glossary ( oasis-sstc-saml-glossary-1.0) The major goals of this version of SAML were to enable single sign-on for web users and to allow for the exchange of authentication and authorization information in a variety of kinds of distributed transaction. The design of SAML reflects a balance of three goals: providing capabilities that make adoption attractive, maximizing interoperability by identifying clear mechanisms for extension, and moving quickly to produce a standard solution.
1.1	Committee Specification; balloting in pursuit of OASIS Standard status is in progress	Complete SAML v1.0 specification set in one zip file This version of SAML focuses on improving interoperability and specification clarity through experience with Version 1.0, and in particular on tightening up the relationship of SAML with XML Signature. In general, minor revisions of SAML can be expected to be backwards compatible. This version is very slightly incompatible with SAML Version 1.0 in the area of XML Signature in order to take advantage of new knowledge about XML Signature processing.
2.0	Work begun during summer 2003; estimated to be complete by Q2 of 2004	The goals of the Version 2.0 effort are: Addressing issues that have arisen from experience with real-world SAML implementations and with standards architectures that layer on top of SAML, such as the OASIS WSS and XACML work. The TC is currently seeking implementation reports. Adding a variety of desirable features that were deferred from previous versions, such as session support, the exchange of metadata to ensure more interoperable interactions, and collection of credentials. Many of these features will be based on the Liberty Alliance V1.1 specifications that were contributed to the TC. The TC is working on a formal mission statement for Version 2.0, which will be added to this FAQ when it is available.

Q: Who should be involved in this effort ?

A: Organizations or individuals who are interested in authentication and authorization services, access management, or identity management may want to consider joining this TC. Current representation in the TC includes security software vendors, representatives from university initiatives, and government and financial institutions. The current TC members are listed here.

Q: Who will benefit from this work and how?

A: The Security Assertion Markup Language benefits a diverse group. It allows security systems and application software to be developed and evolve independently. This is because SAML provides a set of interoperable standard interfaces. Standardizing the interfaces between systems allows for faster, cheaper, and more reliable integration. As more profiles of SAML usage are developed, these benefits will be opened up to more and different kinds of access management.

Producers of security software benefit by having a standard schema and protocol for expressing security information. Application developers benefit by decoupling their software from the underlying security infrastructure. Finally, end users benefit because SAML promotes single sign-on (the ability to use a variety of Internet resources without having to log in repeatedly).

Q: How does this work compare with related efforts at other standard organizations?

A: The Security Assertion Markup Language is complementary to the XML and web services security efforts being developed at OASIS and in other open venues. For example, SAML uses XML Signature from W3C/IETF, and has been profiled for use with the WSS: SOAP Message Security specification from the OASIS WSS TC. The design of XACML, another OASIS specification, was heavily influenced by SAML. And specifications from the Liberty Alliance and the Internet2 Shibboleth effort are based on SAML.

---

2. Technical

Q: What is the connection between acts of authentication and SAML authentication assertions?

A: Any entity that can authenticate another entity (verify its identity) can potentially act as an authentication authority and issue a SAML authentication assertion. It is up to relying parties, for example a PDP, to decide what authentication authorities it chooses to trust.

The means of ensuring that the entity making a request and the entity referred to by an assertion are one and the same is dependent on the environment and protocols being used. The general mechanism provided is the SubjectConfirmation element, which is intended to carry data appropriate to the environment. Possible mechanisms include an artifact encoded in a URL, a Kerberos service ticket, or a public key associated with a signature on a document. SAML profiles will specify the details for different situations.

It is expected that others besides the SAML Technical Committee will define other schemes appropriate for other environments. They might or might not publish these as profiles, but doing so ensures greater interoperability.

Q: How does SAML protect against "man-in-the-middle" and "replay" security attacks in general?

A: The SAML assertions and protocol schemas were developed with various types of security attacks in mind and include several mechanisms useful in mitigating such attacks. Profiles are expected to prevent or minimize MITM attacks as much as possible given the limitations of the environment in question. The Security and Privacy Considerations document discusses what should be considered.

Q: How is trust established between a client and a SAML authority?

A: SAML is a very general framework which will be used in a wide variety of environments. It is up to relying parties to decide what asserting parties they trust for what purposes. For example, Company A might trust Company B to tell it if an individual was a Company B employee, but not to tell if the employee has a Secret Clearance. Trust relationships must be established out of band. (Also, a certain amount of configuration information, for example network addresses, will have to be exchanged out of band.)

Q: Will SAML PDPs need to be configured to understand only selected authorization decision queries?

A: Any PDP will have a policies covering a finite number of resources. If it is asked about a resource for which it has no policies, it will produce an Indeterminate response. It is up to the PEP to locate a PDP that knows about the resources it protects. SAML does not provide any automated way of doing this.

Q: I don't currently use SOAP. Do I need to invent my own protocol for requesting and getting SAML assertions?

A: You are allowed to use SAML requests and responses over any protocol you like. Whether you will be able to interoperate with anybody else is another question. The SOAP-over-HTTP protocol is intended to be very simple to implement and should represent less work than implementing SAML requests and interpreting SAML responses.