users to access multiple services without logging in multiple times. For example, if you are logged into facebook.com, you wouldn’t have to re-enter your credentials to use messenger.com. If you login into www.google.com, then you are automatically logged-in to all services offered by Google such as mail.google.com, www.youtube.com, play.google.com etc which saves time and effort to re-login.
open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP). What that jargon means is that you can use one set of credentials to log into many different websites.
The Service Provider (SP) sends a redirect to the Identity Provider (IDP) 3. The User-Agent follows the redirect an access the IDP. The request contains a SAMLRequest parameter. 4. The IDP sends back a response with a SAMLResponse. 5. The SAMLResponse is submitted by the User-Agent to the SP. 6. The user is now logged in for the Service Provider and can access the resource. How SAML Authentication works?
The SAMLResponse that is sent by the IdP to the User-agent or the browser is sent by the browser to the SP (Service Provider). That request could be intercepted and an attacker can change the <NAMEID...> in order to change the user, say from firstname.lastname@example.org to email@example.com giving him admin access to the website.
If the XML signature logic incorrectly handles signature validation, an attacker can just exclude a signature to create a XML document that passes signature validation. If we remove the contents of SignatureValue and send an empty value, the server sometimes doesn’t verify it and that could be used to bypass the validation.
libraries will parse the saml:NameID element out of the XML tree, extracting the last text element inside of it and will use that value to identify the user logging in. But… What happens if you break the saml:NameID element up such that it contains an XML comment? <saml:NameID>adm<!-- this is a comment -->firstname.lastname@example.org</saml:NameID> In this scenario, the XML tree, when parsed, will look like so: NameID |_ Text: adm |_ Comment: this is a comment |_ Text: email@example.com And depending on the XML parsing logic used in the SAML library, you can probably see where this is headed: depending on where you insert a comment you can dramatically impact that identity of the user that’s being logged in! More info at: https://developer.okta.com/blog/2018/02/27/a-breakdown-of-the-new-saml-authentication-bypass-vulnerability
encrypted if this feature is supported by the SP. The AuthnRequest can be signed to help ensure the request is being sent by a trusted SP Use only SHA-2 certiﬁcates when designing new SAML workﬂows TLS v1.2 is the preferred protocol to use when establishing a connection to the SP – it is the only version providing modern authenticated encryption