iTranslated by AI
What I Wanted to Know After Reading 'Introduction to SAML'
Introduction
When starting to learn about SAML authentication, Introduction to SAML is very easy to understand and highly recommended. However, I encountered some stumbling blocks during actual implementation, so I've summarized them in this article. In this post, I will cover the following topics:
- Trusting IdP Certificates
- Cookies when receiving SAMLResponse
- CSRF measures for IdP-initiated SSO
- Single Logout specifications
- Necessity of Single Logout implementation
Trusting IdP Certificates
First, let's talk about trusting IdP certificates. When setting up SAML authentication, you register the IdP certificate with the SP. At that point, I wondered whether I should just trust the IdP certificate provided.
In TLS, you typically verify whether a certificate is signed by a Certificate Authority (CA). I wasn't sure if a similar flow was required for SAML authentication.
I couldn't find a definitive answer in the specifications on how to handle this, but I found a site (PingIdentity) that mentions certificate handling.
According to this article, TLS and SAML use different trust models, and it is fine to trust only the uploaded certificate. This allows for the use of self-signed certificates.
On the other hand, there are benefits to using a certificate signed by a CA. If a partner verifies the certificate chain, the current certificate can be included in the SAMLResponse, etc., and used for signature verification. By doing this, you don't need to worry about the certificate's expiration date.
Since this depends on the IdP, I think it's generally fine to start by trusting only the IdP certificate uploaded to the SP.
Cookies when receiving SAMLResponse
Next, regarding cookies when receiving SAMLResponse. The SAMLResponse sent in step 7 of the following sequence diagram contains an InResponseTo field, which the SP needs to verify. At this point, I mistakenly thought that cookies would not be sent because it is a cross-origin request. In fact, since it corresponds to a simple request, cookies are also sent.
The response returned from the IdP to the user agent looks roughly like the following, and it executes a form element submit using JavaScript. Since this meets the conditions for a simple request, cookies are sent.
Therefore, by saving the Request ID using the session when creating the SAMLRequest in step 2 of the sequence diagram, the SP can compare the Request ID with the InResponseTo value when it receives the SAMLResponse.
Because I misunderstood this point, I initially used a somewhat roundabout method of storing the Request ID in a KVS when I first started the implementation.
<form name="samlform">
<input name="SAMLResponse" value="...">
<input name="RelayState" value="...">
</form>
<script>
document.samlform.submit();
</script>
CSRF Measures for IdP-initiated SSO
InResponseTo functions as a countermeasure against CSRF. However, in IdP-initiated flows, InResponseTo is not present, so CSRF protection is not possible. This issue is also pointed out in ritou's article, and it's one of the elements that makes SAML feel a bit questionable.
Since no specific countermeasure seems to be mentioned in the specifications, I think it's important to simply keep this risk in mind.
Single Logout Specifications
In the specifications, Single Logout (SLO) is represented by the following sequence diagram.
In the case of SP-initiated logout, it starts from step 1. If there are other SPs authenticated via SAML, steps 3 and 4 are repeated.
In the case of IdP-initiated logout, it starts from step 3. If there are other SPs authenticated via SAML, steps 3 and 4 are repeated.
The difficult points here are the method of sending the LogoutRequest/LogoutResponse and the signatures.
(Quoted from SAML Profile 4.4.2 Profile Overview, Figure 3)
How to send LogoutRequest/LogoutResponse
Sending LogoutRequest in SP-initiated logout
Regarding sending an SP-initiated LogoutRequest, the specifications state the following:
(SAML Profile 4.4.2 Profile Overview, line 1171)
The request may be sent directly to the identity provider or sent indirectly through the user agent.
In other words, the LogoutRequest can be sent directly to the IdP or indirectly via the user agent. In this case, just like when sending a SAMLRequest, it is sent according to bindings such as HTTP POST Binding or HTTP Redirect Binding.
Returning LogoutResponse after receiving LogoutRequest from IdP
When receiving a LogoutRequest from the IdP, the specifications state the following:
(SAML Profile 4.4.2 Profile Overview, line 1186)
The response may be returned directly to the identity provider or indirectly through the user agent (if consistent with the form of the request in step 3).
This means that the LogoutResponse should be returned using the same method as how the LogoutRequest was received. This handling feels quite complex.
Furthermore, if the SP does not behave correctly or if an error occurs, there is a risk that the entire Single Logout process will fail, preventing the destruction of sessions in other SPs. This is briefly mentioned in the SAML2P Documentation.
Signatures
Signatures are mandatory for both LogoutRequest and LogoutResponse. Therefore, when supporting Single Logout, the SP must manage a private key for signing and register a certificate for signature verification with the IdP.
Necessity of Single Logout Implementation
By using Single Logout, if there are other SPs authenticated via SAML, you can also terminate those sessions. However, when looking through help documentation for products that implement SAML, I found very few that encouraged users to register SP certificates with the IdP or set a Single Logout URL in the IdP. As a result, I began to wonder if supporting Single Logout is even common in the first place.
Furthermore, looking at the help pages of various products, I found many cases where SCIM (Salesforce, Udemy, ...) is used when deactivating users in the IdP.
Therefore, my current opinion is: perhaps there's no need to implement Single Logout? The idea I have is that SAML only provides SSO, and session termination via Single Logout is not performed. Instead, account management, such as account deactivation, is handled via SCIM. (This is strictly my personal opinion. If there is a general consensus that it should be done differently, I would appreciate it if you could leave a comment.)
Conclusion
Although it's not very well organized, I've written about things I didn't understand just by reading 'Introduction to SAML'. My understanding of SAML authentication is still shallow, so if anyone has any opinions, I would appreciate it if you could leave a comment.
Also, while learning SAML authentication, I tried implementing it in Golang. Although there may be some flaws, it might be of some reference.
References
Help documents for products that implement SAML were surprisingly useful.
-
- SmartHR supports SP-initiated Single Logout
-
- "16-1. About Single Sign-On settings using SAML authentication"
Discussion