SharePoint Permissions Architecture - Part 1

SharePoint is a bit of a beast when it comes to managing access to sites, lists, and libraries.  To plan out many of these involves discussions on every major layer of a company and their various needs.  The building blocks of a Permissions architecture are the following:
1. Users -> Users are defined using Active Directory (a server that is like a giant contact list for your company...it holds who you are, what dept you are in, your password, phone number, etc.).
2. Active Directory Groups -> In Active Directory, groups can be made so that you can work with people as chunks instead of individuals.  This is a great help when it comes to thousands of people being involved in your company...who wants to manage them all individually!?
3. SharePoint Groups -> Active Directory groups are more common as larger groups of people.  At a school, for instance, there might be groups for Faculty, Staff, and Students (amongst others).  There might even be groups broken out by department.  Often there is a need for more specific groups when it comes to sharepoint or even a mixture of multiple groups.  So, SharePoint will let us create our own groups of people (and you *can* include AD groups INSIDE or AS A PART OF a sharepoint group).
---
4. Types of Authentication - what does Authentication mean?  It means how your company verifies your username and password so that only you can access what you are supposed to (keeps other people out of your business ^_^).  There are several types between SharePoint 2007 and 2010 but these are usually set by your company's IT department and not something you generally have control over.  A couple of examples include:  Forms-Based Authentication (whenever you try to go into SharePoint or Webmail or some other Microsoft-based stuff, you get a webpage that asks for your username and password and then sends you to the webpage you were trying to go to) and Windows Authentication (pops up with a login box for you to type your username and password - and often a domain - and it logs you in and takes you to your page...though, you often have to log in again if you try to go to another system like Webmail, depending on how your company has set things up).  2010 introduces a new type of authentication called Claims-based authentication, look it up on google for a fun read, but is sort of a hybrid of multiple authentication types.
---
5. 3 layers of access in SharePoint - there are 3 primary places where permissions can be set:  the Site (giving access to an entire webpage), the list (you can set specific permissions on all the lists or some of the lists in a particular site), and the item (items INSIDE a list can have their own permissions set so that certain people can't see certain items...great for manager-only items in a public location but SHOULD BE AVOIDED if at all possible). 
6. SharePoint Permissions Inheritance - SharePoint's permissions are connected and automatically set (and updated) by the level above whatever you are looking at (see the levels in the previous point).  If you make a change at that uppermost level, all things underneath it reflect that same change and you are only allowed to edit the Site level.  This works great in an ideal world - and you might be able to get some leverage out of this on occasion, but there are too many reasons to customize permissions for a certain list or library.

So, that's it for now, the next post will explain how to arrange your building blocks into a decent permissions standard for the organization.  Mind you, there is no one-size-fits-all solution for permissions architecture but this one will get you started thinking along those big-picture lines of permissions.