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
GoForceGoGoForceGo 

Single Sign-On Questions


We have a client application that currently relies on knowing the administrator username/password to log in and read/update data in salesforce

When admins change their password or reset the security tokens, this creates big problems.

How does one solve this issue?

I am wondering if any of these can be used (in preferred order)

1. Salesforce acts as a the single-sign on authentication authority.

2. A "fake" single sign-on solution where we maintain the username/password for one user who has privileges similar to Admin (SFDC recommends that real admin not be put on Single Sign On). We would implement the Authenticate web service and return true.

3  A real single sign on solution where both our application and salesforce use a central username/password. I assume this is possible

4. Salesforce.com periodically polls our application to pull the data, instead of we callling it. How does one implement periodic polling?





Message Edited by GoForceGo on 11-28-2008 08:15 AM
RickyGRickyG
GoForceGo -

Are you sure that a single-signon is the direction you should be looking?  It sounds like your issues are coming from essentially hard-coding a value for username, password and security control in the client application.  As with any hardcoded values, these limit the flexibility of the application that uses them.

So if an admin changes the password or recreates the security token, your app becomes invalid.  How about creating Apex web services and using them to interact with the data?  Or did I miss interpret the design pattern entirely?
GoForceGoGoForceGo
I am not necessarily looking for Single Sign-On solution, but I don't see how else it would work.

The client application needs to interact with Salesforce. Within logging in through API with a username/password, how else would you do it?

Apex Web Services or Salesforce API can be invoked only after logging it.

Can you clarify what your thoughts are?





SuperfellSuperfell
You could use outbound messaging, and get notified of a data change that triggers your application, the OM can include a sessionId, so you can make api calls without knowing a username or password. You could also use a mergefield or webtab and have users come to your application from salesforce.com, again letting you get a sessionId without having to store credentials.
RickyGRickyG
Thanks, Simon - what a guy!
GoForceGoGoForceGo
Simon/Ricky

Thanks. This would work if a data change in SFDC is triggering a call to external application.

However, in my case, it is an event in the client application that is triggering a call to SFDC.

How would I solve it in that case.

I am sure I am not the only one struggling with this issue - all client applications have the same issue!



SuperfellSuperfell
Perhaps you can describe in more detail what your client application is and how a user would use it.
GoForceGoGoForceGo
The client application converts phone v-mails to text messages and attaches them as a custom object in SFDC.

So when a new v-mail comes on a specific phone number, SFDC API is invoked. We find the contact with that phone # and attaches a custom message object which has the text of  the v-mail.

There is no real UI in the client application - just API calls.












Message Edited by GoForceGo on 12-01-2008 09:14 AM

Message Edited by GoForceGo on 12-01-2008 09:23 AM
mazizmaziz
For this you could set up a new user that has just the required rights, which would be used uniquely for that purpose. That "user" would be less likely to change password or security token.

But I admit it's begging for a proper solution. I like your idea of having Salesforce periodically poll the data, but I don't think there is a scheduling API (yet).
GoForceGoGoForceGo
Yep, that might alleviate the problem a little - user who isn't likely to change password/token.

How about the 'fake' single-sign on solution I talk about? Essentially this user would have a profile with single sign-on enabled. Salesforce won't authenticate this user, and will call Authenticate Web Service implemented by a server that the client App knows about...



mazizmaziz
Your suggestion sounds interesting.

I've been looking around and apps like CronKit implement scheduling, which might help with periodic polling.

I've also wondered if your entire solution might not simply be implemented on force.com using an email service. If you want to keep your code on client side, you could still set up an email service on Salesforce and have that call your API or pick up the data whenever an email is received. That way your solution can initiate the process whenever it wants simply by sending an email.

GoForceGoGoForceGo
The Apex e-mail service is a great idea!

The only concern I would have is what happens when volume goes up. If number of e-mails received is high, Apex will be constantly calling our client apps.
Of course, on client side, we could control the number of e-mails that we sent out - we could "batch" them.









Message Edited by GoForceGo on 12-03-2008 06:03 PM
GoForceGoGoForceGo
Seems like Apex Email Services are not available in Professional Edition. I assume it won't be available even if we are certified App Exchange provider that can publish Apex code to a Professional Org.

Is there any other way of notifying Salesforce (available in Professional Edition) that an external event has occurred that does not require Username/password?






mazizmaziz
Well that ruins my party. Thanks for sharing, I am also interested in a solution. I will let you know if I come up with anything.
GoForceGoGoForceGo
Sorry! I will do likewise if I can think of anything.

Of course, the 'fake single-signon' solution is still an option, but it requires more work, more setup, and probably an extra user license.

And it won't work if an org already is using single-sign on, since you can have only one single sign-on URL.





mazizmaziz
I guess something like WebToLead (with workflow) could also be used for this. But we are entering the realm of ugly hack.

Though less of a hack if we use a custom object and sfdc-web2anything.


Message Edited by maziz on 12-08-2008 01:26 PM
RickyGRickyG
Well, if you are entering this territory, wouldn't it make sense to also look at Email Services?
GoForceGoGoForceGo
Hmmm....seems like Web-To-Lead does not require any User Id/Password? It just dumps the leads to Org ID using https://www.salesforce.com/servlet/servlet.WebToLead.

If someone knew your Org Id, could they just dump leads into your org?

I guess WebToLead could create a new 'fake lead' which can trigger an workflow outbound message?

Web2anything seems to require authentication.

Does sound like a hack!!

Ricky, as I said, it appears that email Services are not available in Professional Edition - otherwise it sounds like a good solution!





Message Edited by GoForceGo on 12-08-2008 02:31 PM