January 29, 2014
This is the final installment in a four-part series covering (almost) everything you need to know about salesforce.com security. In 101, we discussed all security components in Salesforce that govern data security, with definitions and common use cases. Followed by 102, which covered application security. In this installment, we'll take a deeper dive into application security, addressing advanced use cases of app security components, as well as examining some new components from the Spring '14 release, such as Salesforce Identity. There may be some repetition in definitions and such, but I want to make sure enough context is given when needed.
I’ve attempted to highlight the most common issues and pitfalls, however, there may be additional issues you face, and other considerations to keep in mind when designing your security model. Please use this set of blog posts as one of your many building blocks of Force.com knowledge and extertise. This series is not meant to be a sole replacement for salesforce.com’s documentation and advanced whitepapers, but rather an important supplement, touching on all aspects of the Force.com security model. Safe Harbor statements aside, let’s dig in!
The Force.com and salesforce.com security model is a combination two major components:
- Force.com data security
- Force.com application security
- Discussed in 102 and this post—application security consists of the components, profiles, and permissions that govern which functionality and/or areas of the application users have access to, both internal and external. E.g., your Partner Community users can only access certain objects, and cannot edit/create reports.
Force.com Application Security Components
This section defines the components, profiles, and permissions that govern user access to various system components and application functionality, e.g. the ability to export data or manage campaigns.
In general, routine audits of all security components are recommended to ensure that your current security structure continues to satisfy your evolving business model and goals. This can require some arduous work unwinding years of band-aids and quick-fixes. Layering together numerous quick-fixes can result in an unorganized and unstable data structure. At the time, one-off patches may seem appropriate, but enough of these exceptions will start to add up and you will have a haphazard conglomeration of code, patches, and other settings. These can often be consolidated more efficiently if a little ‘remodeling’ is conducted during spring-cleaning.
Force.com Security Profiles
Force.com Security Profiles - Definition
As a major component of Salesforce’s security model, Force.com security profiles extend object permissions, tabs, field level security (FLS), APEX/Visualforce access, and app or system permissions to different users. Object permissions dictate which objects users have access to within a given profile, and the respective access within each object such as create, read, edit, delete (CRED), view all, and modify all. Salesforce comes with standard profiles as well as the ability to create custom profiles. Standard profiles cannot be customized, which is often why custom profiles are utilized, providing greater control over the various elements of the application users can access. Standard profiles are often used as a starting point, with many choosing to clone standard profiles into new custom profiles, which are further modified.
Force.com Security Profiles - Architectural Considerations
One point I’d like to reiterate from the use-cases in 102 is that it’s very important to limit the number of profiles in your org as much as possible. I’ve seen some pretty disorganized security models, with many redundant, unneeded profiles. It’s an arduous task to manage each profile since there are so many different points of configuration, so try to find the biggest groups of users possible for each profile.
You might even consider including a ‘shell’ profile, that grants minimal, or almost no access. Then, if you need to add one-off users that need very specific access—say, a Marketing partner that is sending new opportunities via API or ETL, such as (my favorite) Informatica Cloud—you may only need to ‘create’ Access to Opportunity, with no access to any other objects or tabs. This ensures the user account is only used for the purposes initially intended and is not exposing any data to outside parties. This opportunity permission can be granted by assigning the ‘shell’ profile with ZERO access to anything, and also adding a permission set that includes ‘Create’ on Opportunities only.
Shown: Data Model/ERD for Profiles and Permission Set Objects
Force.com Permission Set
Force.com Permission Set - Definition
Permission sets allow administrators to fine-tune user access to a collection of settings. Permission sets are designed to be used in conjunction with profiles. A user’s profile will establish the minimum amount of permissions they have within the system, while permission sets will open up additional functionality when combined with the profile. All access settings available in a permission set are also available in profiles. Permission sets can be assigned at the individual user level. Permission sets should be leveraged to avoid profiles getting out of hand.
Force.com Permission Set - Architectural Considerations
As mentioned in profile considerations, permission sets can be used to have tight granular control over which users can access what content. Depending on this size of your org, the way you use permission sets could simplify or complicate your life. If it starts looking like a mess, you’ll want to perform regular audits to avoid redundancies. It is possible that your permission sets are too granular if the same users have many different permission sets. On the other hand, it’s also possible that they are too broad if few permission sets each contain many permissions, opening up unneeded/unintended access to certain users. Of course, this all depends on what your business needs are. In any situation, routine ‘health checks’ and ‘sanity checks,’ can be extremely beneficial.
One quirk to permission sets is that users are added one-by-one via the user record. This can be a painstaking process if several users need to be added. In this case, you might consider using a profile for the users, or managing the permission set assignments via an APEX Data Loader.
Force.com Custom Settings
Force.com Custom Settings - Definition
Much like custom objects, custom settings allow administrators to create and associate custom sets of data for an organization, profile, or specific user. Custom setting data can be used in formula fields, validation rules, Apex, and the API without an additional cost of repeated queries to the database. Custom settings should be leveraged to eliminate the need to hardcode sets of data into custom code, establishing a very agile environment.
Force.com Custom Settings - Architectural Considerations
Custom settings can really make the difference between a scalable, easy to maintain deployment, and a very frustrating deployment. If the extra effort is put forth to organize custom code, allowing configuration in as many places as possible, your custom development can grow with your evolving business. Let’s say you have a custom search function that checks for duplicate accounts when logging new cases or leads. You may need it to behave differently depending on which user role is logging the case. You could have the code reference a custom setting table that ‘maps’ access levels/behavior to specific roles. Sure, you could hard-code the roles into the APEX class to suit today’s needs, but what happens 6-12 months down the road when you deploy a Community or implement new business processes for additional departments? You would have to track down the original developer and pay to have it changed to accommodate your new business needs, or hire a new developer and pay extra while they figure out “what the H” the original developer was thinking. Or, how about simply adding the new roles to the custom setting table, at the appropriate access level? This can go from a 5-10 minute task that your internal admin can handle, into a costly little development effort.
Salesforce.com Account and Opportunity Teams
Account and Opportunity Teams - Definition
An account/opportunity team is a team of users that work together on an account/opportunity. For example, your account team may include an executive sponsor, dedicated support representative, and project manager.
You can build an account team on each account that you own. When selecting an account team member, choose a role to indicate the role the person plays on the account. Also, depending on your sharing model, you can specify the level of access each account team member will have to the account and any contacts, opportunities, or cases associated with that account. So, you can give some team members read-only access and others read/write access.
Account and Opportunity Teams - Architectural Considerations
I don’t have too much to add from the beginner’s version, but I wanted to share the ERD/Data Model so you can get a visual of all the objects/tables involved with sharing and Account/Opportunity Team Sharing.
Force.com License Types
Force.com Feature Licences - definition
There are many license types on the Force.com platform, used for different purposes. These include the standard salesforce.com Sales Cloud license, Service Cloud, Chatter Only, Chatter Plus, Community/Partner Portal, among others (which we discussed in detail in 102).
Salesforce.com and Force.com also have several feature licenses, which entitle users to additional features such as Marketing or Call Center.
Force.com Feature Licenses - Architectural Considerations
As Feature licenses open up essential functionality, it is imperative you evaluate which functionality will be needed. I won’t go into cost, as this can vary greatly depending on your contract, but salesforce.com is typically pretty good about working with you to make sure you’ll have the functionality you need to be successful. Many desired features may already be included in your contract, but you can always try to negotiate any of these to help sweeten the pot for your CFO. Below is a breakdown of the feature licenses available, with additional commentary when necessary.
- Chatter Answers User
Primary functionality: Access Chatter Answers. This feature license is automatically assigned to high-volume portal users who self-register for Chatter Answers. You may also need to take a look at adding this to any internal or partner users if you expect them to contribute to your community.
- Force.com Flow User
Primary functionality: Run flows. Any user that will be using the flows you have created, regardless of where you deploy will need this feature license. The admin creating flows will need one as well.
- Knowledge User
Primary functionality: Access Salesforce Knowledge. Like Flow User, all users such as admin, authors, reviewers, publishers, and others on your team will need this feature enabled on their user record.
- Live Agent User
Primary functionality: Access to Live Agent. Applies to applicable Service Cloud editions, so any support personnel will need to have both.
- Marketing User
Primary functionality: Create, edit, and delete campaigns. Configure advanced campaign setup, import leads, and update campaign history via the member import wizards. Also ensure these users have the appropriate system and object permissions in their profile. It’s very common to have a profile specifically for Marketing Users.
- Mobile User
Primary functionality: Access Salesforce Classic. The Mobile User checkbox doesn't apply to the free version of Salesforce Classic because users of the free app can access Salesforce from their device without a mobile license. Salesforce1 is included with all licenses!
- Offline User
Primary functionality: Access Connect Offline. You’ll also need to ensure you’ve configured offline access appropriately.
- Salesforce CRM
Content User Primary functionality: Access Salesforce CRM Content. Again, this applies to all users, whether internal or external, that need access to content functionality, except when sharing specific libraries/content publicly.
- Service Cloud User
Primary functionality: Access the Salesforce Console for Service. Note: Access to the Salesforce Console for Sales requires the Sales Console User permission set license.
- Site.com Contributor User
Primary functionality: Edit site content on Site.com Studio.
- Site.com Publisher User
Primary functionality: Create and style websites, control the layout and functionality of pages and page elements, and add and edit content on Site.com Studio. Typically for your Site.com developers, but can also be used for users contributing content such as news or blogs.
- Work.com User
Primary functionality: Access to Work.com objects and permissions. Applies to users with licenses for Sales Cloud, Service Cloud, Platform, or Chatter Plus.
It’s also very important to understand the limits of the platform/license type. A full breakdown of Salesforce.com limits can be found here.
Salesforce.com Field Level Security
Salesforce.com field level security - definition
Field-level security (FLS) settings let administrators restrict users’ access to view and edit specific fields in:
- Detail and edit pages
- Related lists
- List views
- Connect Offline
- Email and mail merge templates
- Custom links
- Synchronized data
- Imported data
The fields that users see on detail and edit pages are a combination of page layouts and FLS settings. The most restrictive field access settings of the two always apply. For example, if a field is required in the page layout and read-only in the FLS settings, the field-level security overrides the page layout and the field will be read-only for the user.
Salesforce.com field level security - architect considerations
Even though users may not need access to certain fields on page layouts or list views, there may be times when they need to merge these fields into email templates or pdf templates. For example, when using a powerful mail merge application such as Conga Composer, users will need Read-access to any and all fields in the merge template, such as proposals, invoices, etc. In this case, you can still grant read only access to the fields included in a merge document, without adding them to any page layouts, lists or reports.
Also, any API/ETL users will need access to the fields they are writing to, so ensure these users have profiles or permission sets that grant field level security to the appropriate fields.
Salesforce Identity - Definition
I’m not sure that I could top the definition straight from DeveloperForce: As the number of cloud-based providers and applications continue to grow, users are faced with an ever-growing array of login options and credentials. This trend poses a problem for not only users, but administrators and developers looking to leverage a full ecosystem of applications and features within the cloud.
Salesforce Identity provides Identity and Access Management (IAM) for Web and mobile applications through the simplicity, transparency, and trust of the Salesforce Platform. Salesforce Identity helps to improve the usability and adoption of applications through single sign-on for end users, simplify administration through centralization and automation of user identity and access rights, and provide peace of mind for the CIO through visibility and control over their cloud investments.
Salesforce Identity - Use
So what does this mean for current Salesforce users? Well, if you already have Enterprise or Unlimited/Performance Editions, it’s already included.
One of the main goals of Salesforce Identity was to make authentication, Single Sign-On (SSO) and directory services available to companies, whether or not they’re already using Salesforce. Since there’s so many different uses and considerations, certainly enough information to fill an article series of its own, I’ll just highlight some of the major features and point out what it means for companies using Salesforce vs companies not using Salesforce:
- Single Sign-On & Social Desktop
Users sign in once into Salesforce Identity and gain one click access to applications. With an Identity-enabled Chatter feed, users can access deeply integrated applications and push important information back to the user. Existing Salesforce companies can simply use their existing user records and their main user directory. Enabling SSO to other services and applications, your Salesforce users can use their Salesforce credentials to log into other services, such as a custom iOS app.
- Identity & Access Management
Administrators centrally manage access to applications designed for desktop, smartphones or tablets. Management of users across applications and clouds is automated through highly flexible provisioning workflows. The main advantage to administrators would be only having to maintain one user account for each employee, and auto-provisioning users across all enterprise applications. This is available to existing Salesforce users, and additional users for the low $5 fee.
- Enterprise Directory Integration
For organizations with existing enterprise systems like Active Directory, administrators can utilize automated synchronization of users and Single Sign-On. A lot of companies still use Active Directory as their centralized user management and SSO directory. Without changing the directory, administrators can use Salesforce Identity to add SSO to their Active Directory Users and any/all of their applications.
- Cloud Directory Services
Salesforce Identity supports standards-based access to user attributes and entitlements through a SCIM (System for Cross Domain Identity-Management )-based cloud directory. This can effectively replace systems like Active Directory, and the price ends up being pretty attractive.
Administrators have the ability to immediately shut off access to applications and services through automated de-provisioning. Imagine being able to shut off a user’s access to all their accounts with one or two clicks? No more scrambling and long employee termination checklists. Not to say you eliminate checklists, you should still enforce a repeatable protocol, but there can be much less steps involved.
- Centralized Reporting
Organizations gain transparency, insight, and peace of mind with centralized reports over user authentication, access, utilization, and de-provisioning. However the features of Salesforce Identity are being used, all activity is accessible through the same reporting tools available on the Force.com platform. This can help pinpoint gaps in adoption, abuse or breaches.
Salesforce.com Security Controls - Definition
I wanted to wrap up this series by touching on the Security Controls section, which is located in the setup menu:
It contains several different aspects of security, largely pertaining to global application settings, with the exception of Sharing Settings (OWD & Sharing Rules) and Field Accessibility (Field Level Security). Other settings include Network Access (allowed IP addresses), Session Settings and Authorization Partners. It also includes some admin tools relating to security such as the Setup Audit Trail (detailed log of all configuration done, by who with timestamp) and Portal Health Check.
While the default settings may be adequate for your organization, it should not be overlooked as there may be options that help your business, whether it’s providing additional layers of security, or enhancing user experience.
Salesforce.com Security Controls - Use
I’ll attempt to touch on each page within the Security Controls Section and highlight the most common aspects one might consider that have not yet been covered in this guide.
- Sharing Settings
This is where OWD and Sharing Settings are controlled
- Field Accessibility
One of a few places Field Level Security can be controlled
- Password Policies
All password policies for the org are configured here. Common config points may be setting expiration frequency, preventing past passwords from being used, enforcing a minimum length and complexity, max invalid login attempts and lockout period. Admin can also assign a custom forgot password/locked account assistance message.
- Session Settings
This is where all settings governing login sessions are configured. You may set a timeout duration, force HTTPS, enable SMS identity confirmation, disable login page caching, GET/POST protection, session security levels and clickjack protection. The default values are typically satisfactory, but if you have a short session duration, you may want to limit the popup warning message as users may have several popups to close when they get in every morning (I really hate that!)
- Network Access
This section allows you to define IP address ranges that you trust, preventing two-stage authentication from happening, even if using a new PC. You might consider doing this for your office network, but not for your wireless/guest networks if you have 3rd party visitors accessing the network.
The Activations screen is a new Admin tool that allows you to track all of the IPs users have logged in from. It also records a timestamp when a ‘challenge’ was sent, prompting users to email a validation code or answer a secret question.
- Login Access Policies
Users can grant access to 3rd party apps for support, if Admin has made them available to users in Login Access Policies. This also includes Salesforce.com Support. You might consider disabling these if your internal staff regularly supports users for all issues.
- Certificate and Key Management
This page displays all certificates used for authentication with Single Sign-On or Salesforce as an identity provider. CA-signed certs are created here, but need to be signed by a certificate authority before use.
- Single Sign-On Settings
Used to enable SAML* Single Sign-On (SSO) and create a new SAML SSO Setting. This will leverage a certificate from above along with an identity/auth provider (below). SSO Enables you to to allow users to log into Salesforce with credentials from another application.
- *SAML stands for Security Assertion Markup Language, and provides a secure, XML-based solution for exchanging user security information between an identity provider (your company) and a service provider (Force.com). SAML 2 is a major revision from the SAML 1.1 standard and now supports, among other things, W3C XML encryption and service provider initiated web single sign-on exchanges. This allows service providers like Force.com to query the identity provider for authentication.
- Auth. Providers
Enable users to log into your Salesforce organization using their login credentials from an external service provider such as Facebook© or Janrain©. Along with defining the authentication provider in this screen, you would also need an APEX registration handler and ensure the service provider is configured properly.
- Identity Provider
Enabling Salesforce as an Identity Provider has many benefits as Salesforce becomes the main application they log into every day, providing the ability to access all other applications and services from one place. A domain must be configured in order to enable Salesforce as an Identity provider. You can enable users to access other services (ERP/Email) directly from Salesforce automatically, through a button/link in Salesforce or a Tab.
- View Setup Audit Trail
The main screen displays the last 50 config changes in the org, including user admin. You can also download a csv of the last six months. This is very helpful when multiple admins or users are making configurations changes. If something goes wrong, it’s possible to track down the source of the problem.
- Expire All Passwords
Pretty straightforward: Expire all passwords with one click so users are prompted to create a new one the next time they login. This is especially helpful in crisis situations where there may have been a security breach. Better safe than sorry.
- Delegated Administration
Delegated Administration allows multiple administrators in the org to be responsible for various aspects. For example, user management may be delegated to Sales and/or Support Managers, so the primary Administrator can focus on more complicated tasks.
- Remote Site Settings
Web Addresses that can be invoked from Salesforce. This may include URLs for apps from the app exchange such as Adobe Echosign or to launch custom links to external sources such as Google News or Twitter Search.
- HTML Documents and Attachments Settings
Enables Admin to disallow HTML documents and attachments. I’ve never considered doing this, but I suppose there’s a possibility an HTML attachment on an email being uploaded or synced to Salesforce could contain some nasty stuff that ruins your day. This may be necessary if your company is not using solid email security software.
- Portal Health Check
Summaries of portal user access to various functionality and data. Reports include: Administrative and User Permissions, Object Access and Field-Level Security, Sharing Organization-Wide Defaults and Sharing Rules. These come in really handy when doing all those routine audits, health checks and sanity checks I keep talking about.
Speaking of ‘sanity checks,’ maybe I need one after completing this series. I tried to be as thorough as possible, however, I know there are so many more use cases, exceptions and scenarios that may come up. One of the recurring themes you may have noticed is that businesses scale and evolve—what might be right for you today doesn’t mean it will work for tomorrow. This is why with almost every component, you should be looking for ways to streamline the maintenance and modularize your environment as much as possible, so simple modifications don’t turn into major projects. If you can work some routine 'spring cleaning' I can almost guarantee it will save you time down the road, even if it does add to your task list now.
Think you’ve got some security chops now? Perhaps you should dig a little deeper into some of these advanced secuirty topics.
To stay secure you have to stay up to date. Download the latest report on how the best IT teams are using Salesforce here.