Authentication

  • Article

Security Notes for SharePoint Portal Server Developers

Authentication

Authentication is the process of verifying the identity of a person or process. Microsoft SharePoint Products and Technologies do not perform authentication; Internet Information Services (IIS) handles authentication. IIS security is integrated with the Microsoft Windows Server Active Directory, and every user who accesses a resource must have a valid Windows user account. You can perform authentication against a credential store other than the Active Directory, but it is not recommended or supported.

Local Administrators and SharePoint Portal Server Administrators

SharePoint Products and Technologies support two sets of high-level administrators: local administrators and SharePoint administrators group members. You can specify the SharePoint administrators group by using the Set SharePoint administrative group account link in Security Configuration on the SharePoint Portal Server Central Administration for server_name page. For information about the SharePoint administrators group, see Managing the SharePoint Administrators Group.

When a person or process requests a page or a resource, SharePoint Products and Technologies check to see if the current user is a local administrator or is in the SharePoint administrators group. Upon verification, full access is granted to all portal sites and site collections.

Local Administrator Abilities vs. SharePoint Administrator Abilities

Users who are members of the SharePoint administrators group but are not members of the local Administrators group can perform maintenance-level tasks only. For example, such users cannot create or delete a portal site, or create or disconnect a configuration database. Only local administrators can perform the following tasks:

  • Change the configuration database
  • Change the SharePoint Administrators domain group
  • Enable full-text search
  • Manage content paths
  • Extend/unextend IIS virtual servers

To enable a user to be a server farm administrator for Microsoft Office SharePoint Portal Server, you must add that user to the local administrators group on each server in the server farm.

Also, you can only register one domain group as the SharePoint administrators group. If you want to include other members, you must add them to the group using the user and group management tools for your domain. If you want to change which group is registered, you can follow the steps to specify a group, and then specify a different domain group. When you specify a new group, the old group's rights are removed, and the members of that group can no longer manage the servers running SharePoint portal Server.

Permissions in SharePoint Products and Technologies

SharePoint Products and Technologies use rights to control access to resources. A right is a privilege that allows a user to perform an action on the server. Examples include View Pages, Insert List Items, and Change List Permissions. There are currently about 20 rights. Some rights are dependent on others. For example, Insert List Items has View List Items as a dependent.

At the IIS virtual server level, you can define a rights mask. This enables or disables rights for use on the portal site and site collections within that virtual server. Local computer administrators and SharePoint administrators can set the rights mask.

Authorization

SharePoint Products and Technologies perform authorization. SharePoint-specific access control lists (ACLs) dictate access, and implementation is similar to the Microsoft Windows system. Windows is called for domain group resolution.

Even though SharePoint Portal Server inherits the security model from Microsoft Windows SharePoint Services, it implements its own security provider for authorization. Underlying Windows SharePoint Services sites call the SharePoint Portal Server security provider for ACLs. Callout is registered in ONET.XML and all ACLs are stored in the Area system.

Note  ACL is a collection of ACEs (Access Control Entries), each of which maps a security principle (user, group, and so on) to a set of rights.

Groups and SharePoint Products and Technologies

SharePoint Products and Technologies support three types of groups with the following characteristics:

  • Windows domain groups
    • Can be nested inside each other
    • SharePoint Products and Technologies call Windows for user resolution
    • Can be a member of both of the following types of groups
  • Cross-site groups
    • Scoped to the site collection
    • Cannot be nested within each other
    • Can be a member of site groups, but not Windows domain groups
  • Site groups
    • Scoped to an individual Web site
    • Cannot be nested within each other

Default Site Groups

The following site groups are installed in SharePoint Portal Server by default. However, you can also create custom site groups.

  • Guest.  Has limited rights to view pages and specific page elements. Use this site group to give users access to a particular page or list without granting them rights to view the entire site. You cannot add users explicitly to the Guest site group; users who are given access to lists or document libraries by way of per-list permissions are automatically added to the Guest site group. You cannot customize or delete the Guest site group.
  • Reader.  Allows users to search, view, and browse content in the site.
  • Member.  Allows users to submit listings and create personal sites.
  • Contributor.  Allows users to submit content to areas in the site to which they are granted rights.
  • Web Designer.  Allows users to change layout and settings on a Web page to which they are granted rights.
  • Administrator.  Allows users full control of the Web site.
  • Content Manager.  Allows users to manage all settings and content in an area to which they are granted rights.

