function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Delegated Authentication for SFDC contacts

We have purchased SFDC Enterprise Edition and we are looking for a way to have our clients (contacts in SFDC) submit/view cases directly into/from SFDC.

We were looking at self-service portal in SFDC, but this portal doesn't seem to work for our company for a following reason. Our accounts in SFDC have been configured as a hierarchy accounts (For example: Corporate Office->Continet Office->Regional Office->City Office->...) and there are contacts on each level. Our contacts need to be able to add/edit cases for their accounts as well as all child accounts (basicaly have the same hierarchy in portal). It seems like SFDC self-service portal cannot do that. Am I correct?

We are thinking about writing our own portal that would work directly with SFDC database. Is it possible? If yes, can you please give us an advice on how to do following?

- Single sign-on from our product (web based application) directly to SFDC (Contact level users)
- View issues based on SFDC hierarchy
- Uploading files to SFDC from our portal

Thank you

I believe you should take a look at the sForce 6.0 preview document that was recently posted in the Announcements forum. Right now there is no way to so SSO with Self-Service users, but I believe some Self-Service user information is being exposed in 6.0 that may make what you're looking to do viable.

I don't think we can wait for SForce 6.0 release. Any ideas about workaround? I'm open to any suggestion.

Thank you.

In Summer '05, the general flow will be:

1) Verfiy the user is logged in to your website. If they are not logged in to your website, you should not automatically log them into the self service portal
2) If they are logged in to your website, then you need to know what their Self Service username is. There should be a mapping from your internal user to the Salesforce CSS user
(This can either be an automatic mapping, or you could store this mapping in your internal database. In your internal database, you'll want to store the username and the ID of the self service user)
3) If you need to create a SelfService User for them, do so. Store the information in your local database for future use
4) Log them into Salesforce. You have two options for the password. One option is go give all the self service users a complex password that is only known to this integration. Another option is to create a unique password for each user, and store that in your local database. You can use the setPassword function to set a password for a CSS user

Given that you can't programatically create users, or set their passwords, I've heard of one workaround, but it wouldn't work for a large number of users. When you create the self service user, you use an email you own. You login with that email, change the password to a set password, then change the email back to the original user. You login using the same steps as above (one shared pass).

We're also working to apply delegated authentication to self service users.

We would like to do something very similar, but different.

Here is the flow we'd want:

* User logs into Self Service Portal
* User clicks link TO our application from the Portal
* We want some way of verifying that the user is who they say they are, preferably by being able to verify the session that is passed to us from the Portal link
* We don't want a separate authentication in our application since Salesforce already has it

It sounds like this might be coming later.
I think this request just came to me from your CSM, if no, this is an odd coincidence

Here's what I came up with, curious to get your feedback:

In Summer '05, customers can call the getServerTimestamp API call with a valid self service user session id, so if that call returns, you know the sessionId is valid. Today, the API is closed to self service users and their SIDs.

You can add a link like this on your self service homepage, which should open a new window to your site, and automatically verify the user based on the info passed in the URL

<A href="{!User_Session_ID}&apiendpoint={!API_Partner_Server_URL_50}&userid={!User_ID}&documentid=123456" target=_blank> 

Then the sessionId can be used to verify the user is logged in (by making a successful call to getServerTimestamp), and the userId can be used to match them up on the company system. Note that any of the self service merge fields could be used: Username, email, custom fields, etc

This requires an organization that has API access, and knowledge of a language such as Java, C#, VB.NET, Perl, or another language that supports web services. Information on how to call getServerTimestamp is in the API documents at

Message Edited by benjasik on 06-05-2005 04:05 PM