One challenge for companies implementing SharePoint is to figure out security. Keeping the model straight over time, as the SharePoint implementation matures, is even more of a challenge. SharePoint's ease of installation and high-level configuration can sometimes mask its underlying complexity, especially when dealing with more advanced scenarios like security.
To begin, IT managers need to understand two distinct security concepts – authentication and authorization. SharePoint is only involved in authorization -- granting users access to functions and content. Conversely, authentication -- which is the act of validating that users are who they say they are -- is the responsibility of a membership provider.
Microsoft gives you different membership providers out of the box depending on the version of SharePoint you have – either Windows SharePoint Services (WSS) or Microsoft Office SharePoint Server (MOSS) 2007. WSS supports only Active Directory and Windows local accounts, while MOSS includes support for LDAP directories. Both versions of SharePoint can use the SQL membership provider from the .NET framework. This article will focus only on authorization.
SharePoint groups and site collections
What's often confusing about Microsoft's information portal is how SharePoint groups work. The groups are a collection of users and groups from the membership provider -- Active Directory is the most common. It's important to remember that SharePoint groups cannot contain other SharePoint groups. When planning your implementation, that should be a consideration.
When you install SharePoint and create your first site collection, three primary SharePoint groups are created automatically. They are: Owners, Members and Visitors. Each group will be named for the root web in the site collection -- for example, Intranet Members.
These three groups can either be inherited by sub sites or new ones can be created. New
To continue reading for free, register below or login
To read more you must become a member of SearchWinIT.com
groups that are created as part of a site provision process are named for that site by default. You also have the option to change that name when the group is created.
Groups that you create manually can be named anything you like. In either case, the groups actually reside at the site collection level, which means that no matter what site you're on, you'll see all of the SharePoint groups within the site collection. The advantage is that you can grant any one of those groups access to any asset. The downside is that if you have a lot of groups, it can be overwhelming.
Controlling SharePoint security
Granting permissions to various SharePoint constructs is done within the People and Groups section of the Site Settings menu or within the list/library settings. Figure 1 shows the People and Groups menu option within the Site Settings section of a WSS site. MOSS has a nearly identical interface.
Figure 1
[IMAGE]
Figure 1 – Under Site Settings you'll see the People and Groups menu.
To change permissions on the site, click on People and Groups. You'll be presented with a list of users within a given group. Typically, you'll see the Members group, as shown in Figure 2. On the left, it shows the other basic groups in the site collection. To add a user to this group, click New on the menu and, when prompted, enter the name of the user.
Figure 2
[IMAGE]
Figure 2 – The People and Groups interface is where you add new users.
If you want to break inheritance, click on Site Permissions. Then, click on the Actions menu and then Edit Permissions, as shown in Figure 3. This will copy all users and groups from the parent to the child. However, any further changes to the permissions on this site will not affect the parent. Keep in mind that because the SharePoint groups are stored at the site collection level, when you make changes to existing groups -- such as adding and removing members -- it affects all sites using those groups, whether or not the sites inherit permissions.
Figure 3
[IMAGE]
Figure 3 – Under Site Permissions, you'll see an Actions menu and Edit Permissions menu.
SharePoint Security best practices
Unless you want end users to manage security, try to add only Active Directory or other membership provider groups to SharePoint groups. That will enable centralized administration of permissions through AD. Some other best practices for SharePoint security include the following:
Shawn Shell is the founder of Consejo Inc., a consultancy based in Chicago that specializes in Web-based applications, employees and partner portals, as well as enterprise content management. He has spent more than 19 years in IT, with the last 10 focused on content technologies. Shell is a co-author of Microsoft Content Management Server 2002: A Complete Guide, published by Addison-Wesley, and the lead analyst/author on the CMS Watch SharePoint Report 2008.