Customizing Site Groups

You can create a new site group or customize an existing site group (except for the Guest and Administrator site groups, which cannot be customized) to include only the rights you want. For example, if you want only the Web designers to be able to edit lists on the site, you can remove the Edit Items right from the Contributor site group.

As mentioned earlier, some rights depend on other rights. You must be able to view items before you can edit items. In the same way, if you add a right that requires another right, the required right is also added. So, if you grant the Edit Items right to a user, the View Items right is granted automatically.

Note  For more information about dependencies in user rights, see User Rights and Site Groups.

The SharePoint Portal Server object model provides full support for creating custom site groups. For more information, see the examples in the Code Snippets section of the Microsoft SharePoint Products and Technologies 2003 SDK.

Granting Access to the Portal Site

After you have created a portal site, you can give users access to it by assigning them to site groups.

Notes

  • You can adjust access to areas of the portal site by assigning users to a site group for a specific area.
  • Local users and groups added to a site group in a server farm deployment of SharePoint Portal Server 2003 must be located on a front-end Web server. Any attempt to add a local user or group from a computer that is not a front-end Web server fails and returns the error message, "The User does not exist."
  • To add users and domain groups to portal sites, in SharePoint Portal Server 2003, only domain account mode is supported. With domain account mode, you add users and cross-site groups to your site using their existing domain account information, including their account names and e-mail addresses. You can also add Windows domain groups to your site.

The portal site-level rights follow:

  • BrowseUserInfo.  View information about users. This right is not available through the user interface.
  • CreatePersonalSite.  Create a personal site.
  • CreateSSCSite.  Create a Web site using Self-Service Site Creation.
  • ManageAudiences.  Add, change, or delete audiences, view members of a specific audience, and find the audiences to which a specific user belongs, as well as manage the rules defining audiences and compile audiences as the rules and members of an audience change.
  • ManagePeople.  Create, change, and delete site roles, including adding users to the site groups and specifying which rights are assigned to a site group.
  • ManageSearchIndexing.  Manage search indexing on a site.
  • ManageSite.  Manage a site, including the ability to perform all administration tasks for the site and manage contents and permissions.
  • ManageSubscriptions.  Add and remove subscriptions on a site.
  • UseSearch.  Perform a search on a site.
  • UseSubscriptions.  Subscribe to a site.

Note  You can use the SecurityManager.ManageSiteSecurity () method in the SharePoint Portal Server object model to manage these permissions programmatically.

Granting Access to Areas

SharePoint Portal Sever provides the ability to control permissions on a per-area basis. If you have sensitive information stored in an area and you do not want to expose the information to all members of your portal site, you can set permissions for just that area to control which users can view, edit, or add items to it. You can grant permissions to area listings or content to individual users, to groups of users, or to a site group. Per-area permissions work for any area listing or content in an area (for example, Announcements, Tasks, Shared Documents, and so on).

Note  In a Windows SharePoint Services site, it is possible to set security on a per-list basis. It is not possible inside a portal site, that is, for any lists inside an area.

Area permissions can be changed by any user who has the Manage Area Permissions right (by default, included in the Administrator site group) or Full Control permissions for that area. By default, all members of an area (all users assigned to a site group, except for the Guest site group) have access to all area content, including portal listings, lists, and document libraries. Each site group has a predefined level of permissions for all area listings and content.

Note  Area is the smallest object securable in SharePoint Portal Server. All objects in the area obey ACLs defined for that area, and there is no per-list security inside a portal site. Security is inheritable throughout areas. Groups are established at top-level of the portal site and you can break and rejoin inheritance.

