28 October 2013

A drag-and-drop tool for comparing profiles, permission sets, and users

Comparing profiles, permission sets, and users in an easy to use, intuitive, drag-and-drop user interface, is a difficult usability problem to solve. It's difficult because each user, permission set, and profile may have thousands if not millions of permissions associated with them. Therefore, when comparing users, profiles, and permission sets together, the number of questions you can ask are several orders of magnitude. Basically, instead of looking for a needle in a haystack, it's like comparing multiple haystacks looking for multiple needles of varying size, color, and material.

John Brock created such an app for a Dreamforce 2012 presentation. He set out to demonstrate what could be accomplished with the permission set and user API.  Built on Heroku and the Salesforce platform using OAuth2, ExtJS4, and Java with the Play! framework, the PermComparator, provides a simple drag-and-drop user interface that allows an administrator to drag and drop users, permission sets, and profiles into a series of columns to compare and contrast their individual settings.

With each user, permission set, or profile, the administrator can compare user, object, and setup entity access permissions through a series of collapsible, accordion style lists. Within each set of permissions, the administrator can compare common, unique, and differing permissions. The easiest way to understand how to use the PermComparator is through the concept of a Venn Diagram.

Assuming A, B, and C are any combination of users, profiles, and permission sets that an administrator would compare:

  • Common permissions (111) help answer the question, "How are these users, profiles, or permission sets the same as one another." This helps determine where there are redundant profiles or permission sets that could potentially be merged or deleted. This also helps when determining why one user has access that another doesn't. Since all comparisons share these permissions in common, these permission can be ruled out as creating the additional access.
  • Unique permissions (001, 100, 010) help answer the question, "What does this user, profile, or permission set have that none of other ones have." This can help troubleshoot why one user, profile, or permission set has access to something where none of the others do and is a likely candidate for determining what additional access has been granted.
  • Differing permissions are everything but what is common (100, 110, 010, 011, 001, 101 which is really everything in the diagram but 111). This matters most when you have more than two things you are comparing. Differing permissions answers the question, "What permissions are assigned and shared with some but not shared with everything being compared." This can help isolate potential differences which may result in discovering that a user should have a slightly different profile or permission set to get the job done. 

Recently, there was a lot of buzz in the Salesforce community about this tool. It was great to hear members of the community sing John Brock's praises for the PermComparator. He was called a 'crazy genius' whose tool was 'life changing'. One thing for sure, John solved a difficult problem and created an incredible visualization tool for understanding access controls in a complex system by making it drag-and-drop simple.

The PermComparator is open source and available on GitHub to be downloaded, forked, or contributed to should you need access to the actual source code.

21 October 2013

Visualizing Identity Fraud Using Login History

I love the cool data visualizations that I find on the web. I spend hours upon hours perusing great visualizations and infographics on sites like visual.ly, flowingdata.com, and Information is Beautiful. It's amazing how much I have learned about the US debt ceiling, the complete history of coffee, or ten things I never knew about Disneyland.

While these sites visualize great esoteric knowledge, I'm always amazed at the lack of great, easy to use data visualization tools within the enterprise to understand common problems like discovering when a user's credentials have been compromised.

In salesforce.com, administrators can use login history to help solve the problem of discovering identity fraud. Administrators can download the last six months of login data including who logged in, how they are did it, and from where. This is incredibly valuable data but is also a sea of information that only grows with the number of users and the adoption of the platform.

Yesterday, I came across a great new app that makes visualizing data sets like this incredibly easy.

The site is called Raw from Density Designs. It allows you to drop data into a free form text box and declaratively drag-and-drop from any number of easy to use vector graphics including treemaps, bubble charts, dendrograms, alluvial diagrams, circle packings, and scatterplots.

To try this, use workbench to first download your login history.
You should also download your users so that you can transform the user id in login history into user name which will make it easier to visualize your data.
To transform your user ids to user names, use the VLOOKUP function. You don't have to do this but it really will make your visualization easier to understand.

Once you have your complete login history data, copy and drop it into the Raw free form text box.
One of the great features of this app is that it automatically understands the data and gives you options. I kept it simple and decided I wanted to understand the relationship of users and how they logged into my organization so I used an alluvial diagram and compared the username, platform, sourceip, browser, and application attributes.
This gave me a great visualization of how these attributes relate to one another.

It also gave me the ability to export the resulting visualization to SVG, PNG, or JSON so I could use them. The first image in this blog post came from the PNG export.
With this visualization, I can now look for anomalies where a user may log in from an unknown IP, browser, application, or computing platform. These anomalies help me understand whether a user has had their account compromised and whether identity fraud has taken place within my organization.

Visualization of large data sets is all over the internet and there are great tools to help explore the data. Why shouldn't we be able to use them to solve our everyday enterprise sized problems?

07 October 2013

Visualizing User's Permissions Across Profiles and Permission Sets

Matt Lamb, a salesforce.com MVP at Appirio, responded to a question about whether it's worth just using profiles or if administrators should also use permission sets when assigning permissions to users. 

Matt tweeted, "The modularity [of permission sets] is awesome. In practice I've found they make auditing (e.g. "Who can Delete Accounts?") very difficult."

It's true that auditing can be difficult. I'd like to show you some simple steps that make the process much easier.

Permission sets were created to enable the layering of permissions. This allows administrators to meet use cases where profiles alone cannot go. Permission sets' modularity provides everything from the ability to layer a single permission to providing access to whole applications across different regions and lines of business.

Adopting permission sets introduces an auditing challenge. Now that permissions span a user's profile and all of their permission sets, it's challenging to determine why a user has access (e.g. "Who can delete accounts?").

I don't buy the argument that an administrator should rely solely on a profile because it's somehow more auditable than permission sets. I've even heard that 'CTRL-F' on a profile is a best practice when determining what a user has access to.

Some people may have seen me roll the Standard User profile out on over forty feet of paper in past Dreamforce sessions.

But what many admins may forget is that there's more than forty feet of permissions there. To view page layout assignments, record type settings, and field level security, you need to click into other pages. So even if you constrain yourself to only using profiles, they are still fundamentally not self-auditing.

Ultimately, what we all want is a visualization and reporting tool that allows us to audit what a user has been assigned. While we don't have a declarative reporting interface to display this information, we do have a robust API that allows a developer to build administrative tools to visualize and report on a user's permissions.

Last year, Doug Bitting created exactly that. His tool allows you to easily audit a user's permissions across both their profile and all of their permission sets in a highly visual manner.

As an example, Shawna Wolverton as a user in my org has one profile and many permission sets assigned to her.

When I click on the 'Display Perms' custom link on her user page, I can visualize the permissions assigned her.  I also start to get some sense of exactly how many permissions can be assigned a single user.

We can also report on the object and field permissions that the user has.

Finally, we can report on setup entity access permissions such as Apex Class and Apex Page access.

Doug made it very easy to download and configure my organization with this functionality.

I went to github (https://github.com/forcedotcom/user-access-visualization) and followed his directions in the Readme file. 

I first downloaded a ZIP of the repository. 

Then I used workbench to deploy a ZIP of the 'src' directory to my organization. (I could have used the force.com IDE to deploy the files as well; workbench is just my tool of choice.)

Last, I created a custom link on the user object. This link redirects an administrator to the visualforce page that will display the user's permissions. It knows who the user is because the page passes in the user id in the parameters of the URL (e.g. /apex/UserAccessDetails?uid={!User.Id}).

And there you have it. Using these methods, you can setup and audit a user's access across their profile and permission sets in around ten minutes.