Service Provider-Initiated SAML Flow
Amit Chaudhary

Amit Chaudhary

Amit Chaudhary is Salesforce Application & System Architect and working on Salesforce Platform since 2010. He is Salesforce MVP since 2017 and have 17 Salesforce Certificates. He is a active blogger and founder of Apex Hours.

Service Provider Initiated SAML Flow | SSO

Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials. For example, after users log in to your org, they can automatically access all apps from the App Launcher. You can use Salesforce as Identity provide (IDP) or as Service provider (SP).

In this session, we will talk about Salesforce As a service provider (SP). When a user attempts to access a service provider (SP) resource, the SP can redirect and request an identity provider (IDP) to authenticate and confirm identity.

NOTE: The system that authenticates users is called an identity provider. The system that trusts the identity provider for authentication is called the service provider

Service Provider Initiated SAML Flow Basic requirements

  • Participating systems support SAML 2.0 protocols and up to date recommended security countermeasures
  • SAML sign in URL, entity ID and certificate from IDP configured in SP
  • SAML ACS URL and entity ID from SP configured in IDP
  • If Salesforce is the SP, my domain must be enabled

Service Provider Initiated SAML Flow Video

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.
  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.

What else to know

  • Requests and assertions are XML
  • Implementation generally browser-based
  • SAML request bindings can be made on redirect / POST
  • Assertion Subject contains username / federation ID
  • Assertions are specific: Issuer, Audience, In ResponseTo, Issue Instant
  • Replay detection (AssertionId)
  • Optional extra security:
    • Request signing and verification
    • Assertion encryption
    • CA-signed X509 certificates
    • Session level
  • Custom attributes
  • Single logout
  • Registration handler & JIT provisioning

Considerations for choosing SP-Initiated SSO

  • Widespread and supported by many enterprise applications
  • Established and proven secure (when implemented well)
  • Standard implementation is browser-based:
    • No back channel required
    • Easy to debug

Think before

  • XML tokens suboptimal for mobile
  • Requires IDP to “know” the SP
  • Adequate only for basic info transfer from IDP to SP

Soon we will share all step to perform in Salesforce for Service Provider flow.

Further Learning

Share this article

Leave a reply

Keep in Touch

Subscribe for Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 3,229 other subscribers

Search

Our Supporter

RECENT POSTS

Apex Hours

Apex Hours is one stop platform to learn Salesforce skills and technology

Join our Newsletter and get tips and tricks how to explore the salesforce for free!