You need to sign in to do that
Don't have an account?
GoForceGo
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
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
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?
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?
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!
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
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).
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...
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.
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
Is there any other way of notifying Salesforce (available in Professional Edition) that an external event has occurred that does not require Username/password?
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.
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
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