Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the OASIS Security Services Technical Committee (the organization).
SAMLÃ, 1.1 was ratified as the OASIS standard in September 2003. The critical aspects of SAML 1.1 are discussed in detail in official documents of SAMLCore and SAMLBind. If you're new to SAML, you should read the SAML introductory topic first, then the SAMLOverview document from OASIS.
Before SAML 1.1, SAMLÃ, 1.0 was adopted as the OASIS standard in November 2002. SAML has experienced one minor (V1.1) and one major revision (V2.0) since V1.0, which itself is the protocol is relatively simple. SAML 1.0 is more of a historical importance, however, since the US Federal E-Authentication Initiative has adopted SAML 1.0 as its core technology.
Fortunately, versions 1.0 and 1.1 of SAML are similar. See SAMLDiff for specific differences between the two standards. This article concentrates on SAML 1.1 as it is an important standard that lays the groundwork for many other standards and implementations.
Warning: The implementers and authors should note well that all sample code in this article is non-normative and only for illustrative purposes. See SAML OASIS specification for normative requirements.
Video SAML 1.1
SAML 1.1 Aserba
The statement contains the statement used by the service provider to make access control decisions. For example, the authentication statement confirms to the service provider that the principal does authenticate with the identity provider at any given time using a certain authentication method. Other information about the principal may be disclosed in the authentication statement. For example, in the authentication statement below, the principal's e-mail address is affirmed to the service provider:
E-mail addresses (as in the example above) will be sufficient in a large number of situations. In some cases, however, additional information is required before service providers can make access control decisions. For example, suppose students are allowed to access scholarship data. The attribute statement can indicate whether the principal has a "student" affiliate, used by the service provider to allow or deny access (resp.) To the scholarship application:
Attributes are often obtained from LDAP directories, so consistent attribute representation across security domains is critical.
In the example above shows how a student can gain access to a scholarship application, the service provider works well as a policy enforcement point and policy decision point . In some situations, it may be better to link the policy decision point with the identity provider. In this case, the service provider sends the URI to the identity provider confirming the authorization declaration deciding whether or not the principal should be granted access to the guaranteed resources at the given URI.
The three types of statements are not mutually exclusive. For example, both the authentication statement and the attribute statement can be included in a single statement (as shown above). This precludes the need to travel the next round between the service provider and the identity provider.
Maps SAML 1.1
SAML 1.1 Protocol
The SAML protocol is a simple request-response protocol. SAML requester sends SAML Request element to respondent:
Similarly, SAML respondents return the SAML element Response to the applicant:
The bindings and profiles required to influence the exchange of messages are detailed in the following sections.
SAML 1.1 Bindings
SAML 1.1 formally defines only one binding protocol , the SAML SOAP binding. A compatible SAML 1.1 implementation must implement SAML via SOAP over HTTP (binding sync protocol). Transport mechanisms other than HTTP are allowed, as long as independent aspects of the SAML SOAP binding protocol are observed (see section 3.1.2 SAMLBind).
SAML 1.1 SOAP binding builds on 1.1 SOAP version (the numbering is purely accidental). SAML requester wraps the SAML Request element in the SOAP message body. Similarly, the SAML responder returned the SAML Response element in the body of the returned SOAP message. If there is an error, the respondent returns a SOAP error code instead.
Every SAML markup should be included in the SOAP body. SAML 1.1 does not set any SAML specific SOAP headers. The applicant is free to include the desired SOAP header (though not required).
Remember that in SOAP 1.1, the HTTP header SOAPAction must be included with each HTTP request (although the value may be empty). The SAML applicant can assign the following values ​​to the header SOAPAction :
SOAPAction: http://www.oasis-open.org/committees/security
However, SAML respondents should not rely on this value.
Secure connection is not required for SAML requests and responses, but in situations where messages of integrity and confidentiality are required, HTTP over SSLÃ, 3.0 or TLSÃ, 1.0 with server-side certificates required.
The SAML Responder can return the "403 Forbidden" response when it refuses to respond to the SAML requestor. A respondent should return a "500 Server Internal Error" response in case of a SOAP error (SOAP error element must be included as well). Otherwise, the "200 OK" response is returned, even if there is a SAML processing error. Such responses will include the Status SAML element in the SOAP body.
SAML 1.1 Profile
In general, the profile describes the use cases and the exchange of messages needed to transfer the statement from the identity provider to the service provider. SAML 1.1 specifies two Web Browser SSO Profiles:
- Browser Profile/POST
- Browser Profile/Artefact
The Browser/POST profile relies on a "push" operation that passes the SSO statement with value through the browser using HTTP POST. We say that the identity provider "pushes" a statement to the service provider.
The Browser/Artefact Profile uses the "drag" mechanism. This profile basically conveys an SSO statement from an identity provider to a service provider by reference (via a browser using HTTP Redirect), which is then dereferenced via a reverse channel exchange (e.g., Service provider) withdraws "statements from the identity provider using SAML via SOAP over HTTP).
These profiles support cross-domain single sign-on (SSO). The specs do not specify any additional profiles. Specifically, SAML 1.1 does not support profiles for securing web service messages or does not support single outgoing profiles.
Both SAML 1.1 profiles begin on the inter-site transfer service , which is managed by the identity provider. How the principal arrives at the transfer service in the first place is not specified by the specification. See Sections 4.1 and 4.2 of SAMLOverview for possible scenarios. In practice, clients that access secure resources at the service provider will be transferred to an inter-location transfer service at the identity provider, but the exact sequence of steps required to achieve this is not described by SAML 1.1. (See section 4.3 of SAMLOverview for some rough ideas along this line.) This scenario is really discussed in SAMLÃ, 2.0.
After visiting the inter-location transfer service, the principal is transferred to the consumer service statement at the service provider. Exactly how the principal is transferred from the inter-site transfer service to the consumer service statement depending on the profile used. In the case of Browser Profiles/Artifacts, redirects are used; in the case of Browser/POST Profiles, the client issues a POST request (with or without user intervention).
To speed up processing by consumer service statements, two separate URLs are specified:
- Assertion Consumer URL (Browser/POST Profile)
- Artifact Receiver URL (Profile Browser/Artefact)
These and other endpoint locations can be recorded in the metadata file. Exactly how the identity provider obtains a trusted metadata file, or determines the location of trusted endpoints from a particular service provider, is outside the scope with respect to SAML 1.1.
Note that the appropriate SAML 1.1 identity provider must provide an inter-location transfer service. Similarly, the SAML 1.1 service provider must provide a consumer service statement.
Browser/POST Profile
Profile SAMLÃ, 1.1 Browser/POST sets out the following four steps (4). The terminology used in the original specification has been slightly modified to conform to the SAML 2.0 specification.
Message flow begins with a request directed at the IdP.
Request Inter-Location Transfer Service in IdP
Headmaster (via an HTTP user agent) requesting the Inter-Site Transfer Service at the identity provider:
https://idp.example.org/TransferService?TARGET= target
where target is the desired resource in the service provider, say, https://sp.example.com/home. In other words, the following GET request is issued by the user agent via SSL/TLS:
The profile does not specify how the URL to the Transfer Service (with the TARGET parameter) is obtained by the user agent.
Respond with HTML form
The Inter-site Transfer service returns an HTML document containing the FORM element:
where the TARGET parameter has been preserved from step 1. The SAMLResponse parameter value is the base64 encoding of the SAML Response element as follows:
The SAML response must be digitally signed by the identity provider.
Important: It is assumed that the principal has established a security context in the identity provider, otherwise the Inter-Site Transfer Service will not be able to provide authentication statements in the Response SAML element.
Requesting Assistant Consumer Services in SP
The user agent requests the Assertion Consumer Service at the service provider:
where the parameter values ​​ TARGET and SAMLResponse are extracted from the HTML form in step 2.
Note: To automate submission of forms, the following JavaScript lines can appear anywhere on the page:
This of course assumes that the page contains one element FORM ( form [0] ).
Responding to principal's request
The Assertion Consumer Service consumes the SAML Response element, creates a security context in the service provider and redirects the user agent to the target source.
Browser Profile/Artefact
The Browser/Artifact Profile SAMLÃ, 1.1 specifies the following six (6) steps. The terminology used in the original specification has been slightly modified to conform to the SAML 2.0 specification.
Message flow begins with a request directed at the IdP.
Request an Inter-Location Transfer Service in IdP
Headmaster (via an HTTP user agent) requesting the Inter-Site Transfer Service at the identity provider:
https://idp.example.org/TransferService?TARGET= target
where target is the desired resource in the service provider, say, https://sp.example.com/home. In other words, the following GET request is issued by the user agent via SSL/TLS:
The profile does not specify how the URL to the transfer service (with the TARGET parameter) obtained by the user agent.
Redirect to Assertion Consumer Service
The principal is transferred to the Assertion Consumer Service at the service provider, that is, the following responses are returned to the user's agent:
where artifact is a reference to the statement that the identity provider is willing to provide on request.
Important: It is assumed that the principal has established a security context in the identity provider, otherwise the Inter-Location Transfer Service will not be able to provide authentication statements.
Requesting Assisted Consumer Services in SP
The user agent requests the Assertion Consumer Service at the service provider:
https://sp.example.com/ACS/Artifact?TARGET= target & amp; SAMLart = artifact
where target and artifact is as before. In other words, the following GET requests are issued by the user agent via SSL/TLS:
Request Artifact Resolution Service at IdP
The Assertion Consumer Service at the service provider initiates a reverse exchange with the Artifact Resolution Service at the identity provider. SAML SOAP message is bound by HTTP POST request:
where artifacts were previously sent from the identity provider to the service provider in steps 2 and 3.
Respond with SAML Statement
The identity provider completes the back-channel exchange by responding with a SAML statement that is bound to the SAML SOAP message:
In this case, the authentication statement includes NameIdentifier which contains the primary e-mail address.
Responding to principal's request
Assertion Consumer Service parses the Response SAML element, creates a security context in the service provider and redirects the user agent to the target source.
See also
- SAML
- SAML 2.0
- SAML-based products and services
References
Source of the article : Wikipedia
0 Comments