0

I'm new to security concepts. I am studying how SAML works and I'm confused about how IDP sends SAML assertion to SP. I searched on the internet and I found out two scenarios are possible. First is when you authenticate to an IDP, the IDP sends the browser a SAML file and the browser will use it as a token to authenticate to SP. Second is when you authenticate to an IDP, the IDP sends the SAML file to all of the SPs and then SPs know you and you can use them. I have two questions. First How exactly SAML file is sent from IDP to SP??? And when user authenticates to an SP in this manner who gives authorization to the user???

Sobhan Safdariyan
  • 3
  • 1
  • I suggest taking a look at the [Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0](https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) and specifically section 4.1, Web Browser SSO Profile. – ComponentSpace Dec 06 '20 at 01:50
  • thank you... it really helped @ComponentSpace – Sobhan Safdariyan Dec 15 '20 at 09:12

1 Answers1

2

Typically the user (whose identity is the thing in question) authenticates to the IdP using a web login form in a browser (or something like that involving sending credentials over HTTPS). The IdP returns a SAML message to the user's browser in the HTTPS response body, or possibly in a Location (redirect) header. The browser then sends an HTTPS request to the SP, passing the SAML either in the URL (query string, usually a GET request) or in the request body (usually a POST request). The SP then verifies that the SAML is from a trusted IdP and hasn't been tampered with.

At this point the SP knows the user's identity. The SP uses this to determine what services / resources the user is permitted (authorized) to access. The SP also often gives the user it's own session token (possibly a JWT) for ongoing access, rather than continuing to use the SAML.

If the SAML was conveyed via the URL, it is essential that it be single-use (or at least expire extremely quickly), as URLs are less secure than HTTP message bodies due to frequently ending up in logs, etc.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • a couple of comments for additional clarity, even though everything you said is technically correct... First, while redirect is a valid transport method, it shouldn't be used for carrying the assertion to the SP, it exposes the token too readily from a security perspective resulting in data leakage. The second is that authorization is usually "negotiated" based on attributes in the assertion above and beyond username, such as group identifiers sent as well. – Andrew K. Dec 07 '20 at 16:02
  • Very good point about the weakness of SAML in the URL. In my experience it can be done safely if the SAML is single-use (or at least sufficiently short-lived to be effectively single-use) as by the time it might leak anywhere such as a log, it is no longer usable. However, it's definitely best to keep any kind of security token out of URLs entirely. – CBHacking Dec 09 '20 at 05:39
  • The HTTP-Redirect binding doesn't support SAML responses as the resultant URL can be too long for some browsers. Of course, the other advantage of the HTTP-Post binding is that the SAML response is encrypted at the TLS layer and therefore, in many instances, encrypting the SAML assertion is unnecessary. – ComponentSpace Dec 16 '20 at 07:26
  • @ComponentSpace URLs (including their parameters in HTTP GET requests) are also encrypted by TLS. Not that you claimed otherwise, but you kind of implied it. The reason you want to avoid secrets in URLs is because URLs sometimes are written into logs (by servers and/or clients) that might later leak, not because the URLs are sent in plain text. – CBHacking Dec 16 '20 at 08:13
  • @CBHacking Thanks for the clarification. The implication wasn't intended but my wording should have been better. – ComponentSpace Dec 16 '20 at 22:46