Identity Confirmation
Background
What is happening?
In an effort to enhance security for our users and customers, salesforce.com has implemented various Security and User Authentication upgrades in the area of Identity Confirmation.
Education
Is there a way that I can be alerted to new security threats as they are discovered?
Yes - partners can subscribe to the Security Alerts page (click the Security Alerts icon to the right), which will be updated with information on threats and concerns as they are discovered. As always, customer facing security information can be found at trust.salesforce.com/security.html.
How do I view a replay of the Partner security webinar?
Replay the Partner Security Webinar from Nov. 16, hosted by Jim Cavalieri, SVP Technology Strategy.
How is this being messaged to customers and developers?
We hosted a security webinar for our customers; you can watch the recording here.
Technical Background
Watch the webinar highlighting the 3 changes!
What changes have been made?
There are 3 major changes occurring that affect how identity confirmation works:
1. [Web UI] Login Activation - In order to login into Salesforce.com using a web browser, the user will need to activate his/her computer. This is done by clicking on an email link received after first successful login attempt. Once the link has been selected, the security authentication will be activated and the user will now be able to login into Salesforce.com from that computer.
Note: If you have logged into Salesforce within the last few months from your regular computer, we have added your IP address to our list of trusted networks and this activation will NOT be necessary.
2. [Web UI / API] Network Access / Trusted IP Ranges - In order to leverage the Force.com Web Services API, the IP address of the client will need to exist on a list within the targeted Salesforce.com customer org. This list is known as Trusted IP Ranges which is stored in each Salesforce.com org.
- Prior to activation of this new feature, we have been tracking usage of the API Login() call (over the past number of months) and cataloging IP addresses that use this call for each customer org. This list of IP addresses is the starting point for our Trusted IP Ranges for each customer org. Customers will notice their Network Access list is pre-populated with these IP addresses.
- NOTE: New customers will need to manually add their API client (or server) IPs and/or IP ranges to the Network Access list within the Setup area of their Salesforce.com instance. Once this is done, they will be able to successfully access the API
3. [API] Security Token - If the client's IP address is not on the Network Access list, the client will NOT be able to login via the Force.com Web Services API using your standard Salesforce.com username and password. Instead, you will need to generate a Security Token within the Setup area. You can then append the Security Token to your password and use this as your new password to grant API access. Once the client IP address has been added to the Network Access list, they can choose to either use the password+token or password to login.
Note: The Security Token is tied to the user password, so if the password is reset or expires, then user will need to reset and generate a new security token.
Common Questions
Will I have to re-code my Force.com AppExchange app to comply with this change?
No, this primarily affects the customer user experience on Login. Technically, there are NO code changes involved for partners.
Will the Security changes affect my Test Drive?
Yes, but we have taken proactive measures to prevent any future issues. In the event your Test Drive org was not included, please log a support case here.
What should we do to prepare for this change?
Document your service IP addresses and provide these to your customers. Become aware and review our educational materials on Security. Visit https://trust.salesforce.com/security.html on a regular basis to stay up to date with security best practices. Update your documentation and user guides to include these security tips and guidance. Inform your support staff to prep for potential customer calls experiencing problems traced back the use of the API Login() call.
If I understand this correctly, I think our application will stop working come Monday morning unless we can get to our customers and add our IP addresses into their org. Is this true?
No. Existing customers will have your server IP address added to our Trusted IP Ranges automatically. They will see a list of pre-populated IP address based on usage of the last few months in their Network Access list. New customers will have to add your IP addresses to their trusted networks in their org (set IP address range on profile).
Where can developers get the latest technical details on how the new API Login() call behaves?
Please visit the ADN for the latest revision to the API docs. This will be updated ahead of the release.
How will this effect AJAX or FLEX salesforce.com applications that use a sessionid to login?
No effect at all. The changes discussed apply only to the API Login() call.
Do you need to setup IP ranges Profile by Profile or can it be done org-wide now?
There is no change to the way you set Login restrictions. This cannot be done org-wide in EE or UE; you need to set this up profile by profile. As outlined in help:
- For Enterprise Edition, Unlimited Edition, and Developer Edition, click Setup | Manage users | Profiles, and select a profile, then click New in the Login IP Ranges related list.
- For Professional Edition, Group Edition, and Personal Edition, click Setup | Security Controls | Session Settings, and then click New in the Login IP Ranges related list.
Do you need the username and token for sites that have been added to the Trusted IP Ranges?
No - The customer can choose to provide their web client credentials (username/password) for login through your application, as long as the IP address where Login() call is coming from is part of the Trusted IP Range.
Are the tokens for API logins for each time you login or one time only?
The security token is persistent; it is valid until the user changes their password or resets their security token.
How does the token work, does it need to be concatenated or appended to the password?
Yes, so for instance:
If your password = mypassword
And you security token = XXXXXXXXXX
You must enter "mypasswordXXXXXXXXXX" (without quotes) in place of your password