Abstract

Force.com has a unified security layer that underpins all applications across all customers. Users are a pivotal resource within the framework, and various configuration choices can be made to customize how these users exist and interact with platform resources. While developers may not have to write code around user management and access, they still must understand what the platform offers in order to best meet the needs of their customers. The general process of managing users and their domain of influence in a system is often called identity management.

This article introduces identity management on Force.com. It looks at user provisioning, authentication and authorization, and points at the more advanced sign-on features such as SAML.

Introduction

The identity and access tools supplied by the Force.com platform are sophisticated enough to allow a developer or architect to completely automate user provisioning, for example by linking creation of platform users to the addition of an employee to a group in a corporate Active Directory deployment, or to implement Single Sign-on, a configuration where user authentication to Force.com is taken care of for the user, resulting in transparent access from a corporate Intranet to the platform.

This article provides an overview of the identity management features that are provided out of the box on the Force.com platform. The three basic concepts described in this article are:

  • User provisioning, or how user profiles are created and changed over time.
  • Authentication, or how users are identified and their identities validated.
  • Authorization, or how users are granted permission to specific resources.

Use of the web-based administration console, use of the Force.com SOAP API, and use of Internet standards are all discussed, and impact to developers of each choice are discussed.

Essentials of User Provisioning

The simplest way to create and manage users is by using the online Administration console under the Setup menu, found after you log on.

System Administrators and other users with the Manage Users permission can create users, assign licenses, reset passwords, disable users, and assign profiles to users. Force.com enforces several rules around changing user data:

  • Email address changes must be confirmed by the user.
  • Passwords cannot be explicitly set by anyone except the user, but they can be reset, forcing the user to set a new value.
  • Users cannot be deleted, they can only be deactivated.
Figure 1: Listing active users


User Authorization

Two primary mechanisms control user access to resources on the Force.com platform: profiles and sharing rules.

A profile is a template containing a collection of pre-defined settings that determine what a user can see and do within the platform. Profiles set the basic rules for whether a given user can see and use each application as well as each tab within the application.

Figure 2: Part of the profile configuration

Profiles also store permissions to view, create, modify, and delete both standard objects such as Accounts and Contacts, and custom objects, such as those that are used in the recruiting application described in the Force.com Fundamentals book. Profiles can be created, deleted, and altered on the Setup page, by traveling to Setup | Manage Users | Profiles.

Figure 3: Read/Create/Edit/Delete permissions on objects

Once a profile is created, rules can also be created to add or remove specific object fields from pages displayed to users with a given profile, by travelling to Setup | Security Controls | Field Accessibility.

Sharing rules are logic that allows you to enlarge the set of data records that a user can view or change. For example, creation of sharing rules associated with a public group or queue might be used to grant access for project members to temporarily see client records that they would normally not have access to. Sharing rules may overlap, if this happens, the more permissive rule always applies. More information on sharing rules can be found in the documentation.

If an administrator does no customization of profiles or sharing rules, existing default profiles and organization-wide defaults will determine what users can interact with. Standard profiles are created at the time of creation of the organization that include Standard User and a System Administrator. At the same time, organization-wide defaults are created for the organization as a whole. organization-wide defaults can be customized by going to Setup | Security Controls | Sharing Settings.

Figure 4: Organization-wide sharing defaults

You can also set a Sharing rule override; this can be used to bypass all the existing sharing rules and allow or restrict access for a given group or user. From a troubleshooting perspective, this new feature could save time for developers who are attempting to solve non-authorization-related problems, however this powerful feature must be treated with extreme caution in production environments, as it can be used to bypass important security rules.

When a new application is installed or enabled for a given organization, System Administrators should be advised to review the profiles and sharing rules in use for their user base, as new settings for visibility of the application, visibility of the tabs within the application, and access settings for custom objects that applications may have added to each profile.

Essentials of User Authentication

By default, web access to Force.com is granted by requiring users to provide a username and password that match values stored within Salesforce tables. Users are directed to a single form-based sign-in page to enter their credentials. Once users sign in, they can access any Force.com property that is authorized by their profile, including their own applications, Salesforce CRM, Portals, Sites, Ideas or VisualForce pages without re-authenticating.

Administrators are able to force a reset of single or bulk user passwords, as well as setting password policy around password expiration (forcing the user to reset their password after a certain time), password lockout (refusing access to an account if an incorrect password is used too many times), and requirements for length and complexity of new passwords. Password Policies are managed at Setup | Security Controls | Password Policies.

Figure 5: Configuring a password policy

Signing in From Desktop Clients, Mobile Devices, and other External Applications

When users interact with software that is not running directly on the Force.com platform, the software creates a session on behalf of the user, and uses that session to communicate with the platform. In order to do this, the software usually prompts the user for their login credentials and stores those credentials for repeated use. For security purposes, however, the platform requires that any external application connecting to the platform send one extra piece of information on behalf of the user - a security token. Note that administrators can configure their organization to forbid the use of external applications altogether.

What is a Security Token?

A security token is a long string of characters that is generated uniquely for each user. A user may regenerate their security token at any time and an administrator can force the regeneration of a security token. To use the security token, a user simply appends the security token string to the end of their password when setting up the external device or program.

Users may regenerate their security token by going to Setup | My Personal Information | Reset My Security Token

Figure 6: A typical token reset screen

Advanced User Management

Many larger organizations prefer to synchronize their platform user list with an authoritative user list stored internally within their own enterprise. Automating administration reduces typos and human error, and is often required as part of an enterprise security regime.

