Security Assertion Markup Language: Difference between revisions

Revision as of 17:37, 30 November 2022

Latest revision as of 18:06, 19 April 2025

(35 intermediate revisions by 27 users not shown)

Line 1:

{{shortShort description|XML-basedTechnical format and protocolstandard for exchanging authentication and authorization data between parties}}

'''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:

Line 6:

* 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|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.&nbsp;Hughes et al. ''Profiles for the OASIS Security Assertion Markup Language (SAML)&nbsp;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 ==

The SAML specification defines three roles: the principal (typically a human user), the [[identity provider (SAML)|identity provider]] (IdP), and the [[service provider (SAML)|service provider]] (SP). In the primary use case addressed by SAML, the principal requests a service from the service provider. The service provider requests and obtains an authentication assertion from the identity provider. On the basis of this assertion, the service provider can make an [[access control]] decision, that is, it can decide whether to perform the service for the connected principal.

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&nbsp;2.0 Technical Overview,<ref name="SAMLTechOverview20">N.&nbsp;Ragouzis et al. ''Security Assertion Markup Language (SAML)&nbsp;2.0 Technical Overview.'' OASIS Committee Draft&nbsp;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 IdPIdentity Provider to the SPService Provider, the IdPIdentity Provider may request some information from the principal—suchprincipal (such as a user name and password—inpassword) in order to authenticate the principal. SAML specifies the content of the assertion that is passed from the IdPIdentity Provider to the SPService Provider. In SAML, one identityIdentity providerProvider may provide SAML assertions to many serviceService providersProviders. Similarly, one Service Provider (SP) may rely on and trust assertions from many independent IdPsIdentity Providers (IdP).<ref>{{cite web |last1=Guevara |first1=Holly |title=How SAML Authentication Works |url=https://auth0.com/blog/how-saml-authentication-works/ |website=auth0.com |publisher=auth0 |access-date=19 April 2025}}</ref>

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 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 Attributeattribute Queryquery|an example of attribute query/response]].

Beyond queries, SAML 1.1 specifies no other protocols.

Line 124 ⟶ 125:

SAML&nbsp;1.1 specifies just one binding, the SAML SOAP Binding. In addition to SOAP, implicit in SAML&nbsp;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&nbsp;1.1 Web Browser SSO. The notion of binding is not fully developed until SAML&nbsp;2.0.

SAML&nbsp;2.0 completely separates the binding concept from the underlying profile. In fact, there is a brand [[SAML 2.0#SAML 2.0 Bindingsbindings|new binding specification in SAML&nbsp;2.0]] that defines the following standalone bindings:

* SAML SOAP Binding (based on SOAP&nbsp;1.1)

* Reverse SOAP (PAOS) Binding

Line 171 ⟶ 172:

{{clear}}

; 1. Request the target resource at the SP (SAML&nbsp;2.0 only): The principal (via an HTTPHTTPs user agent) requests a target resource at the service provider: <pre><nowiki>https://sp.example.com/myresource</nowiki></pre> The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7.

; 2. Redirect to the SSO Service at the IdP (SAML&nbsp;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&nbsp;2.0 only): The user agent issues a GET request to the SSO service at the URL from step&nbsp;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="html4stricthtml">

<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]]