Content deleted Content added
No edit summary |
LeftyJohnson (talk | contribs) m correct citation |
||
| (45 intermediate revisions by 35 users not shown) | |||
Line 1:
{{
'''Security Assertion Markup Language''' ('''SAML''', pronounced ''SAM-el'', {{IPAc-en|ˈ|s|æ|m|əl}})<ref name="ISnTY">{{cite web|url=http://www.webopedia.com/TERM/S/SAML.html |title=What is SAML? - A Word Definition From the Webopedia Computer Dictionary |date=25 June 2002 |publisher=Webopedia.com |access-date=2013-09-21}}</ref> is an [[open standard]] for exchanging [[authentication]] and [[authorization]] data between parties, in particular, between an [[identity provider (SAML)|identity provider]] and a [[service provider (SAML)|service provider]]. SAML is an [[XML]]-based [[markup language]] for security assertions (statements that service providers use to make access-control decisions). SAML is also:
* A set of XML-based protocol messages
* A set of protocol message bindings
* A set of profiles (utilizing all of the above)
An important use case that SAML addresses is [[web browser|web-browser]] [[single sign-on]] (SSO). Single sign-on is relatively easy to accomplish within a [[security ___domain]] (using [[HTTP cookie|cookies]], for example) but extending SSO across security domains is more difficult and resulted in the proliferation of non-interoperable proprietary technologies. The SAML Web Browser SSO profile was specified and standardized to promote interoperability.<ref name="SAMLProf20">J. Hughes et al. ''Profiles for the OASIS Security Assertion Markup Language (SAML) 2.0.'' OASIS Standard, March 2005. Document identifier: saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf (for the latest working draft of this specification with errata, see: https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf)</ref> In practice, SAML SSO is most commonly used for authentication into cloud-based business software.<ref>{{Cite web |title=SAML: A technical primer |url=https://ssoready.com/docs/saml/saml-technical-primer |access-date=2024-12-14 |website=SSOReady Docs |language=en}}</ref>
== Overview ==
Line 13 ⟶ 14:
At the heart of the SAML assertion is a subject (a principal within the context of a particular security ___domain) about which something is being asserted. The subject is usually (but not necessarily) a human. As in the SAML 2.0 Technical Overview,<ref name="SAMLTechOverview20">N. Ragouzis et al. ''Security Assertion Markup Language (SAML) 2.0 Technical Overview.'' OASIS Committee Draft 02, March 2008. Document identifier: sstc-saml-tech-overview-2.0-cd-02 https://wiki.oasis-open.org/security/Saml2TechOverview</ref> the terms subject and principal are used interchangeably in this document.
Before delivering the subject-based assertion from
SAML does not specify the method of authentication at the identity provider. The IdP may use a username and password, or some other form of authentication, including [[multi-factor authentication]]. A directory service such as [[RADIUS]], [[Lightweight Directory Access Protocol|LDAP]], or [[Active Directory]] that allows users to log in with a user name and password is a typical source of authentication tokens at an identity provider.<ref name="92xv0">{{cite web|url=http://www.informationweek.com/software/information-management/saml-the-secret-to-centralized-identity-management/d/d-id/1028656? | title=SAML: The Secret to Centralized Identity Management |publisher=InformationWeek.com |date=2004-11-23 |access-date=2014-05-23}}</ref> The popular Internet social networking services also provide identity services that in theory could be used to support SAML exchanges.
== History ==
Line 21 ⟶ 22:
[[File:History of SAML.svg|thumb|right |History of SAML (2002–2005)]]
The [[OASIS (organization)|Organization for the Advancement of Structured Information Standards (OASIS)]] Security Services Technical Committee (SSTC), which met for the first time in January 2001, was chartered "to define an XML framework for exchanging authentication and authorization information."<ref name="QmSYw">{{Cite mailing list | last = Maler | first = Eve | mailing-list = security-services at oasis-open | title = Minutes of 9 January 2001 Security Services TC telecon | date= 9 Jan 2001 | url = http://lists.oasis-open.org/archives/security-services/200101/msg00014.html | access-date = 7 April 2011}}</ref> To this end, the following intellectual property was contributed to the SSTC during the first two months of that year:
* ''Security Services Markup Language'' (S2ML) from Netegrity
* ''AuthXML'' from Securant
Line 58 ⟶ 59:
* [[XML Encryption]]: Using XML Encryption, SAML 2.0 provides elements for encrypted name identifiers, encrypted attributes, and encrypted assertions (SAML 1.1 does not have encryption capabilities). XML Encryption is reported to have severe security concerns.<ref name="J2KVQ">{{cite web|title=How To Break XML Encryption|url=https://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf|publisher=[[Association for Computing Machinery]]|access-date=31 October 2014| date=19 October 2011}}</ref><ref name="0wAHF">{{cite web|title=RUB Researchers break W3C standard|url=http://aktuell.ruhr-uni-bochum.de/pm2011/pm00330.html.en|archive-url=https://web.archive.org/web/20111124050008/http://aktuell.ruhr-uni-bochum.de/pm2011/pm00330.html.en|archive-date=2011-11-24|publisher=[[Ruhr University Bochum]]|access-date=29 June 2012| date=19 October 2011}}</ref>
* [[Hypertext Transfer Protocol]] (HTTP): SAML relies heavily on HTTP as its communications protocol.
* [[SOAP|Simple Object Access Protocol (
SAML defines XML-based assertions and protocols, bindings, and profiles. The term ''SAML Core'' refers to the general syntax and semantics of SAML assertions as well as the protocol used to request and transmit those assertions from one system entity to another. ''SAML protocol'' refers to '''what''' is transmitted, not '''how''' (the latter is determined by the choice of binding). So SAML Core defines "bare" SAML assertions along with SAML request and response elements.
Line 103 ⟶ 104:
# Authorization decision query
The result of an attribute query is a SAML response containing an assertion, which itself contains an attribute statement. See the SAML 2.0 topic for [[SAML 2.0#SAML
Beyond queries, SAML 1.1 specifies no other protocols.
Line 124 ⟶ 125:
SAML 1.1 specifies just one binding, the SAML SOAP Binding. In addition to SOAP, implicit in SAML 1.1 Web Browser SSO are the precursors of the HTTP POST Binding, the HTTP Redirect Binding, and the HTTP Artifact Binding. These are not defined explicitly, however, and are only used in conjunction with SAML 1.1 Web Browser SSO. The notion of binding is not fully developed until SAML 2.0.
SAML 2.0 completely separates the binding concept from the underlying profile. In fact, there is a brand [[SAML 2.0#SAML 2.0
* SAML SOAP Binding (based on SOAP 1.1)
* Reverse SOAP (PAOS) Binding
Line 132 ⟶ 133:
* SAML URI Binding
This reorganization provides tremendous flexibility: taking just Web Browser SSO alone as an example, a service provider can choose from four bindings (HTTP Redirect, HTTP POST and two flavors of HTTP Artifact), while the identity provider has three binding options (HTTP POST plus two forms of HTTP Artifact), for a total of twelve
=== Profiles ===
Line 171 ⟶ 172:
{{clear}}
; 1. Request the target resource at the SP (SAML 2.0 only): The principal (via an
; 2. Redirect to the SSO Service at the IdP (SAML 2.0 only):The service provider determines the user's preferred identity provider (by unspecified means) and redirects the user agent to the SSO Service at the identity provider: <pre><nowiki>https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request</nowiki></pre> The value of the <code>SAMLRequest</code> parameter (denoted by the placeholder <code>request</code> above) is the [[Base64]] encoding of a [[DEFLATE|deflated]] <code><samlp:AuthnRequest></code> element.
; 3. Request the SSO Service at the IdP (SAML 2.0 only): The user agent issues a GET request to the SSO service at the URL from step 2. The SSO service processes the <code>AuthnRequest</code> (sent via the <code>SAMLRequest</code> URL query parameter) and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
; 4. Respond with an XHTML form: The SSO service validates the request and responds with a document containing an XHTML form: <syntaxhighlight lang="
<form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
<input type="hidden" name="SAMLResponse" value="response" />
Line 195 ⟶ 196:
== See also ==
* [[SAML 2.0]]
* [[SAML metadata]]
* [[SAML-based products and services]]
| |||