The area-level rights follow:

  • ViewArea.  View an area and its contents.
  • AddListItems.  Add items to lists, add documents to document libraries, and add Web discussion comments.
  • EditListItems.  Edit items in lists, edit documents in document libraries, and customize Web Part Pages in document libraries.
  • DeleteListItems.  Delete items from a list, documents from a document library, and Web discussion comments from documents.
  • CancelCheckout.  Check in a document without saving the current changes.
  • ManagePersonalViews.  Create, change, and delete personal views of lists.
  • ViewPages.  View pages in an area.
  • AddAndCustomizePages.  Add, change, or delete HTML pages or Web Part Pages, and edit the portal site by using a Windows SharePoint Services-compatible editor.
  • ApplyStyleSheets.  Apply a cascading style sheet (.CSS file) to an area or the portal site.
  • BrowseDirectories.  Browse directories in an area.
  • AddDelPrivateWebParts.  Add or remove Web Parts on a personalized Web Part Page.
  • UpdatePersonalWebParts.  Update Web Parts to display personalized information.
  • CreateCategory.  Create an area on the portal site.
  • ManageCategory.  Delete or edit the properties for an area on the portal site.
  • ManageCategorySecurity.  Add, remove, or change user rights for an area.

You can use the SecurityManager.ManageAreaSecurity() method in the SharePoint Portal Server object model to manage these permissions programmatically.

Notes

  • All area backing Web sites in SharePoint Portal Server must be leaf Webs. (Leaf Webs are Webs that do not have subsites under them.) You cannot create subsites under area backing Web sites. So, this means that even if you are an administrator, you will not be able to create subsites under an area backing Web site.

  • There is no deny ACE in SharePoint Portal Server, and permissions are cumulative.

  • Portal role (site group) is site collection (SPSite)-wide and can only be created at the top level.

  • You can secure an area object in two ways:

    • Assign a user to a role (site group) and then assign the role to the area.
    • Directly assign a user to an area.

  • There are two kinds of security inheritance:

    • Role assignment inheritance, in which the user belongs to the role.
    • Role definition inheritance, which is the permission mask associated with the role.

  • In SharePoint Portal Server, when an area inherits security settings from its parent, it inherits both role assignment and role definition. However, when an area breaks inheritance from the parent area, it actually only breaks role definition inheritance. In other words, the same role cannot have different assignments in different subareas. This is the reason why portal role is site collection-wide only, and why you can change what a role means (the permissions it has) on a per-area level. You could theoretically make the Reader role have all rights on an area if you choose. You could also remove a role completely from an area, for example, you could stop users in the Reader role from accessing your area by removing the Reader role all together.

  • When you add a user to a portal role, the user has the right to the entire portal site because of to the reasons explained earlier. Therefore, if you only want a user to have access to a particular area, you would need to add the user directly to the area without assigning the user to any role. However, you should only add users to subareas; it is not recommended to add users directly to the home area. You should only assign users to roles in the home area.

  • You break an area's security inheritance from its parent if you change the security settings for that area in any way.

User-Level Security and Web Parts

There are two modes for editing Web Parts in SharePoint Products and Technologies: Shared mode and Personal mode. In Shared mode, changes are seen by all users. Personal mode changes are seen only by the individual making them.

The user-level rights controlling user modes follow:

Shared:

  • Add or customize pages.  Allows shared mode changes for Web Parts and Web Part pages outside document libraries.
  • Edit list items.  Allows shared mode changes for Web Parts and Web Part pages inside document libraries

Personal:

  • (Add or Remove Private Web Parts) Personalize Web Part pages.  Allows users to add or delete parts in personal mode for pages in Web sites and document libraries
  • (Updated Personal Web Parts) Personalize Web Parts.  Allows users to modify part properties in personal mode for pages in Web sites and document libraries.

SharePoint Portal Server Security Object Model

The SharePoint Portal Server Security object model provides support for creating and deleting users and roles, and for assigning permissions and rights masks. In the object model, a site group is referred to as a SPRole. A mapping of rights to a principle is an SPPermission. An ACL could be represented as an SPPermissionCollection.

