Apex Code Development You need to sign in to do that
Don't have an account?
swestenzweig SSO Best Practices
Good afternoon. I am looking at implementing an SSO solution between a 3rd party application and SalesForce.com. One of the "requests" for the SSO solution is that the user login from SalesForce. For business reasons associated with a federated approach, I have been asked to provide a solution that does not use a federated model. Hence, I am investigating the delegated authentication approach detailed by SalesForce documentation. In the delegated authentication approach, however, if the user is going to login using the SalesForce login page it does not appear that a true single sign-on solution can be attained to the 3rd party application. I'll explain my understanding, but please offer any corrections:
From the Salesforce login page, once a user enters his credentials SalesForce checks to see if the user is designated for delegated authentication. If so, a web service request including the user's username, password, and source IP is sent to the 3rd party software (which implements the web service) for authentication. After authenticating, the 3rd party software returns only a boolean result to SalesForce. SalesForce then creates a secure session for the user. The problem I see, conceptually, is how the session is persisted on the 3rd party software as no session information is passed via the webservice? As such, any time a user accesses a resource on the 3rd party application, the user would need to re-authenticate as there is no method of persisting the authenticated session between the SalesForce and the 3rd party software.
I realize there is a solution using the 3rd party software login (and forwarding a token back to SalesForce for delegated authentication) and creating a session on the 3rd party application first, but I want to be sure there is no reasonable solution using the SalesForce login first.
Thanks in advance for any insight.
How does the user get from the salesforce.com application to the 3rd party application, is it a link or tab in salesforce? if so you can configure it to pass a sessionId & serverUrl that the 3rd party can use to verify that the user has a real salesforce.com session, and can then use that information to create/map the user into a user/session in the 3rd party app.
Thanks for the response, Simon. Ideally, the goal is to be able to deep-link into the 3rd party application from SalesForce. One of the objectives is to minimize the amount of custom code required on the SalesForce.com side, but if passing the sessionId and serverUrl is as simple as pulling it off the session and forwarding it on I think that could be a reasonable compromise. There is only one thing I am not clear on: how would the 3rd party software validate the sessionId?
It would make an api call to salesforce using the sessionId.
I have been successfully able to implement a single sign-on solution which authenticates through a third-party software and creates a session on SalesForce.com utilizing delegated authentication.
In looking at the settings on the SalesForce.com developer instance I was using for testing, I discovered a *new* setting under "Security Controls" which allows you to set an Identity Provider. One of the reasons for implementing an SSO strategy like I've deployed above was because SalesForce.com would not act as an IdP; it appears that SalesForce.com can now be used as an IdP. I am very interested in learning more about this new capability.
Is this capability fully deployed and available to all SalesForce.com instances or is this still pre-release?
Are there any limitations SalesForce.com has when acting as an IdP?
Will SalesForce.com work with any SP that implements SAML 2.0?
Where can I find detailed technical documentation about this?
Thanks!