Authorization
Authorizing access is a
case of granting permissions
to securable objects.
When doing so, you need
to consider the following
five components:
Individual permissions. These permissions
grant the ability to perform
specific actions. For
example, the View Items
permission gives the user
the ability to view items
in a list. The list of individual
permissions that
are available are farmvaliwide
but can be controlled at the Web application
level by a farm-level administrator.
Permission level. This component
groups individual permissions together for
easier management and assignment. WSS
has five default permission levels: Limited
Access, Read, Contribute, Design, and Full
Control. MOSS adds a few more such as
Approve and Manage Hierarchy. You can
add new permission levels or change the
default levels to suit your needs. Permission
levels are per-site and can either be inherited
from a parent site or explicitly set at a
subsite, library, or item level.
User. User is a security principal that
can be identified using one of the authentication
methods associated with the Web
application.
Group. A group identifies a set of users.
It can be a Windows security group, a role
that’s verified via a role provider, or a Share-
Point Group such as Site Owners, Site Members,
or Site Visitors. SharePoint Groups
are new to SharePoint 2007 and essentially
replace site groups. Groups provide a way for SharePoint site collection administrators
to group users without having to rely on IT to
create Windows security groups.
Securable object. Users or groups (either
Windows Security groups, Roles or Share-
Point Groups) are assigned a permission
level for a specific securable object: site,
list, library, folder, document, or item. By
default, permissions for a list, library, folder,
document, or item are inherited from the
parent site, parent list, or parent library.
However, anyone assigned a permission
level that includes the Manage Permissions
permission for a particular securable object
can change the permissions for that securable
object. SharePoint allows item-level
permissions, which means that a user could
be granted access to an individual document
in a document library and not be able to
access any other part of the SharePoint site.
Access permissions on individual items also
comes into play for the security-trimmed UI
that SharePoint 2007 employs. You can see
only items (including Web Parts) to which
you have read access, and you can’t see
options whose function requires
a permission that you don’t
have. For ease of maintenance,
always use a group to assign
permission levels to a securable
object. Granting individual user
access should be done only on
an exception basis.
Storing User
Details and
Establishing
Permissions So how does SharePoint store
information about users such
that it can subsequently validate their access to resources? First, users
can receive explicit access to objects via
their user accounts or implicit access by
being members of a security group or role.
Furthermore, you can add users, security
groups, or roles as individual entities or as
members of a SharePoint Group. The latter
is the preferred method as it eases overall
management.
When you grant a user, security group
or role any form of access to any resource
in a site collection—either individually or
via a SharePoint Group—an entry for that
security principal is created in the UserInfo
table in the content database that is associated
with the site collection. (Their details
are also put into the User Information List,
which is what you see when you view All
People through the browser interface.) Thus,
if a security principal has access to multiple
site collections, it will have multiple entries
in the UserInfo table. This table stores,
amongst other things, an internal identifier
for the security principal that’s used in many
other tables, an indication of whether the
principal is a security group or role, and the
security identifier of the principal from its
authentication provider. For the Windows
provider, this is the Security Identifier (SID)
of the user or group. For other providers,
it’s the unique identifier that that provider
has allocated to the principal. If a user has
been granted implicit access to a resource
via a security group or role, then an entry
in the UserInfo table is created for that user
account the first time the user successfully
accesses a resource in the site collection.
Four other tables come into play when
establishing the permissions that a user
ultimately has. First, the Groups and Group-
Membership tables. When a SharePoint
Group is defined, its details are stored in the
Groups table, and the GroupMembership
table has links to the individual users as
defined in the UserInfo table. Thus, when
you add security principals to a SharePoint
Group, the GroupMembership table for that
group is updated to include the internal
identifiers for each principal in the UserInfo
table. The other two tables are Roles and
RoleAssigment. These are the tables that
ultimately reveal the exact permissions that
a requesting user has, with entries relating
back to individual user records in the User-
Info table and SharePoint Group records in
the Groups table.
Permissions that are associated with
your individual user account, security
groups, and roles of which you are a member
and SharePoint Groups you belong
to are aggregated to form your final list of
permissions. Well very nearly; there’s also
something called Web Application Policies
that apply permissions to the Web application
as a whole, but detail for this is outside
the scope of this article. Just know that these
policies take precedence over permissions,
and you can use them to globally deny or
allow access to the Web application, then
the individual user permissions come into
play.
Concluding the
Authentication and
Authorization Process
So we now know how, through authentication
providers, we can prove the identity
of a requesting user and how we can store
information about and assign permissions
to known identities. So how does SharePoint
validate that a requesting user is allowed to
access a securable object?
When you access any resource in a site
you’re essentially requesting an item from
that site. For example, accessing the site’s
home page is actually making a request for
default.aspx, and editing an item in a list is
a request for EditForm.aspx. If you pass the
authentication process, then SharePoint is
passed the primary SID that identifies you
in the underlying authentication scheme
(e.g., your SID for the Windows scheme). This identifier is subsequently used to look
up your details in the UserInfo table every
time you request a resource. From there,
SharePoint can establish whether you have
the required permission to perform the task
at hand.
It’s important to note that SharePoint
checks only your primary SID, which is
important for the Windows security provider
to know in cases in which your primary
SID may have changed. This is typical
in any form of domain migration.
Although many domain/user migration
tools will retain the old SID in the user’s
security token, SharePoint doesn’t check
the sidHistory of the requesting user. Thus,
there’s no match in the UserInfo table for the
new SID, and the user loses access. You can
use the –migrateuser switch in the Stsadm
utility to replace the old user account with
the new user account, but you must take
this behavior into account in your rename
and migration processes to retain seamless
access going forward. You can learn more
about the Stsadm tool in “Stsadm: Taking
Control of SharePoint Administration”
November 2007, InstantDoc ID 97107.
Final Advice
SharePoint 2007 offers much flexibility in
terms of authentication and authorization,
which, when carefully planned, can result
in a very robust and functional environment
for sharing resources on many different
levels and differing environments.
Although you can use multiple authentication
schemes, do be aware that there are
some functional differences that can result.
You can read about these differences in the
article “Forms Authentication in SharePoint
Products and Technologies (Part 3): Forms
Authentication vs. Windows Authentication”
(msdn2.microsoft.com/en-us/library/
bb977430.aspx), and because of the way
access checks are performed, be aware of
the steps you need to take when migrating
user accounts, so that users maintain access
to their SharePoint content.