As mentioned earlier, use the SecurityManager.ManageSiteSecurity() and SecurityManager.ManageAreaSecurity() methods in the SharePoint Portal Server object model to manage permissions for areas and sites.

For examples and object model information, see Code Snippets and the Reference sections of the Microsoft SharePoint Products and Technologies 2003 SDK.

Note  SharePoint Products and Technologies security descriptor prevents modifying server data on an HTTP GET. This can be overcome through the use of UnsafeSaveOnGet permission in Microsoft ASP.NET.

IIS Security

Two virtual servers are used when you install SharePoint Portal Server, one for the top-level portal site (content) and one for central administration. Each virtual server can have its own application pool associated with it. An application pool is a set of dedicated processes that service requests for that virtual server. Each application pool can have a unique user identity. By default, SharePoint Portal Server gives you two application pools both owned by a local computer account called "Network Service."

In a server farm scenario, the domain accounts for central administration and content virtual servers should be different. All front-end Web servers should have the same accounts.

Note  If the front-end Web servers need unique accounts, you must set up the accounts manually.

SQL Server and SharePoint Portal Server

You can configure SharePoint Portal Server to use Microsoft Windows authentication or Microsoft SQL Server authentication to connect to the portal site databases. However, we recommend Windows authentication because it is more secure and is the default authentication mode set during installation.

Note  For security reasons, you should limit the users with access to the databases and SQL Server. Also, look out for hotfixes at the Microsoft Web site that fix potential security issues in SharePoint Portal Server.

The Extra Secure Extranet

Secure Sockets Layer (SSL) and client certificates are supported in SharePoint Portal Server. When using SSL, you should use a separate domain account for the application pools for each virtual server.

SharePoint Security Validation

The one-click attack uses a FORM POST from script to unknowingly submit data. In such attacks, the malicious code gets the target to browse to the page that has the script. The target never knows what script got executed; this is a Web-wide problem, inherent in the design of scripting and cross-domain browser security.

SharePoint Products and Technologies address this problem with the use of a request digest for security validation. The digest contains site secret, time, and user name and should be present in every page served to the client.

Note  For security validation to take place, the digest must be returned with each post to the server.

Safe Mode Rendering

The Safe Mode Rendering feature in SharePoint Products and Technologies provides a safe execution environment for SharePoint pages and Web Part Pages. It eliminates the following risks:

  • User inserting code with an infinite loop or code that consumes a large amount of memory.
  • User inserting references to Web Form Controls or other classes that the administrator did not approve (or have tested for scalablity or robustness).

Using Safe Mode

Following are guidelines for using Safe mode in your portal-based applications and Web Parts.

  • Install the assembly of the part in either the virtual server's bin directory or the global assembly cache.
  • Enable the assembly in the SafeControls list in the web.config file.
  • The administrator can also choose to enable only specific types from within the assembly.
  • If the class has been marked unsafe or is not listed in the SafeControls list, an instance of the control is not created during the rendering of the .aspx page.

Safe Mode Restrictions

Safe mode and the Web Part infrastructure provide limits on the rendering of Web Parts. These limits are set either at the virtual server level or at the assembly level. You can set or change the virtual server level limits in web.config or in SharePoint Central Administration. You set assembly-level limits by assigning permissions to assemblies using Code Access Security policies. For more information on code access security, see Microsoft Windows SharePoint Services and Code Access Security.

Single Sign-On

The Single Sign-On in SharePoint Portal Server 2003 chapter from Microsoft SharePoint Products and Technologies Resource Kit provides an excellent description of Microsoft Single Sign-On service in SharePoint Portal Server. You can also see the Using Microsoft Single Sign-On Service topic for a Web Part sample.

Code Access Security

Code access security is a mechanism that helps limit the access code has to protected resources and operations. To learn how to implement policies for code access security for Microsoft SharePoint Products and Technologies and to see answers to some of the most commonly asked questions about code access security and its applicability to Microsoft SharePoint Products and Technologies, see Microsoft Windows SharePoint Services and Code Access Security.