24 June 2013

Mass Assign Permission Sets and other cool things using the API


The Salesforce sObject API is an important part of permission sets, allowing you to perform tasks that you cannot perform through the permission set UIs.  Some administrators may already be comfortable with the salesforce.com sObject API, but for those who are not, it is possible to use the API without writing a bunch of source code by using the Workbench tool at http://workbench.developerforce.com/.  While Workbench has a great query builder interface, below are some example queries.


Users with a Permission like Modify All Data


Because a user’s effective permissions are determined by both their profile and all assigned permission sets, it actually requires two queries to determine which users have a particular permission.  The query asks the question what users are assigned to a profile or permission set that contains Modify All Data.

SELECT AssigneeId, Assignee.Name, PermissionSet.Label, PermissionSet.isOwnedByProfile
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true


Permission Sets Assigned to a User


SELECT PermissionSet.Id, PermissionSet.Name
FROM PermissionSetAssignment
WHERE Assignee.Username = 'admin@my.org' AND
PermissionSet.isOwnedByProfile = false


Permission Sets with a Particular Token


In a previous section, it was suggested that adding tokens to your permission set names or descriptions may be useful.  Here is a query that looks for a token within a permission set description:

SELECT Id, Name, Description
FROM PermissionSet
WHERE Description Like '%#salesrep#%'
Mass Assign Permission Sets to Users

Mass Assign Permission Sets to Users


It is possible to perform mass assignment of permission sets via the sObject API.  This is performed by inserting PermissionSetAssignment records (unassigning is nothing more than deleting the PermissionSetAssignment records).  To perform this operation with a spreadsheet and the Workbench, follow these instructions:

  1. Select “Insert” from the “Data” menu at the top of your browser window.
  2. Select PermissionSetAssignment from the ObjectType menu
  3. Select the “From File” radio button and choose your CSV-formatted spreadsheet.
  4. Click “Next”
  5. Map the columns from your spreadsheet as appropriate.
  6. Click “Map Fields”
  7. Choose whether you wish to process the request asynchronously
  8. Click “Confirm Insert”

17 June 2013

Phasing in Permission Sets



Permission sets represent a fundamental shift in enabling a user's access. As a result, you should have a release strategy before rolling out new permission sets to users in your org.

As with other important changes made to an org, you should first create permission sets within a Sandbox environment and test them with actual users.  This will enable you to effectively test a user's access prior to rolling it out to production but it will also give you an opportunity to discuss with other Admins the use cases which will make sense for your deployment. And because permission sets are supported in Change Sets, it's easy to move them from sandbox to production.

Instead of fixing existing profiles and their clones, consider preventing one-off profiles being created from this point forward as a good first step in phasing in permission sets.

If you do choose to remove permissions from your profiles and migrate them to your permission sets, consider doing the following:

  1. For any group of users, select/ask for 3-5 ‘volunteers’ to participate in a control group.  Make sure they have the time and willingness to give you feedback, and allot time for yourself to make corrections as they use the app.
  2. Do not delete existing profile.
  3. Create a baseline profile that represents all of the layout, field permissions, and other configurations necessary for this small group to get their job done. Keep in mind that this profile should be designed as a reusable set of baseline configurations (will be usable by more than this control group’s functional role).
  4. Create the additional permission sets consisting of user and object perms necessary for them to do their job.
  5. Add on other control groups to the profile, differentiating the users by the permissions in their specific permission sets.

As an example, you may have created a one-off profile in the past that represents all users who have read access to the app but a couple of additional permissions that make them different like the ability to single sign-on or use the API. Design a profile that removes these different permissions but establishes a baseline set of field permissions, layout assignments, etc that is a simple user.  For these users, add the permission sets that set them apart from this baseline profile including the necessary read permissions on objects. As other groups need to have some read access to the app, create different permission sets that represent that grouping but assign them the same profile that is shared by the original control group.

