2

In ruby-saml gem, we have the below options config for deciding whether to sign certain request/response:

  settings.security[:authn_requests_signed]   = true     # Enable or not signature on AuthNRequest
  settings.security[:logout_requests_signed]  = true     # Enable or not signature on Logout Request
  settings.security[:logout_responses_signed] = true     # Enable or not signature on Logout Response
  settings.security[:want_assertions_signed]  = true     # Enable or not the requirement of signed assertion
  settings.security[:metadata_signed]         = true     # Enable or not signature on Metadata

Using a certificate will ensure we are talking to who we think we are talking to. Why would anyone ever want to set these config to false?

Henry Yang
  • 2,283
  • 3
  • 21
  • 38

1 Answers1

5

This is a common issue with SAML implementations. While in some scenarios the signature is legitimately optional at the protocol level, there are other scenarios where it's not optional...yet implementations unfortunately allow this.

ruby-saml implements the Service Provider (SP) aspect. With respect to the SAML spec

  1. The service provider may sign the authentication request (AuthNRequest). The protocol allows the authentication requests to be unsigned. This setting also informs the value of an optional AuthnRequestsSigned attribute in SAML metadata generated by the library; this attribute communicates to the identity provider whether the service provider is going to be signing requests. Best practice - sign the request.

  2. The service provider must sign the logout request (LogoutRequest) in front-channel SLO. The library is violating the spec if it allows this request to be unsigned. From the spec:

4.4.4.1 Usage

The requester MUST authenticate itself to the responder and ensure message integrity, either by signing the message or using a binding-specific mechanism.

While some implementations insist that https can be thought of as a binding-specific mechanism, server-side https does provide message integrity in flight but it certainly does nothing to authenticate the requester. The signature is a much stronger guarantee that the requester isn't some random third party sending a DoS-like logout request to the identity provider.

  1. The service provider must sign the logout response (LogoutResponse) in front-channel SLO with POST/Redirect bindings. The library is violating the spec if it allows this response to be unsigned. From the spec:

Section 4.4.3.4 Session Participant/Authority Issues <LogoutResponse> to Identity Provider

The <LogoutResponse> message MUST be signed if the HTTP POST or Redirect binding is used.

  1. The service provider expects a signature on the response it receives from the identity provider. The structure of the response message is such that there's an overall Response element which includes an Assertion element. The spec requires that the response OR the assertion OR both response and assertion are signed.

This setting also informs the value of an optional WantAssertionsSigned attribute in SAML metadata generated by the library; this attribute communicates to the identity provider whether the service provider will want the assertion to be signed in addition to any signatures required by the spec. Many commercial identity providers will sign both the assertion and the response but some will only sign either.

  1. The SAML metadata spec recommends that the metadata be signed.

Section 3 - Signature Processing

Various elements in a metadata instance can be digitally signed (as indicated by the element's inclusion of a <ds:Signature> element), with the following benefits:

  • Metadata integrity
  • Authentication of the metadata by a trusted signer

A digital signature is not always required, for example if the relying party obtains the information directly from the publishing entity directly (with no intermediaries) through a secure channel, with the entity having authenticated to the relying party by some means other than a digital signature.

Many different techniques are available for "direct" authentication and secure channel establishment between two parties. The list includes TLS/SSL, HMAC, password-based mechanisms, etc. In addition, the applicable security requirements depend on the communicating applications. Additionally, elements can inherit signatures on enclosing parent elements that are themselves signed.

In the absence of such context, it is RECOMMENDED that at least the root element of a metadata instance be signed.

So the really egregious issues are allowing the LogoutRequest and LogoutResponse to go unsigned.

identigral
  • 3,920
  • 16
  • 31