Requirements are often phrased in terms of (mutual) authentication, integrity, and confidentiality, leaving the choice of security mechanism to implementers and deployers. The primary SAML use case is called Web Browser Single Sign-On (SSO). A user utilizes a user agent (usually a web browser) requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the requesting user, issues an authentication request to a SAML identity provider through the user agent.
General SAML Security
The following sections analyze the security risks in using and implementing SAML and describe countermeasures miniOrange SAML SSO plugin/module use to mitigate the risks.
- SAML Assertions:
At the level of the SAML assertion itself, there is little to be said about security concerns—most concerns arise during communications in the request/response protocol, or during the attempt to use SAML by means of one of the bindings. The consumer is, of course, always expected to honor the validity interval of the assertion and any elements that are present in the assertion. However, one issue at the assertion level bears analysis: an assertion, once issued, is out of the control of the issuer. This fact has a number of ramifications. For example, the issuer has no control over how long the assertion will be persisted in the systems of the consumer; nor does the issuer have control over the parties with whom the consumer/service provider will share the assertion information. These concerns are over and above concerns about a malicious attacker who can see the contents of assertions that pass over the wire unencrypted (or insufficiently encrypted). While efforts have been made to address many of these issues within the SAML specification, nothing contained in the specification will erase the requirement for careful consideration of what to put in an assertion. At all times, issuers should consider the possible consequences if the information in the assertion is stored on a remote site, where it can be directly misused, or exposed to potential hackers, or possibly stored for more creatively fraudulent uses. Issuers should also consider the possibility that the information in the assertion could be shared with other parties, or even made public, either intentionally or inadvertently.
1.1. SAML Protocol:
The following sections describe security considerations for the SAML request-response protocol itself, apart from any threats arising from use of a particular protocol binding.
1.1.1. Denial of Service:
The SAML protocol is susceptible to a denial of service (DOS) attack. Handling a SAML request is potentially a very expensive operation, including parsing the request message (typically involving construction of a DOM tree), database/assertion store lookup (potentially on an unindexed key),construction of a response message, and potentially one or more digital signature operations. Thus, the effort required by an attacker generating requests is much lower than the effort needed to handle those requests.
1.1.2. Requiring Signed Requests
miniOrange SAML SSO plugin/module signs request, also narrows the order of the asymmetry between the work done by the SAML plugin and responder. The additional work required of the responder to verify the signature is a relatively small percentage of the total work required of the responder, while the process of calculating the digital signature represents a relatively large amount of work for the requester. Narrowing this asymmetry decreases the risk associated with a DOS attack. Note, however, that an attacker can theoretically capture a signed message and then replay it continually, getting around this requirement. This situation can be avoided by requiring the use of the XML Signature element <ds:SignatureProperties> containing a timestamp; the timestamp can then be used to determine if the signature is recent. So the narrower the window of valid signature after the issue of response, the higher security you have against replay denial of service attacks.
2. SAML Bindings Security:
The security considerations in the design of the SAML request-response protocol depend to a large extent on the particular protocol binding (as defined in the SAML bindings specification [SAMLBind]) that is used. The bindings sanctioned by the OASIS Security Services Technical Committee are the SOAP binding, Reverse SOAP Binding (PAOS), HTTP Redirect binding, HTTP Redirect/POST binding and HTTP Artifact binding and SAML URI bindings. miniOrange SAML SSO plugins support Http-Redirect and Http-POST bindings.
2.1. HTTP Redirect binding
2.1.2. Denial of Service
Threat: Malicious redirects to Identity Provider or Service Provider targets.
Description: A spurious entity could issue a redirect to a user agent so that the user agent would access a resource that disrupts Single Sign-On. For example, an attacker could redirect the user agent to a logout resource of a service provider causing the Principal to be logged out of all existing authentication sessions.
Countermeasures: Access to resources that produce side effects are specified with a transient qualifier that must correspond to the current authentication session. Alternatively, a confirmation dialog could be interposed that relies on a transient qualifier with similar semantics.
2.2. HTTP POST binding
2.2.1. Stolen Assertion
Threat: If an eavesdropper can copy the real user’s SAML response and included assertions, then the eavesdropper could construct an appropriate POST body and be able to impersonate the user at the destination site.
Countermeasures: We maintain confidentiality whenever a response is communicated between SAML SSO plugin and the user’s browser. This provides protection against an eavesdropper obtaining a real user’s SAML response and assertions. If an eavesdropper defeats the measures used to ensure confidentiality, additional countermeasures are available:
● The Identity Provider and Service Provider sites SHOULD make some reasonable effort to ensure that clock settings at both sites differ by at most a few minutes. Many forms of time synchronization service are available, both over the Internet and from proprietary sources.
● When a non-SSO SAML profile uses the POST binding it must ensure that the receiver can perform timely subject confirmation. To this end, a SAML authentication assertion for the principal MUST be included in the POSTed form response.
● Values for NotBefore and NotOnOrAfter attributes of SSO assertions SHOULD have the shortest possible validity period consistent with successful communication of the assertion from Identity Provider to Service Provider site. This is typically on the order of a few minutes. This ensures that a stolen assertion can only be used successfully within a small time frame.
● The miniOrange SAML SSO plugin checks the validity period of all assertions obtained from the Identity Provider site and reject expired assertions. We choose to implement a stricter test of validity for SSO assertions, such as requiring the assertion’s IssueInstant or AuthnInstant attribute value to be within a few minutes of the time at which the assertion is received at theService Provider site.
● If a received authentication statement includes a <saml:SubjectLocality> element with the IP address of the user, the Service Provider site MAY check the browser IP address against the IP address contained in the authentication statement.
2.2.2. Forged Assertion
Threat: A malicious user, or the browser user, could forge or alter a SAML assertion.
Countermeasures: The browser/POST profile requires the SAML response carrying SAML assertions to be signed, thus providing both message integrity and authentication. The miniOrange SAML SSO plugin verifies the signature and authenticate the issuer.
2.2.3. Browser State Exposure
Threat: The browser/POST profile involves uploading of assertions from the web browser to a Service Provider site. This information is available as part of the web browser state and is usually stored in persistent storage on the user system in a completely unsecured fashion. The threat here is that the assertion may be “reused” at some later point in time.
Countermeasures: Assertions communicated using this profile must always have short lifetimes and should have a <OneTimeUse> SAML assertion <Conditions> element. Service Provider sites are expected to ensure that the assertions are not re-used.
2.2.4. Replay
Threat: Replay attacks amount to re-submission of the form in order to access a protected resource fraudulently.
Countermeasures: The miniOrange SAML SSO plugin mandates that the assertions transferred have the one-use property, preventing replay attacks from succeeding.
2.2.5. Modification or Exposure of state information
Threat: Relay state tampering or fabrication. Some of the messages may carry a <RelayState> element, which is recommended to be integrity-protected by the producer and optionally confidentiality-protected. If these practices are not followed, an adversary could trigger unwanted side effects. In addition, by not confidentiality-protecting the value of this element, a legitimate system entity could inadvertently expose information to the Identity Provider or a passive attacker.
Countermeasure: Follow the recommended practice of confidentiality- and integrity- protecting the RelayState data. Note: Because the value of this element is both produced and consumed by the same system entity, symmetric cryptographic primitives could be utilized.
3. SAML Profile Security
The SAML profiles specification [SAMLProf] defines profiles of SAML, which are sets of rules describing how to embed SAML assertions into and extract them from a framework or protocol.
3.1. Web Browser Single Sign-On (SSO) Profiles
Note that user authentication at the source site is explicitly out of scope, as are issues related to this source site authentication. The key notion is that the source system entity must be able to ascertain that the authenticated client system entity that it is interacting with is the same as the one in the next interaction step. One way to accomplish this is for these initial steps to be performed using TLS as a session layer underneath the protocol being used for this initial interaction (likely HTTP).
3.1.1. SSO Profile
3.1.1.1. Message Modification
Threat: The possibility of alteration of the messages in the stream exists for this set of profiles. Some potential undesirable results are as follows:
● Alteration of the initial request can result in rejection at the SAML issuer, or
creation of an artifact targeted at a different resource than the one requested
● Alteration of the artifact can result in denial of service at the SAML consumer.
● Alteration of the assertions themselves while in transit could result in all kinds
of bad results (if they are unsigned) or denial of service (if they are signed and
the consumer rejects them).
Countermeasures: To avoid message modification, the traffic needs to be transported by means of a system that guarantees message integrity from endpoint to endpoint. For the web browser-based profiles, the recommended method of providing message integrity in transit is the use of HTTP over TLS/SSL with a cipher suite that provides data integrity checking.
3.1.2. Single Logout Profile
Threat: Passive attacker can collect a Principal’s name identifier. During the initial steps, a passive attacker can collect the <LogoutRequest> information when it is issued in the redirect. Exposing these data poses a privacy threat.
Countermeasures: All exchanges should be conducted over a secure transport such as SSL or TLS.
Threat: An Unsigned <LogoutRequest> could be injected by a spurious system entity thus denying service to the Principal. Assuming that the NameID can be deduced or derived then it is conceivable that the user agent could be directed to deliver a fabricated <LogoutRequest> message.
Countermeasures: miniOrange SAML SSO plugin/module signs the <LogoutRequest> message. The Identity Provider can also verify the identity of a Principal in the absence of a signed request.
3.2. Name Identifier Management Profiles
Threat: Allow system entities to correlate information or otherwise inappropriately expose identity information, harming privacy.
Countermeasures: IDP must take care to use different name identifiers with different service providers for the same principal. The IDP should encrypt the name identifier it returns to the service provider, allowing subsequent interactions to use an opaque identifier.
3.2.1. Attribute Profiles
Threats related to bindings associated with attribute profiles are discussed above. No additional profile-specific threats are known.
4. Summary
Security and privacy must be addressed in a systematic manner, considering human issues such as social engineering attacks, policy issues, key management and trust management, secure implementation and other factors are outside the scope of this document. Security technical solutions have a cost, so requirements and policy alternatives must also be considered as a “must” legal and regulatory requirements. This non-normative document summarizes general security issues and approaches as well as specific threats and countermeasures for the use of SAML assertions, protocols, bindings and profiles in a secure manner that maintains privacy. Normative requirements are specified in the normative SAML specifications.
