SuccessFactors by default will use IDP (Identity Provider) initiated in a SAML2 SSO setup.
- Client publishes a link somewhere that users click that initiates the SSO process on their side.
- Client sends us a SAML Response.
SP initiated means that the user starts by clicking on a SuccessFactors link.
- Typically something like https://performancemanger4.successfactors.com/login?company=danscompany.
- When SF 'seed' that URL, we send the customer a SAML Request. They send us back the Response and the rest is the same as IDP.
Why does SuccessFactors use IDP and not SP in most instances?
- SP implementation is often more problematic to enable
- While SuccessFactors are compliant with the standards, within the standards there are many ways a customer can configure the system on their end. This in itself introduces inconsistencies leading to problematic implementations.
- We have limited support of SP login URL’s. We need the "company=" variable to identify a SP initiated URL. When we see it’s an SP enabled instance we send out the Login Request. Without the company we can’t do that. and many URL’s in our application do not have the company. Therefore if a user bookmarks the page, many of them will fail when they try them later on.
- Customer’s that use SP Initiated SAML typically have users that expect the bookmarks to work.
- We recommend clients setup one link and use IDP login.
Does SuccessFactors Have Plans to Better Support SP?
To fully support SP, SuccessFactors would need to rewrite all of our application pages to support the company token. This is not a project that we have any plans to put on our current roadmap.
KBA , sf sso , LOD-SF-PLT , Foundational Capabilities & Tools , How To