Site-Level Security
Now, you have groups of users and
groups of rights. What can you do with
these groups to secure the SharePoint
portal? SharePoint 2003 offers two levels
of security: site level and list level.
When you create a SharePoint site,
you—as the creator or owner—have a
choice about how to handle security. The
options are to inherit the permissions of
the parent site or to use unique permissions. If you decide to inherit the parent's
permissions, the security options flow
down to the new portal site and everyone
who has any level of access in the parent
site has the same level of access in the
new site. If you select unique permissions,
you are initially the only user given any
access to the new portal site. After the
site's creation, you can add new users or
groups of users to the site and can grant
specific permissions.
Suppose your Contoso organization
has an IT department. The IT department wants to grant employees the ability to track trouble tickets through their
SharePoint issue-tracking list. To that end, the IT department has created an IT
portal site off the main Contoso site. In
this fictional organization, every member of the domain has at least read access at
the main company site. When you created
the IT portal site, you did so with inherited
permissions; any
domain user has
the ability to connect to the IT portal
site and see the
data on the home
page, including the
issue-tracking list on
the IT portal site's
home page. Now,
the IT department
needs to have a
location at which it
can save IT-specific
information, such as
server passwords.
The IT department doesn't want
users to see that
this documentation exists, so it has created a new portal site with unique permissions. This PrivateIT portal site might
have only members of the IT department
as users. When non-IT users attempt to
access the PrivateIT portal site, they'll see
an error message stating that they don't
have permission to access that resource.
Optionally, you can have the system
prompt them with a message stating that
they can ask the administrator to grant
them access to the restricted portal.
List-Level Security
List-level security works similarly, but at the individual list level as opposed to the
site level. Consider again the example of
the public IT portal site with its issue-tracking list. Suppose the IT department wants
to give any user the ability to read items
in the list, but the department wants to
give members of the Managers cross-site
group the ability to add new issues and
edit existing issues. In the list's permissions
options, you can add users or groups and assign them various permissions. You
simply enter the list, click Modify Settings
and Columns, and click the Change permissions for this list link. Figure 2 shows
the most granular list of rights available for
assignment. You might notice the tantalizing Modify item-level security link in the left
pane. This link offers you only the ability to
toggle users' views from seeing and editing all entries in the list to seeing only their
own entries in the list.
This item-level permission is a hint of what
is to come in SharePoint 2007, which represents a major evolution in terms of authentication and authorization over that which
SharePoint 2003 offers. Choices are more
diverse, more granular, and more intuitive.
SharePoint 2007 Authentication
In SharePoint 2007, you not only have
the same Windows-integrated options
as before—you also have the ASP.NET provider model. Use of the ASP.NET provider model removes the need for AD or
Windows accounts and gives you new
options, such as forms authentication
against any store of user data (e.g., a
SQL Server database). You also have the
option to use Web-based single sign-on
(SSO) options in which the user is logged
on via a non-SharePoint logon form. A
familiar example of a Web-based SSO
option is Windows Live ID (formerly known
as .NET Passport). This authentication
evolution gives developers and administrators much greater flexibility while installing
and configuring SharePoint 2007.
SharePoint 2007 Authorization
The SharePoint authentication changes
are important, but they're not nearly as
big as the forthcoming authorization
improvements. In SharePoint 2003, users and administrators are concerned
with rights, but in
SharePoint 2007,
the term is permissions, and the
division between
groups of users
and groups of
permissions is
much more clearly
defined. People are
assigned to logical
groups, such as IT
managers, junior
finance employees, and executive
team members. Permissions are
assigned to logical groups, such as designers and readers, and the permissions associated
with those groups are clearly defined. In
SharePoint 2003, distinction is blurred. At
the site level, you might assign a person
to the Readers role, but at the list level,
the Readers group acts more like a rights
specification. In SharePoint 2003, this
dynamic leads to confusion among administrators: Which group of users is allowed
to do what in each site and in each list?
Another major security improvement
in SharePoint 2007 is the addition of finer-grained permissions. Now, not only
can you secure a site or list, you can also
secure a folder and an item in that list.
Therefore, you can use the same library
to store sensitive documents and publicly
available documents. To prevent unauthorized access attempts, SharePoint 2007
offers a security-trimmed interface. If a
user doesn't have permission to view a
document or menu item, that document
or menu selection doesn't even appear
to that user. The entire Site Actions menu
won't appear if the user doesn't have the
required permissions to use any of the
menu's elements.
SharePoint Groups are logical groupings or collections of people. Out of the
box, the software offers three groups:
Owners, Members, and Visitors. These
groups function like SharePoint 2003's
cross-site groups in that you can assign them anywhere in a site collection and
they will be henceforth available for use
anywhere in that site collection. These
groups let you scale permission assignments across large numbers of people.
The original concept of SharePoint site groups is extremely flexible, making it difficult to effectively organize users and roles. You can assign users to a site
group, and you can assign rights to the
site group. Then, by assigning the site
groups of users to those groups that
contain rights, you effectively create a role
by defining which users can do specific
actions. The new version addresses this
ambiguity in the definition and purpose of groups. In SharePoint 2007, the role-based concept of collections of permissions is now clearly defined as a permission level, which functions as a role. You
assign permissions to these permission levels, and you assign these permission
levels to SharePoint groups.
Groups are also now always defined
at the site-collection level, enforcing a
consistent naming convention within all
the sites of a site collection. All of this
reduces the potential for confusion.
Register
