SAML Single Sign-On Flows

SAML Security

To understand how these SSO flows work, it’s important to understand how providers use SAML to exchange security information.

Tip To brush up on your SSO vocabulary, see Single Sign-On Terminology in Salesforce Help.

For both SAML SSO flow variations, the identity provider authenticates the user—confirms that the user is who they say they are. After the identity provider authenticates the user, it uses a SAML response to tell the service provider who the user is and what they’re allowed to do. It stores information about the user’s identity in a specific part of the response called the SAML assertion.

To signal that the service provider can trust the SAML response, the identity provider signs the response body, the assertion, or both. Whether the response body or the assertion is signed depends on the identity provider.

• If you use Salesforce as an identity provider, Salesforce signs the SAML response body and the assertion.
• If you use a third-party identity provider, check with your identity provider to see how they sign SAML responses.

When the service provider receives the SAML response, it validates this signature. How the signature is validated depends on the service provider.

• If you use Salesforce as an identity provider, check with your service provider to see how they validate signatures. Because Salesforce signs the response body and the assertion, it’s compatible with a variety of service providers.
• If you use Salesforce as a service provider, Salesforce can validate signatures in either the response body or the assertion. Salesforce first looks for a signature in the response body. If the response signature is missing or invalid, Salesforce then tries to validate the signature in the SAML assertion. Even if an attacker captures the SAML response from the user’s browser and tampers with the response body, the SSO login isn’t at risk as long as the assertion signature is intact.

  If your identity provider supports encrypted SAML assertions for extra security, you can also configure Salesforce to decrypt and validate these assertions.

Service Provider-Initiated SAML Flow

In a service-provider-initiated flow, the service provider begins the login process with a SAML request to the identity provider. Here’s how this flow works.

1. The user requests a secure session to access a protected resource in the service provider. For example, the user clicks a link to fill out a form in the service provider. But the form is a protected resource, meaning the user can only access it after logging in.
2. The service provider initiates login by sending a SAML request to the identity provider, asking it to authenticate the user.
3. The identity provider sends the user to a login page.
4. The user enters their identity provider login credentials and the identity provider authenticates the user.
5. The identity provider now knows who the user is, so it sends a cryptographically signed SAML response to the service provider. The SAML response contains a SAML assertion that tells the service provider who the user is.
6. The service provider validates the signature in the SAML response and identifies the user.
7. The user is now logged in to the service provider and can access the protected resource.

Identity Provider-Initiated SAML Flow

In an identity provider-initiated login flow, a SAML request is unnecessary because the identity provider starts the flow with a SAML response. An identity provider-initiated flow is a shortened version of a service provider-initiated flow. Here’s how this flow works.

1. The user logs in to the identity provider.
2. The user clicks a button or link to access the service provider. For example, the user clicks an app on the App Launcher page in a Salesforce org.
3. The identity provider initiates login by sending a cryptographically signed SAML response to the service provider. The SAML response contains a SAML assertion that tells the service provider who the user is.
4. The service provider validates the signature in the SAML response and identifies the user.
5. The user is now logged in to the service provider.

Example SAML Request and Response

<samlp:AuthnRequest ID="bndkmeemcaamihajeloilkagfdliilbhjjnmlmfo" Version="2.0" 
   IssueInstant="2010-05-24T22:57:19Z" 
   ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
   ProviderName="google.com" IsPassive="false" 
   AssertionConsumerServiceURL="https://www.google.com/a/resp.info/acs">
   <saml:Issuer>google.com</saml:Issuer>
   <samlp:NameIDPolicy AllowCreate="true" 
   Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
</samlp:AuthnRequest>

Here’s an example of a SAML response. In a service provider-initiated flow, the identity provider sends a SAML response after the service provider sends a SAML request. In an identity provider-initiated flow, the identity provider starts the flow by sending a SAML response.

<samlp:Response Destination="https://MyDomainName.my.salesforce.com?so=00Dx00000000001"
  ID="_0f551f9288c8b76f21c3d4d15c9cd1df1290476801091"
  InResponseTo="_2INwHuINDJTvjo8ohcM.Fpw_uLukYi0WArVx2IJD569kZYL
    osBwuiaSbzzxOPQjDtfw52tJB10VfgPW2p5g7Nlv5k1QDzR0EJYGgn0d0z8
    CIiUOY31YBdk7gwEkTygiK_lb46IO1fzBFoaRTzwvf1JN4qnkGttw3J6L4b
    opRI8hSQmCumM_Cvn3DHZVN.KtrzzOAflcMFSCY.bj1wvruSGQCooTRSSQ"
  IssueInstant="2010-11-23T01:46:41.091Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>https://myidp.my.salesforce.com</saml:Issuer>
−
<ds:Signature>
−
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
−
<ds:Reference URI="#_0f551f9288c8b76f21c3d4d15c9cd1df1290476801091">
−
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
−
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="ds saml samlp xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>4NVTbQ2WavD+ZBiyQ7ufc8EhtZw=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
−
<ds:SignatureValue>

ExampleSamlSignature</ds:SignatureValue>
−
<ds:KeyInfo>
−
<ds:X509Data>
−
<ds:X509Certificate>ExampleX509 Certificate</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
−
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
−
<saml:Assertion ID="_e700bf9b25a5aebdb9495fe40332ef081290476801092" IssueInstant="2010-11-23T01:46:41.092Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://exampleidp.com</saml:Issuer>
−
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">exampleuser@salesforce.com</saml:NameID>
−
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2010-11-23T01:51:41.093Z" Recipient="https://MyDomainName.my.salesforce.com?so=00Dx00000000001"/>
</saml:SubjectConfirmation>
</saml:Subject>
−
<saml:Conditions NotBefore="2010-11-23T01:46:41.093Z" NotOnOrAfter="2010-11-23T01:51:41.093Z">
−
<saml:AudienceRestriction>
<saml:Audience>https://exampleserviceprovider.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
−
<saml:AuthnStatement AuthnInstant="2010-11-23T01:46:41.092Z">
−
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
−
<saml:AttributeStatement>
−
<saml:Attribute Name="userId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">005D0000001Ayzh</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">admin@identity.org</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">exampleuser@salesforce.com</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="is_portal_user" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">false</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>