No real solution today can ignore the topics of authentication and authorization. Microsoft SharePoint 2013 takes security seriously and provides a modern and powerful set of tools, as well as a solid architecture, for supporting claims-based authentication and authorization. The native support for claims opens SharePoint 2013 to integration with third-party platforms as well as single-sign-on scenarios.
In this first chapter of Part VI you will dig into the main topics about authentication and authorization in SharePoint 2013. In particular, you will learn about claims-based authentication, as well as the old classic authentication mode, which is still available for the sake of backward compatibility. You will also learn how SharePoint authorizes users after having authenticated them. In the next chapter, you will focus on identity federation and OAuth.
Within its two authentication modes—classic and claims based—SharePoint 2013 supports three authentication methods:
Windows Authentication. Uses the Windows infrastructure, providing support for NTLM, Kerberos, Anonymous, Basic, and Digest authentication. X.509 Certificate Authentication is not supported, unless you manually configure users’ certificate mapping rules within Internet Information Services (IIS). It works both in classic mode and claims-based mode.
Forms-Based Authentication (FBA). Utilizes a username-and-password HTML form that queries a membership provider on the back end. By default, it includes providers for LDAP and SQL Server; however, you can develop custom providers of your own. FBA is based on the standard forms authentication provided by Microsoft ASP.NET, which resides at the very core of SharePoint. It works only in claims-based mode.
SAML Token-Based Authentication. Uses an external identity provider that supports SAML 1.1 and WS-Federation Passive profile. SAML token-based Authentication includes Microsoft Active Directory Federation Services (AD FS) version 2.0, LDAP, or custom third-party identity providers. It works only in claims-based mode.
You can configure each method against a web application or a zone using SharePoint Central Administration (SPCA), as shown in Figure 19-1. To reach the Create New Web Application page, simply open SPCA, click Application Management, and then click Manage Web Applications. There you will find a ribbon button for creating a new web application.
A SharePoint zone provides the ability to publish the same web application with multiple endpoints (URLs). Available since SharePoint 2007, the goal of this feature is to give you a method to share a common application configuration and common content databases between multiple IIS sites, which can each have specific configurations of authentication, authorization, security in general, and web.config files.
Starting with SharePoint 2013, the SPCA UI provides the settings for configuring claims-based authentication only. If you need to use classic authentication mode for backward compatibility, such as when running sites migrated from SharePoint 2010, then you must use PowerShell. This is only a temporary solution, however, because classic mode is deprecated and will be removed in future releases. Thus, when migrating an existing SharePoint solution to SharePoint 2013, you should carefully consider the task of migrating to claims-based authentication, too, if the source web application is not already claims based.
Remember that classic mode supports only Windows Authentication (that is, NTLM or Kerberos), while claims-based mode supports all the three available authentication methods.
In the following section, you will learn the main features of claims-based authentication.
The claims-based authentication mode was introduced with SharePoint 2010. It employs the concept of claims identity, representing each user’s identity as tokens made of claims. A claim is a statement, asserted by an issuer, about a subject, which is assumed to be true by the reader, due to a trust relationship between the reader and the issuer. The statement can be about any kind of information. For example, it could be the name, the identity, a role membership, a user preference, or anything else. Claims are issued by a claim provider and packaged into a security token, which is emitted by a security token service, which can also be an identity provider or can use an external identity provider. The identity provider is a service that authenticates the end users, based on a specific set of credentials. For example, an identity provider could be Microsoft Windows Live, Facebook, your Active Directory infrastructure with AD FS on top of it, and so on. The target of the security token is a service provider, which can be a website, a web service, or whatever else. The entity described by the security token is called Subject; in general, this is a user, a server, a service, or anything else that can have an identity of its own.
The power of claims-based authentication arises from the fact that claims-based identities are cross platform and can lead your solutions to provide single-sign-on capabilities on multiple platforms using a standard, secure, and reliable protocol. You can use claims to federate your company with customers, resellers, external service providers, and other third parties. Using claims-based authentication and external security token services and identity providers allows you to federate and trust external systems without duplicating users’ credentials and passwords. Only the identity providers will manage credentials and passwords, while all the various service providers will trust the intermediary identity providers and the security tokens emitted by the security token services.
Each claim consists of a ClaimType property, which in general is a URI that uniquely defines the type of the claim; a ClaimValue property, which is the real content of the claim; and a ClaimValueType property, which defines the data type of the ClaimValue property. Each claim can also be described by some other information, such as the Issuer and the target Subject properties.
The capability to describe an identity as a set of claims (a set of true and trustable information) allows supporting any kind of authentication mechanism. In fact, with the claims-based mode, you can use Windows Authentication, but you can also use FBA or any third-party trusted identity provider.
If you use Windows Authentication in claims-based authentication mode, the Windows identities will be converted to a set of claims representing the current user. You can still take advantage of integrated authentication, because the Windows identity of the current user will be translated into claims at no cost to you. In addition, a Windows user authenticated using classic mode is almost the same as a user authenticated with claims-based mode, because internally in SharePoint the user identity is the same (an instance of type SPUser). On the back end, SharePoint 2013 always uses claims identities—regardless of the mode you selected on the front end—to communicate between the front-end servers and the servers (within the same farm) hosting service applications.
In your code, the current user’s identity and principal will be instances of type ClaimsIdentity and ClaimsPrincipal, available in the assembly Microsoft.IdentityModel released with Windows Identity Foundation (WIF) 1.0.
Be careful: Microsoft .NET Framework 4.5 defines two new types for ClaimsIdentity and ClaimsPrincipal in the System.Security.Claims namespace in mscorlib.dll, and these are broadly available in all the .NET Framework 4.5. However, SharePoint 2013 uses the WIF 1.0 library, with the addition of an extension library (Microsoft.IdentityModel.Extensions.dll) for supporting OAuth and server-to-server authentication. Thus, the ClaimsIdentity and ClaimsPrincipal types used by SharePoint 2013 are those available in the old version of WIF, not the new one introduced in .NET 4.5. Chapter 20 will cover this topic in depth.
When you are migrating a SharePoint 2010 web application that uses classic-mode authentication to claims-based mode in SharePoint 2013, you can use the PowerShell cmdlet Convert-SPWebApplication. The syntax is as follows:
Convert-SPWebApplication -Identity <SPWebApplicationPipeBind> -To <String> [-Force <SwitchParameter>] [-RetainPermissions <SwitchParameter>]
where the Identity argument identifies the web application to convert. The To argument declares the target authentication mode, which by now can only assume the literal value of Claims. There is also an optional Force argument that is useful to keep permissions (RetainPermissions) while migrating. For example, if you want to migrate the web application published at the URL http://migrated.intranet.local/ to claims-based authentication, you can use the following syntax:
Convert-SPWebApplication -Identity http://migrated.intranet.local -To Claims –RetainPermissions -Force
The command converts the web application’s authentication mode to Windows Claims authentication mode, which is the most similar to Windows Classic, and migrates the user accounts in the content database to claims-encoded values, keeping their assigned permissions. To execute the migration, you must be a member of the securityadmin role of the target SQL Server database server, a member of the db_owner role of all the content databases that need to be upgraded, and a member of the Administrators group of the server on which you are running the PowerShell script.
After you convert a web application to claims-based authentication, you cannot revert it back to classic-mode authentication. Thus, you should plan the migration carefully and eventually test it in a testing environment before applying it in production.
After migration, check in the ULS (Unified Logging System) log for any user accounts that are no longer in the Active Directory database (defined in the converted content databases), because they will not be migrated.
If you want to convert only a subset of users to claims-based authentication, such as only those who use a specific content database, PowerShell can help. Specifically, use the MigrateUsersToClaims method provided by the SPWebApplication class. You can find further details about this method at http://msdn.microsoft.com/en-us/library/jj171669.aspx.
With claims-based mode, you can enable multiple authentication methods within the same zone. Thus, you can now have a unique zone—and a unique URL—to access your site, but your users will be able to choose between multiple authentication methods with which to provide their credentials.
When you configure claims-based mode with a unique authentication method, SharePoint will authenticate the end users directly with that unique method. However, if you configure multiple authentication methods, your users will be prompted to select their desired authentication method. Figure 19-2 depicts the authentication method selection page, configured to support both Windows Authentication and FBA.
Figure 19-2. The Sign In page, on which end users select the authentication method when multiple authentication methods are configured on the same zone.
Behind the scenes, the authentication engine of SharePoint normalizes all the users’ identities into SPUser instances, converting every identity into a set of claims. The users’ identity normalization process involves invoking a native service application of SharePoint, called the Security Token Service (STS). Figure 19-3 shows a functional schema of the identity normalization process managed by SharePoint 2013. This section will cover Windows Authentication and FBA, while SAML-based authentication will be covered in the next chapter.
In terms of capabilities, Windows Authentication is almost the same as the old-style classic mode. Backstage, however, the user’s identity is translated into a set of claims. If you develop a custom control or Web Part for writing a user’s identity, you will see that the current user’s identity is a ClaimsIdentity. The set of claims that comprise the user’s identity by default are
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier. A claim with a value of type String that defines the user name.
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid. A claim with a value of type String that defines the security identifier (SID) of the user.
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid. A claim with a value of type String that defines the SID of the primary group of the users.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn. A claim with a value of type String that defines the user principal name (UPN) of the user.
http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname. A claim with a value of type String that defines the logon name of the user.
http://schemas.microsoft.com/sharepoint/2009/08/claims/userid. A claim with a value of type String that defines the user ID of the current user. For Windows Authentication, it assumes a value of 0#.w|{Username}, where the string 0#.w| is a trailer and {Username} is the user name of the user. The w stands for Windows Authentication.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name. A claim with a value of type String that defines the name of the user, assuming a syntax like that of the previously described claim (userid).
http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider. A claim with a value of type String that defines the name of the identity provider. For Windows Authentication, it assumes a value of windows. This is a SharePoint-specific claim.
http://schemas.microsoft.com/office/2012/01/nameidissuer. A claim with a value of type String describing the issuer of the nameid claim (see the nameid entry later in this list). This is a Microsoft Office–specific claim.
http://sharepoint.microsoft.com/claims/2009/08/isauthenticated. A claim with a value of type String and an inner value of True or False, used to indicate whether the current user is authenticated. This is a SharePoint-specific claim.
http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid. A claim with a value of type String that defines the ID of the current SharePoint farm. This is a SharePoint-specific claim.
http://schemas.microsoft.com/office/2012/01/upn. A claim with a value of type String that describes the UPN of the current user. This is an Office-specific claim.
http://schemas.microsoft.com/office/2012/01/nameid. A claim with a value of type String that describes the unique name identifier of the current user. This is an Office-specific claim.
http://sharepoint.microsoft.com/claims/2009/08/tokenreference. A claim with a value of type String that defines a reference to the user token. This is a SharePoint-specific claim.
http://sharepoint.microsoft.com/claims/2012/02/claimprovidercontext. A claim with a value of type String that defines the context of the current user token. This is a SharePoint-specific claim usually corresponding to the URL of the context.
http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid. A claim with a value of type String that defines the SID of a group to which the current user belongs. A single ClaimsIdentity could contain many claims of this type, depending on the number of groups to which the current user belongs.
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod. A claim with a value of type String that defines the configured authentication method. When using Windows Authentication, it assumes a value of http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows.
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant. A claim with a value of type DateTime that defines the date and time the token was issued.
To extract the value of the claims, you can use code such as in Extracting claims from a current user’s identity.
In this example, it suffices to cast the current user’s identity (this.Page.User.Identity) to the ClaimsIdentity type of the Microsoft.IdentityModel namespace. Assuming the cast is successful, you will be able to enumerate the Claims property and extract each individual Claim instance.
When you configure FBA, you gain the capability to authenticate your users against an external repository of users. By default, this can be an LDAP or Microsoft SQL Server database built using the standard SQL Membership Provider of ASP.NET. Of course, you can also develop custom membership providers of your own, querying any kind of users’ repository. In the next section, you will learn how to configure SharePoint 2013 to support FBA with the standard SQL Membership Provider. For now, consider the default set of claims that make up the user’s identity when using FBA:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier. The same as in Windows Authentication.
http://schemas.microsoft.com/ws/2008/06/identity/claims/role. A claim with a value of type String that defines the name of a role to which the current user belongs. There could be many claims of this type in a single ClaimsIdentity, depending on the number of roles to which the current user belongs.
http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname. The same as in Windows Authentication.
http://schemas.microsoft.com/sharepoint/2009/08/claims/userid. A claim with a value of type String that defines the user ID of the current user. For FBA, it assumes a value of 0#.f|{MembershipProvider}|{Username}, where the string 0#.f| is a trailer, {MembershipProvider} is the name of the configured membership provider, and {Username} is the user name of the user. The f stands for FBA.
For further details about login name encoding, please read the following Wiki page on TechNet: http://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-2013-and-sharepoint-2010-claims-encoding.aspx.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name. A claim with a value of type String that defines the name of the user, assuming a syntax like that of the previously described claim (userid).
http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider. A claim with a value of type String that defines the name of the identity provider. For FBA, it assumes a value of forms:{MembershipProvider}, where {MembershipProvider} is the name of the configured membership provider. This is a SharePoint-specific claim.
http://sharepoint.microsoft.com/claims/2009/08/isauthenticated. A claim with a value of type String and an inner value of True or False, used to indicate whether the current user is authenticated. This is a SharePoint-specific claim.
http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid. A claim with a value of type String that defines the ID of the current SharePoint farm. This is a SharePoint-specific claim.
http://schemas.microsoft.com/office/2012/01/upn. A claim with a value of type String that describes the UPN of the current user. This is an Office-specific claim.
http://schemas.microsoft.com/office/2012/01/nameid. A claim with a value of type String that describes the unique name identifier of the current user. This is an Office-specific claim.
http://sharepoint.microsoft.com/claims/2009/08/tokenreference. A claim with a value of type String that defines a reference to the user token. This is a SharePoint-specific claim.
http://sharepoint.microsoft.com/claims/2012/02/claimprovidercontext. A claim with a value of type String that defines the context of the current user token. This is a SharePoint-specific claim that usually corresponds to the URL of the context.
In this section, you will learn how to configure a SharePoint 2013 web application to support FBA against a SQL Server database. The process involves configuring and creating a SQL Server database, changing the web.config file of the target web application, SPCA, and SharePoint STS, configuring SQL Server permissions, configuring SharePoint, and enabling users and roles in SharePoint.
To configure SharePoint to support FBA with SQL Membership Provider, you first need to create a SQL Server database file that supports your environment. To help you, ASP.NET provides a tool called ASPNET_REGSQL.EXE, which is available in the Microsoft .NET Framework folder. You invoke ASPNET_REGSQL.EXE within the Microsoft Visual Studio command prompt, and it creates a SQL Server database file. The tool is organized as a wizard (see Figure 19-4) with four main pages:
Welcome screen. There is nothing more to do here than simply click the Next button.
Select A Setup Option. On this page, you select whether to configure a new database or to remove an existing one. Choose the Configure SQL Server For Application Services option.
Select The Server And Database. Here, you select the target SQL Server database server where the database file will be created, together with the authentication method that will be used to communicate with the server, and the name of the database file that will be created.
Confirm Your Settings. This is simply a summary of your settings.
To learn more about FBA with a SQL Server database on the back end, consult http://www.microsoft.com/en-us/download/details.aspx?id=34684.
After you create the database, you need to configure some users and groups to use in SharePoint. For this purpose—and for the sake of simplicity—you can create a new ASP.NET Empty Website project in Visual Studio.
Remember that SharePoint 2013 is based on.NET Framework 4.5. Therefore, your website should be created using the same target version of .NET Framework to avoid issues with varying assembly versions.
You can configure the website by going to Project | ASP.NET Configuration, which brings up the ASP.NET Web Site Administration Tool. This is a well-known tool with which every ASP.NET developer should be familiar. From there, you can use the Security Setup Wizard to configure your site for supporting FBA using the previously created SQL database. You can also manually configure the web.config file, if you like. After completing this task, the web.config file of the sample site will look like the XML excerpt illustrated in The web.config file of the sample site for configuring FBA in Visual Studio.
If you are not familiar with the Web Site Administration Tool site, see the document “Web Site Administration Tool Overview,” which is available on MSDN at http://msdn.microsoft.com/en-us/library/yy40ytx0.aspx.
The type attribute values, as well as the connectionString attribute, in the preceding listing should appear on a single line in your code. They’re wrapped here due to typographic constraints.
These configuration elements will be useful when configuring SharePoint 2013 for FBA. While you’re in the Security Setup Wizard, you can also configure some users and groups, for testing purposes. In the sample code that accompanies this chapter, the following roles have been created:
Admins
Managers
Users
In addition, the following users have been created:
SampleAdmin01
SampleManager01
SampleUser01
As their names imply, each user belongs to the corresponding role. For example, you can give them a password value of Passw0rd!. You should test your authentication infrastructure by writing a couple of sample pages for logging in and logging out.
Now that you have a working configuration for you site, you are ready to apply that configuration to SharePoint. First, you need to locate the web.config file of the web application where you will configure FBA. By default, the root folder of a SharePoint web application is located in the C:inetpubwwwrootwssVirtualDirectories folder of every front-end server.
For the sake of simplicity, if you are working in a lab environment, you could create a new web application by using SPCA or PowerShell, and configure it with the following steps. Otherwise, in a production environment, you should locate the web.config file of the real target web application.
Next, you need to copy the connectionStrings/add element that defines your SQL Server membership database into the connectionStrings element of the target web.config file. Be careful while editing the web.config file, and make a backup copy of it before applying any kind of change. If the connectionStrings section is missing, you must create it from scratch, adding it after the configSections element of the web.config file, as shown:
<connectionStrings> <add name="SharePointFBA" connectionString="server=SP2013SQL;database=SP2013_Farm_FBA;integrated security=SSPI;"/> </connectionStrings>
Then you need to locate the Membership and RoleProvider sections, within the system.web section of the target web.config file. There, you need to copy only the providers’ configuration, without changing the default providers that were already configured by SharePoint. The result should look like the following:
<membership defaultProvider="i"> <providers> <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add connectionStringName="SharePointFBA" applicationName="/" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" requiresUniqueEmail="true" passwordFormat="Hashed" name="FBASQLMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> </membership> <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false"> <providers> <add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add connectionStringName="SharePointFBA" applicationName="/" name="FBASQLRoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> </roleManager>
The type attribute values in the preceding listing should appear on a single line in your code. They’re wrapped here due to typographic constraints.
In the previous example, the code highlighted in bold shows that SharePoint 2013 already has a default membership provider named i and a default role provider named c. These are the providers that manage the claims-based infrastructure.
After you have configured the web.config file of the target web application, you need to configure the web.config file of the SPCA web application in the same way, as well as the web.config file of the internal SharePoint STS. The SPCA web application must be configured so that you can manage users defined in the FBA database from within the administrative pages, as well. You can still find its web.config file in a folder in the C:inetpubwwwrootwssVirtualDirectories path of every front-end server. The STS web application needs to have access to the FBA database in order to retrieve claims and information about the authenticated users during identity normalization. You can find the STS service of SharePoint and its web.config file in the SharePoint15_RootWebServicesSecurityToken folder.
To take full advantage of the authentication infrastructure that you have just configured, the application pools of SharePoint need to have access to the SQL Server database you configured for FBA. Thus, you need to properly configure the database’s permissions. This is a simple but fundamental task. To carry it out, you need to enable the Windows identities configured for the following:
The SPCA application pool
The STS application pool
The application pool of the target web application
All three need the following database role memberships:
aspnet_Membership_FullAccess
aspnet_Roles_FullAccess
You are almost done. Now you simply need to configure the FBA providers—for example, through the SPCA interface. To access the list of available web applications, click Application Management, then click Manage Web Applications, and then choose the FBA target. On the ribbon, click the Authentication Providers command, and in the window that appears, click the Default Configuration link. The Edit Authentication configuration page will open.
Select the Enable Forms Based Authentication (FBA) check box, and provide the name for the membership provider and role provider to use. Figure 19-5 shows the configuration dialog box, completed with information based on the current sample scenario.
The last step in configuring FBA is to enable some users or roles to access the site collections defined in your target web application. You can accomplish this task either from SPCA or from the People And Groups page of the target site.
Notice that if you now try to browse for users or roles, you will be able to browse both Windows and FBA users within the same browsing windows. From the perspective of SharePoint 2013, all the users are claims identities, regardless of the authentication provider that was used. Notice how searching for users in Figure 19-6 returns one result in the role repository of FBA and three more results in the security groups of Windows.
No matter which authentication mode and methods you choose, authorization in SharePoint is always managed the same way. This is a great feature that makes life easier for SharePoint administrators, because they do not need to care about the front-end authentication environment.
Authorization in SharePoint is based on permission levels, which are a formal definition of a set of permissions. Permission levels can be assigned to users (SPUser) or groups (SPGroup). Both SPUser and SPGroup inherit from SPPrincipal, which is the base class for every principal in SharePoint, including app principals, as you will learn in Chapter 20. The permission is the low-level item from an authorization viewpoint. SharePoint defines many permissions, and Table 19-1 presents the full list, in the same order as they are defined in the SharePoint management interface. Consider that these permissions cannot be customized or extended. However, it’s unlikely that you would need to customize them because they cover a very wide range of needs.
Table 19-1. The list of permissions defined in SharePoint 2013
Permission | Description |
Manage Lists | Allows you to create and delete lists, add or remove columns in a list, and add or remove public views of a list. |
Override Check Out | Allows you to discard or check in a document that is checked out to another user. |
Add Items | Allows you to add items to lists and add documents to document libraries. |
Edit Items | Allows you to edit items in lists, edit documents in document libraries, and customize Web Part pages in document libraries. |
Delete Items | Allows you to delete items from a list and documents from a document library. |
View Items | Allows you to view items in lists and documents in document libraries. |
Approve Items | Allows you to approve a minor version of a list item or document. |
Open Items | Allows you to view the source of documents with server-side file handlers. |
View Versions | Allows you to view past versions of a list item or document. |
Delete Versions | Allows you to delete past versions of a list item or document. |
Create Alerts | Allows you to create alerts. |
View Application Pages | Allows you to view forms, views, and application pages, and enumerate lists. |
Manage Permissions | Allows you to create and change permission levels on the website and assign permissions to users and groups. |
View Web Analytics Data | Allows you to view reports on website usage. |
Create Subsites | Allows you to create subsites such as team sites, meeting workspace sites, and document workspace sites. |
Manage Web Site | Grants the ability to perform all administration tasks for the website, as well as manage content. |
Add and Customize Pages | Allows you to add, change, or delete HTML pages or Web Part pages, and edit the website using a SharePoint Foundation–compatible editor. |
Apply Themes and Borders | Allows you to apply a theme or borders to the entire website. |
Apply Style Sheets | Allows you to apply a style sheet (CSS file) to the website. |
Create Groups | Allows you to create a group of users that can be used anywhere within the site collection. |
Browse Directories | Allows you to enumerate files and folders in a website using SharePoint Designer and WebDAV interfaces. |
Use Self-Service Site Creation | Allows you to create a website using self-service site creation. |
View Pages | Allows you to view pages in a website. |
Enumerate Permissions | Allows you to enumerate permissions on the website, list, folder, document, or list item. |
Browse User Information | Allows you to view information about users of the website. |
Manage Alerts | Allows you to manage alerts for all users of the website. |
Use Remote Interfaces | Allows you to use SOAP, WebDAV, the Client Object Model, or SharePoint Designer interfaces to access the website. |
Use Client Integration Features | Allows you to use features that launch client applications. Without this permission, users will have to work on documents locally and upload their changes. |
Open | Allows users to open a website, list, or folder in order to access items inside that container. |
Edit Personal User Information | Allows a user to change his or her own user information, including adding a picture. |
Manage Personal Views | Allows you to create, change, and delete personal views of lists. |
Add/Remove Personal Web Parts | Allows you to add or remove personal Web Parts on a Web Part page. |
Update Personal Web Parts | Allows you to update Web Parts to display personalized information. |
A permission level is made up of a set of permissions selected from the list in Table 19-1. SharePoint 2013 defines a default set of seven permission levels:
View Only. Allows the user to view pages, list items, and documents. Document types with server-side file handlers can be viewed in the browser but not downloaded.
Limited Access. Allows the user to view specific lists, document libraries, list items, folders, or documents when given permissions.
Read. Allows the user to view pages and list items, and download documents.
Contribute. Allows the user to view, add, update, and delete list items and documents.
Edit. Allows the user to add, edit, and delete lists, and view, add, update, and delete list items and documents.
Design. Allows the user to view, add, update, delete, approve, and customize pages.
Full Control. Gives the user full control.
Chapter 2 showed how an out-of-the-box SharePoint site configures four groups of users: Excel Viewers, Site Visitors, Site Members, and Site Owners. To configure permission levels for such users, begin on the Site Permissions page, which you can access from the Settings menu (the gear at the top-right of the browser, just beside the user name) on the Site Settings page. Click the Permission Levels ribbon command to display a page in which you can create new permission levels. To create and configure groups, go to the People And Groups page, which you can reach through the Site Settings page.
When you enable anonymous access for a site, you will be able to configure permissions for anonymous users. Figure 19-7 shows the choices for anonymous access: Nothing (no access), Lists And Libraries (but only those for which anonymous users have been explicitly enabled), and Entire Web Site. This page also provides an option to determine whether anonymous users will be able to access remote client APIs anonymously. Consider that an anonymous user does not have any claim assigned, but he or she is still represented by a ClaimsIdentity and a ClaimsPrincipal, in case of claims-based authentication mode.
Anonymous access can be configured from SPCA via the Authentication Providers page. You used this page earlier in this chapter to configure the authentication providers for a web application. You can follow the procedure shown at http://technet.microsoft.com/en-us/library/ff608071.aspx#section2.
After you define permission levels and assign them to users or groups, you can also override default permissions at the list or library level, or even at the single-item level. Because webpages are items, as are documents and general list items, you can configure permissions at the single-page level, too.
In this chapter, you learned how SharePoint 2013 authenticates and authorizes users. In particular, you saw that there are two authentication modes: claims-based mode, which is the default, and classic mode, which is available only in code and for backward compatibility. You can choose from three authentication methods: Windows Authentication, FBA, and using trusted identity providers, which will be explained in Chapter 20. You also walked through how to configure both the claims-based mode and FBA to authenticate users against a SQL Server database. Finally, you learned how SharePoint manages authorizations and permissions.