The ability to programmatically add and modify users is accomplished via the Force.com SOAP API. While there is no explicit user creation or modification methods within the web services API, developers can use generic object manipulation methods to create and modify the standard User objects, with some important caveats. User objects cannot be deleted, and not all of the fields within the User object can be viewed. API calls exist to set or reset user passwords (the latter sends an email to the user requiring them to set their own password). The API cannot set or read the user's security token, and cannot restore the status of a user who is locked out. Please see the Force.com SOAP API Developer Guide for more information.

Developers who are attempting to synchronize users in a corporate directory or other user repository to the platform must be sure to code for possible username collisions that may occur over time between the corporate repository and the Force.com repository; for example, if user jsmith is hired and terminated, it is possible that the user record in the corporate repository is completely removed, while the user record in Force.com is merely disabled. This will cause problems the next time a user is assigned the username of jsmith, as the creation of the user record in the corporate repository will succeed, but a collision will occur when a corresponding user record creation is attempted in the Force.com platform.

From a security perspective, it is not recommended to use a real person's credentials to connect to the Force.com platform to manage users; it is better to use a special account which is assigned a profile containing as few authorized privileges as possible; however, this is not always possible due to cost concerns around dedicated licenses. Developers will have to work to make the right choice based on the risk profile of their organizations or the organizations of their customers.

Advanced User Sign-on

Some organizations choose to implement technical mechanisms to remove the authentication step from a user's experience at Force.com. Instead of the user being required to enter their credentials upon first arriving at Force.com, transparent processes act on the user's behalf to transmit and validate credentials controlled by the organization, with the result that the user is seamlessly taken to a signed in session without any extra effort.

There are a number of reasons why an organization might make such a choice, including convenience for the user, as well as greater ability to control the risk of password compromise. The Force.com platform provides two alternatives for user sign-on.

Delegated Authentication

Delegated authentication is a configuration choice where an organization sets up a web services client (called a delegated authority) that replaces the Force.com mechanism for all sign-in decisions. The delegated authority can be set up to validate users in three different combinations:

  • Password Validation:
  • The Salesforce login page is used to collect a username and password, but the username and password are validated against the delegated authority instead of the internal Salesforce password store.
  • Token Validation:
  • The Salesforce login page no longer works for sign-in.
  • Users must first authenticate to their Enterprise, and the Enterprise must then create a Salesforce session by sending (via HTTP POST) the username and a token to Salesforce for validation by the delegated authority. Once this has occurred, the user may travel between Salesforce and the Enterprise without re-authentication.
  • When token validation is used alone, standard desktop clients such as the Outlook client cannot be used, because the client is incapable of generating and posting the token to Salesforce for validation.
  • Hybrid Model
  • Users are required to use token validation when accessing the Salesforce website directly, but are allowed to authenticate using password validation when using a client application.

Enterprises may choose to enable both tokens and password validation at the same time. If you are a Developer trying to troubleshoot an issue, it is a good idea to know what kind of sign-on configuration is in place. Keep in mind that the username/password authentication sent from an external application no longer requires a Salesforce security token to be successful, so it is a good idea to ask what kind of sign-on configuration is in place.

Figure 7: Single sign-on settings

Note that delegated authentication cannot be enabled using the Administration UI; you must contact salesforce.com support, and state via email that you understand the implications of using this sign-on format. In particular, replacement of the standard authentication mechanism with one that is faulty or insecure could put your corporate data at risk- so make sure that your delegated authentication system is extremely secure. Once delegated authentication is enabled for your organization, you must still turn on the “uses Single Sign-on” permission within each applicable user profile. It is recommended that your system administrators retain locally stored Salesforce passwords without any kind of Single Sign-on enabled. For more information on delegated authentication, see How to Implement Single Sign-On with Salesforce.com.

Federated Authentication (SAML)

Federated authentication uses industry standard protocols to communicate between the organization and the Force.com platform for authentication purposes. The organization configures the platform to trust "assertions" about users made using SAML (Security Assertion Markup Language). The Force.com platform is able to natively validate these assertions and create a session for the user when appropriate. Compared to delegated authentication, which requires the organization to host a service which makes proprietary SOAP API calls, SAML is an industry standard protocol that can securely communicate information between multiple Internet sites without proprietary coding.

To use federated authentication, your Enterprise must have a SAML Identity Provider (or IdP). This Identity Provider can use either version 1.1 or (as of the Summer 09 release) version 2.0 of SAML.

To configure federated authentication within the Force.com platform, enable "SAML Federation" by going to Setup | Security Controls | Single Sign-on Settings and filling out the configuration data.

Figure 8: Setting up SAML

SAML is gaining popularity as a preferred way for organizations to ease password fatigue for their users, while reducing the risks inherent when corporate resources are placed outside Enterprise network perimeters. Because SAML is a well-known standard, and because there are many tools and products available to enable SAML transactions in various Enterprise situations, the ability to meet regulatory commitments also make SAML very attractive.

While currently federated authentication works for direct access to the website, it is not yet possible to pass a SAML token from a desktop client or via the SOAP API. Even if federated authentication is enabled, username/password authentication must still be used to connect with a desktop client or remote application. More information on SAML can be found here.

Summary

The many ways in which users can be created, managed, signed in and disabled are critical to understand when developing for the Force.com platform, especially when writing code that communicates via the Force.com SOAP API. Even developers who are not writing code that directly manages or signs in users will be affected by the identity configuration decisions that administrators make. A basic understanding of identity management can only help developers to be more successful.

About the Authors

Patrick Harding is the CTO of Ping Identity, and a thought leader in federated identity management. Pamela Dingle is the CEO of Bonsai Identity, and an industry expert in the area of Enterprise Identity.