Learn How Authorization Works in Force.com Apps
After completing this unit, you’ll be able to:
- Differentiate between the main ways you can protect access to data in your org.
- Understand when the platform automatically enforces authorization settings.
Access to online data is generally restricted to only those who are identified, authenticated, and authorized. In this module, we focus on authorization, which determines who is able to access which resources.
To understand this concept, think about the data in your own Salesforce org. For example, let’s assume you store information about your users. Some of this information is sensitive, like salary information or Social Security numbers. Authorization lets you specify that only HR or Payroll has access to those fields for everyone in the org, while regular users can see only their own data. That’s the power of authorization!
Configuring authorization and restricting access to data on the Salesforce platform is easy. By simply assigning a certain profile or permission set to a user, an admin can define what level of access the user has to the data stored in the org.
This is accomplished in three main ways:
- Create, read, update, and delete (CRUD) settings
- Determine which objects a user can create, read, update, and delete
- Field level security (FLS) settings
- Determine which fields a user can read and edit
- Sharing Rules
- Determine which records are visible to users
The easiest way to visualize these three concepts is to think about a spreadsheet.
- CRUD limits which tabs (or objects) a user can access.
- FLS limits which columns (or fields on an object) a user can access.
- Sharing limits which rows (or object records) a user can access.
To learn more about how these settings work and how to configure them as an admin, check out the Data Security module.
So admins configure authorization settings via the profile and permission sets in Setup. They take care of it all, right?
Wrong! As a developer, you too have a role to play in enforcing authorization controls. The admin sets the rules, but it’s your job to ensure that your application properly respects them.
In most cases the platform automatically enforces admin-configured authorization settings, so your job is easy. However, because the platform is flexible, there are certain cases where developers can bypass authorization settings.
To understand why and where this happens, you need to understand the two execution contexts that a Force.com app runs in: user and system.
User context is the default context that you see when you’re interacting with the basic UI in Salesforce. In user context, the current user’s permissions, field-level security, and sharing rules are taken into account as you browse the UI or execute code.
The platform runs in user context when:
- A user browses the application via the standard Salesforce-provided UI
- A user views a Visualforce page that uses a standard controller
- A user views a Visualforce page that references objects with standard object notation
- The platform executes Anonymous Apex via console or API calls
- An application on the platform makes a standard API call
This mode is ideal for developers because it enforces all admin configured authorization settings by default. However, user context can limit what data your custom code can interact with.
To support a wide range of features and richer UI experience, the platform can also execute in system context. In this mode, the platform does not take into account the current user's permissions, field-level security, and sharing rules during code execution.
Think of this as code executing with elevated privileges, running as root or as an admin. In this mode, applications have access to all objects and fields that are available in the org, including encrypted fields.
The platform executes code in system context in:
- Apex Classes (including web services)
- Apex Triggers
- Apex web services called from the API
From a security perspective, user context is preferable because user access controls are maintained throughout the transaction. This is why standard pages and Visualforce pages built on standard controllers run in user context. But the restrictions of user context aren’t always appropriate for custom business processes and applications.
Custom Apex and Visualforce applications often require permissions beyond the scope of user's access. System context provides the necessary flexibility for these applications. As a developer, you have to use this flexibility thoughtfully and carefully. With great power comes great responsibility!
To illustrate this concept, we use a sample app called Kingdom Management. In this module, you assume the role of the lead Apex developer for the app, which lets castle-dwelling users track their inventory. As this app processes potentially sensitive data about the kingdoms in the land, make sure that you’re properly enforcing authorization checks throughout, so no data is exposed to, or modified by, unauthorized users.
To get set up in the Kingdom Management developer org, you need to sign up.
- Go to the custom signup page for the Kingdom Management developer org: https://developer.salesforce.com/promotions/orgs/trust-de
- Fill out the form using an active email address and click Sign Me Up.
- Check your email for an activation request.
- Click the link in the email, and complete your registration by setting a new password and challenge question.
After you have your Kingdom Management developer username, you are ready to start learning how to defend your data from invaders.
Throughout this module and the other modules in this trail, we refer to the Kingdom Management application and the demos and challenges contained therein. Below are the various features for navigating the developer org.
- On the upper right side, the application picker contains apps that refer to various topics covered by the modules and units. Multiple units may refer to a single application as long as they share the same topic.
- The tab bar for each app contains tabs specific to demos and challenges. The content refers to each of these demos and challenges by name.
- Inside each tab, the Visualforce page has a Demo section that contains the contents of the issue being demonstrated.
- Inside each tab, the Visualforce page has a Code Links section that contains quick links to the pieces of code relevant to the demo or challenge. Clicking the link takes you to the Visualforce page, Apex controller, or other items associated with your demo or challenge.
We occasionally make updates to this org and the underlying apps. To see if you’re using the latest and greatest copy, check out the Overview tab in each of the custom apps.
If you see that your org is out of date, check out the release notes and sign up for a new version of the org.