Friday, December 14, 2012

Permissioning Is Your Only Real Job

Permissioning is keeping things private while waving them about in public. Once you've branded your Sharepizzle installation and gotten the hang of hitting the "create subsite" and "activate site feature that really should already be active" buttons, your entire world will compress to permissioning. It is best to get it right from the start.

Permissioning is really, really handy in Sharepoint. I will go so far as to say it is one of perhaps two things they have mainly gotten right. It applies to everything in a sharepoint install, at every level, and you can control it for real. You can always tell what parts of the enterprise software are actually valuable and which are colossal wastes of time and funding by what's fixed from install to install. Permissions have been tightly controlled from the start, yet managed to improve in 2010. Surprise. I am actually surprised.

Your ability to control permissions, and break them horribly to do things they were never intended to support, is one of your great powers. If you were a good IT Person,* you might plan for their inheritance and carefully sort through the benefits and disadvantages of a coherent permission approach.

*You aren't a good IT person. If life were a Choose Your Own Adventure novel, you would be one bad move away from being eaten by Ant People. The bad move was choosing this book to begin with.

Permissions have a bunch of levels. Here's some key theory:
  • You can use permissions to hide things, both in inline code/layouts and with the various Audience Settings.
    • This includes the hateful Ribbon metaphor.
  • Initial Sharepoint access and accounts are set, usually, through your institution's Active Directory.
    • As addressed previously, this makes individual user accounts mostly not your issue.
  • Sharepoint groups by default tend to have one of three permission levels, Full Ownership, Contribute, or Read. These are mostly what you need. People can Contribute, or Read.
  • Individuals can have individual permissions set per site or list
  • Groups hold individual accounts and are strongly preferred for setting permissions.
  • Groups cannot contain other groups, ever, for any reason.
Group Permissioning Is Preferred. But Why?

Ideally, all permissions for all subsites and lists on your Sharepoint site are inherited. That is to say, you set them at the top, and like Republican wealth, they trickle down. In reality, as in reality, they do no such thing: you will be breaking permission inheritance for people from Day One, because people do not actually want to share on these sites, but that is the theory.

When you set individual account permissions, they get written to somewhere other than the Active Directory. The account lives on regardless of whether the individual still works in the building, and sometimes regardless of whether their AD account still exists in the system.

Ghosts in the machine will therefore lard your site like fat in bacon. You will not be able to get them out without an overview of every employee in the company. It is therefore best to keep them inside of groups, where the general group has the permissions, rather than trying to keep tabs on who's been hired or fired this week.

Why Can't Groups Contain Other Groups?

This prevents permissioning recusion and inheritance attacks, in theory, where a group set to full control in one place is nested in a Contribute somewhere else. That was a guess. I have no idea, because sometimes groups which explicitly have one level of permission (Full Control) still don't have Full Control over sites or objects they nominally Control The Fullness Thereof.

This sort of weird inheritance problem happens a lot with this software. It is normal. It makes the line of the Bourbon Kings look clean and straightforward.
The Bourbon Kings have nothing to do with alcohol per se, and don't we wish we could say that about you once you're done sorting this garbage out.

How many levels of permission can I set?

You can set specific permission levels on anything in Sharepoint. Each subsite, each list, each folder and item can have independent permissions set. This is valuable because those permissions are largely effective. You set them explicitly and name the accounts with permission, and those accounts can see pretty much exactly that thing you shared with them, and nothing else.

Problematic in that sometimes this means they can't see the inheritance breadcrumb or suckerfish menu to get to that site, useful because they are going to just check their Outlook for the link every time anyway.

No comments:

Post a Comment