As with other org changes, implementing permission sets in phases using sandbox deployments and isolated use cases is the best practice for managing changes in a user's access rights.

07 June 2013

Why CIOs Shouldn't be Afraid of Shadow IT Organizations


I heard a little story the other day. Let me run it by you to see if you've ever come across this.

A small group of people with a big problem signed up for salesforce.com. They became proficient using and administering it. It was a huge productivity boost to one of their critical business process. Things were going so well that they flew too close to the sun. The CIO and the corporate IT organization discovered that there was a shadow IT organization within their walls.

One of the greatest fears of a CIO or VP of IT is when a shadow IT organization purchases, implements, and starts using a system that they have little knowledge or control of. Movement of mission critical apps to the cloud has made this more challenging for CIOs and is often discussed as the 'Consumerization of IT'.

Now the CIO and IT organization are playing catch-up; trying to gain oversight over the shadow IT group to ensure that they follow best practices and official security policies defined by the company. This is where terms like 'segregation of duties', 'least privilege', and 'escalated rights' get thrown around in the game of buzzword bingo. The scary part for the CIO and IT is that they not only need to get up to speed on salesforce.com, but they need to be smarter than the shadow IT organization that has a head start using it.

From my standpoint, this is where understanding how salesforce.com's access management is critical to the success of both groups. You neither want to limit the productivity of the shadow IT group too much, nor escalate their privileges within the corporate IT organization above what is appropriate.

From a process standpoint, there are really five critical steps get control of this situation:
  1. Identify user rights that may violate a security policy if mis-assigned or mis-used. This may vary by organization; however, I typically sum this up in four sensitive security permissions: Manage Users, Modify All Data, View All Data, and Customize Application.
  2. Determine which users have access to these permissions by checking their profiles and permission set assignments. These are the users you will need to monitor.
  3. Reduce your risk by segregating duties where applicable so that users have only what they need to perform a task and nothing more. There are a lot of different ways to do this in salesforce.com. I've blogged a couple different ways worth checking out such as: How Not to Give Out Modify All Data, Reduce Risk Through Re-Certification, and Maker-Checker. I'm also always amazed how few people I talk with know about the Delegated Administration feature.
  4. Create a governance policy that downloads and checks the Setup Audit Trail once per month. Look for patterns that may indicate a compromised security policy. For the most part, this pattern involves either changing the permissions in a profile/permission set or the assignment of any profiles/permission sets that have been identified as a potential security risk. Whenever a questionable activity is identified, flag the user and time in the audit trail.
  5. Finally, check the Login History to determine if the user performing questionable changes is actually a single user or multiple users sharing the same user account. This is easily done by viewing the history of logins for a user and correlating the Source IP, Browser, and Application fields. If there is a lot of variance, they have given their credentials out to other people. Once a user voluntarily gives out their user credentials, you lose the ability to audit their actions. Plus, it's actually a violation of the terms of service.
Most of the conversations I have with CIOs and VPs of IT start from a place of fear but in reality, there are a lot of proactive and reactive ways in which they can limit their risk. 

As Sun-Tzu once said, "If you know the enemy and know yourself, you need not fear the result of a hundred battles."

Report on who has administrative rights



Do you know who has a profile that may be a security risk?  Have you been audited and needed to quickly determine what profiles contribute to that risk?

The security team at salesforce.com created a great little app on the AppExchange that allows admins to determine potential security risks based on user's profiles.

The Security Health Check app can be found on the AppExchange. And the best part, it's free!!

Developed by the salesforce.com information security team, the Security Health Check application performs a quick review of your security-related settings and makes recommendations for improvement. The health check provides a numeric score and tracks your overall security posture over time.The Security Health Check also notes administrative users, reviews your profiles and users to report on all users that have sensitive access rights, and reviews your default and custom sharing rules.



This version is a managed package that will NOT count against your application, tab, and object limits. This version does not currently support Professional or Group editions, but check back for a future update.