With last month’s announcement of Salesforce Mobile Services, the company introduced ten services that included Social, Identity, Trust, Geolocation, and Data services (both customer and offline). At the core of these services is a new feature, Connected Apps, that has until now only been available in a pilot program for new development orgs. However, Connected Apps will become generally available with the release of Summer ’13. So what exactly are Connected Apps?
A “Connected App” is an external application that can securely connect to Force.com over Identity and Data APIs. Connected Apps essentially describe a relationship between an external application and a Salesforce user, and define an entry point into the platform. The benefit of this relationship is that the user can access Force.com resources without revealing their sensitive login credentials and passwords to the application.
If you’ve worked with Remote Access Apps, you may already be familiar with Connected Apps, which used standard OAuth to authenticate, provide Single Sign-On, and acquire access tokens for use with Salesforce APIs. However, Connected Apps add additional levels of control, allowing administrators explicit control over who can use the application. As you’ll see, Connected Apps also allow one or more security policies to be enforced by the application.
Connected Apps Process
The process for creating a new Connected App starts with defining the OAuth metadata about the application. The metadata includes:
- Basic descriptive and contact information for the Connected App
- The OAuth scopes and callback URL for the Connected App
- Optional IP ranges where the Connected App might be running
- Optional information about mobile policies the Connected App can enforce
Once you’ve defined the metadata you’ll receive an OAuth client Id and you’ll be able to reveal the client secret. You can also view the install URL for the Connected App, which you or the administrator will need to install the app. (You’ll need administrator privileges to install the Connected App into your org.) The administrator can then use profiles, permission sets, and IP range restrictions from a detail page to control which users can access the application. Note that if you change or make modifications to the Connected App, the administrator will need to update it.
Creating a New Connected App
As previously mentioned, Connected Apps is in GA as of the Summer ’13 release. You’ll find Connected Apps in the development environment by going to Setup > Create > Apps. This will present the screen shown in Figure 1.
Figure 1 - Creating a new Connected App
Below the standard Apps pane, there’s a second section entitled Connected Apps. Click New next to Connected Apps, at which time you’ll be presented with a screen like Figure 2.
Figure 2 - Configuring your Connected App
Fill in the Basic Information section noting that the programatic Connected App name must be unique across the entire platform. The API Integration section controls how your app communicates with Force.com, and specifies the endpoint that Salesforce calls back to your application. If the external application issues a certificate, you can check the digital signature box and upload the certificate.
Next you’ll notice that you can now select scopes for OAuth authentication. OAuth lets users authorize applications to access Force.com resources (via the Force.com REST and SOAP APIs) on their behalf without revealing their passwords or other credentials to those applications. Alternatively, applications can directly authenticate to access the same resources outside the context of an end user. So, these scopes reference the permissions given by a user running the Connected App, and offer finer granularity over access and management of basic information, data, Chatter feeds, and others as noted. Be aware that if you’ve enabled Remote Access apps in a prior release, you should follow the best practices discussed in the release notes. For example, users in the same org as the app was created may still have automatic approval for the app even though permissions were set to “No user approval required.”
Figure 3 - Setting OAuth2 Scopes
Checking Screen Locking and Pin under Mobile Integration gives the administrator the ability to set the session timeout and PIN length for mobile apps. Finally, a Supported App lets you redirect users (through either a POST method or GET request) to a third-party app when they click on your Canvas app.
Figure 4 - Setting the access method for a Canvas app
Next Steps
Now that your metadata is defined, you can whitelist the IP Ranges for the addresses that can access the app without requiring the user to authenticate and publish your app. If you’d like to learn more about Force.com’s support for OAuth 2.0, I highly recommend Pat Patterson’s excellent article, Digging Deeper into OAuth 2.0 on Force.com. If you’re using web services to integrate an application from a language like Java, Ruby or .Net, see Getting Started with the Force.com REST API.
Resources
Getting Started with the Force.com REST API
SAML: Security Assertion Markup Language