SharePoint offers secure, web-based collaboration that is easy to set up. Security options are pervasive throughout the product. You’ll find information about security’s role in different contexts in various chapters of this book. The focus of this section, as well as the rest of the chapter, is on security options in the product that are often hidden from you as an advanced business user. Whether you are preparing for a new SharePoint installation, making configuration changes, or you just want to learn more about security, pay close attention to the rest of this section.
Note
Most of what applies to security at this level for SharePoint Foundation 2010 also applies for SharePoint Server 2010.
Regardless of the secure application, two important security principles to understand are authentication and authorization. Authentication is the method of identifying the current user of the application. Authorization is the access the user has within the application. Together, these two concepts provide a means for securing your SharePoint Sites.
Most important authentication settings are configured by IT at the web application level. An example of the effect of these settings is when and how you are prompted for logon information to a SharePoint site. Your business needs determine how the web application should be configured for authentication.
On the other hand, authorization settings are pervasive throughout the product. In fact, the number of places and ways SharePoint can be configured for access has increased over previous versions of the product. For example, Microsoft responded to customers’ needs to limit the access IT professionals have to content and settings that only business users need to see or set. A properly configured SharePoint Foundation 2010 web application allows content to be secured so that you, as the site owner, have the final say as to who sees what on your site. However, if you desire this level of security to your site, be sure to discuss this with your site host to guarantee the proper safeguards are in place. For example, SharePoint Foundation provides auditing of item and page views, updates, and deletes, but it is not configured by default.
Tip
INSIDE OUT Authentication isn’t just for the Internet browser
Authentication settings configured by IT can be critical to your SharePoint solution’s ultimate level of success or failure. Also, these settings often determine your ease of use. For example, the Office Integration Features depend on the proper authentication settings for the web application and your client environment.
The Connect To Outlook button, visible on a SharePoint Calendar, is one place that an incorrect configuration for your environment can have an effect. If your web application is set to use forms-based authentication and your Outlook client does not have the latest update that works with this setting, clicking the button will have no effect. This type of error is one of the quickest ways to lose the trust of your visitors because it gives no indication of what is wrong. If you were the visitor who clicked a button that doesn’t do what you expected, would you get the feeling the site is not working? Some visitors might lose confidence in the entire solution after a few experiences like that because they are not sure what will work and what is broken or why.
The five most common authentication types are outlined in this section. Each of these authentication types play a part in the secure web scenarios presented in the next section. Of the five, the classic Windows authentication has been most common in past SharePoint deployments and it is the type that SharePoint has supported most completely over the course of the product’s history. In contrast, claims-based authentication is newly introduced in the 2010 versions of the product to broaden the scope of authentication approaches used for SharePoint sites. For example, you can use claims-based authentication to allow Windows Live ID accounts to authenticate against your SharePoint site.
Classic Windows integrated authentication is the default option when creating a new web application, so it might be very commonly in use. It is also the option most similar to the Windows integrated authentication in the previous versions of SharePoint.
Claims authentication is new for SharePoint 2010, but it is also the recommended setting for new web applications. Upgrades from SharePoint 2007 can also use this setting, but if customizations are being upgraded, they might need code changes to work with the new security model. You will know claims-based Windows integrated authentication is in use when you see an account name with a short prefix before a pipe symbol ( | ). Compare the account name in Figure 2-8 to the account name displayed in Figure 2-9. The latter is an example of the User Information Display with a classic Windows integrated authentication web application. The prefix distinguishes user accounts with the same name in more than one identity provider. For example, if your user name was the same on www.live.com and in Windows, the prefix is the way you can keep track of two SharePoint accounts for the same user name.
In a change from the previous version, forms-based authentication can only be enabled with claims in SharePoint 2010. This type of authentication is popular in extranet scenarios because it doesn’t require an Active Directory account for each authenticated user. However, you might find that certain features don’t work as well with this setup. Particularly challenging is Office integration without the latest versions of the Office clients.
Claims-based without Windows authentication is where SharePoint 2010 really starts to differentiate itself from the previous version of the product. This authentication method allows some advanced scenarios but also requires more complexity on the back end. If you require claims-based authentication without Windows integration, keep in mind that this is a new technology, and it might take some time for the administration best practices to be established. If you need to integrate with some external types of identification systems, like Windows Live authentication, this can be a good option.
Anonymous access is most commonly used with publishing sites that are public facing, but might also make sense within a very large organization where many readers access the site, but only a few content authors publish information. Anonymous access can be used in combination with the previous four authentication types on one web application. Be sure to provide your content publishers with a way to log on through a link published on your intranet or on the page in the public site. In addition to the IT settings for the web application, ensure that you enable your site for anonymous access in the permissions settings of your Site Collection settings.
Note
You can read more about authentication methods and modes on Microsoft’s TechNet website in the section Plan Authentication Methods, at http://technet.microsoft.com/en-us/library/cc262350.aspx.
There are three common scenarios for web application security needs:
Public websites available for anyone on the Internet to read
Secured intranets for use only by users of one organization
Secured extranets for access by visitors across more than one organization
For the first scenario, your web application might be configured by IT for both anonymous access, for readers, and authenticated access of any type, for content authors. If your business needs demand extra security through separation of authoring from reading environments, you would need two separate web applications, possibly in different SharePoint farms and you would need a method to copy the content between the two.
Note
For public websites with complex workflows, you might consider upgrading to SharePoint Server. SharePoint Server provides the publishing site templates and authoring process designed for sites with many more readers than writers.
If you are unable to move to SharePoint Server, but your organization requires the security of a read-only public Internet presence, you have at least one out-of-the-box option, though it is manual. One method for moving the information is by copying the content database backup from an authoring farm to a production farm. When the backup is restored for reading, all the authored content will be moved over without the need for anyone to have access to change it.
Secured intranets are probably the most common use of SharePoint technologies over all versions of the product. Windows integrated authentication is a great choice for this scenario because it provides a great user experience. When all of the users of a SharePoint installation are members of the Active Directory domain, you can avoid logon prompts in many scenarios. Also, a secured intranet environment is most likely to benefit from the maturity of the Office client integration with SharePoint when combined with Windows integrated authentication. The other types of authentication will also work in this scenario, but they do increase the complexity of the configuration for the SharePoint farm’s host IT staff.
Secured extranets are a special case because they often involve collaboration between members of more than one organization. This scenario in particular is a great example for the use of claims-based authentication and how it might be of the most use to you.
The implementation of claims in SharePoint 2010 uses open standards. The use of open standards for authentication allows integration with a wide and growing amount of identification systems. So, when you use claims to authenticate your SharePoint web application, you might be able to allow more users from outside organizations with greater ease.
As mentioned earlier, forms-based authentication has historically been a popular option for extranets because it provides the option to use an account database to store user account information (instead of Active Directory). Whether you use forms-based authentication with Active Directory or another user directory, you might want to invest in a firewall such as Microsoft Forefront Threat Management Gateway (TMG). TMG integrates well with SharePoint and provides an extra layer of protection beyond the security provided through SharePoint and Windows Server.
Tip
INSIDE OUT For new implementations, start with what you know
Does your organization use some version of Microsoft Office and Windows on most computers? Are you familiar with logging on to a network driven by a Windows Server? If you are like a large amount of SharePoint users, those pieces are probably true. If that is the case, you’re lucky because it’s also the sweet spot of SharePoint.
Historically, SharePoint adoption has been high when people need a place to share Office documents on a Windows-based network. That is why such a focus had been placed on classic Windows authentication in past versions and why it was the default option for many SharePoint 2007 implementations. If you are starting from a clean slate in 2010, claims-based windows integration is the suggested starting point. Claims-based Windows integration offers the benefits of classic Windows authentication with the flexibility of claims management for future enhancements. On the other hand, if you’re a communications professional, and you want a way to get your organization’s message out to a large number of people—internally or externally—you will probably be comfortable with anonymous access to your SharePoint sites. SharePoint offers lots of authentication options, but you don’t have to use them all. Simple plans can yield powerful results.
SharePoint Foundation 2010 includes other security features that are configured outside the Site Collection that you might want to take advantage of. Each of the following features has settings that must be configured by the farm administrator at the web application level. Configuring each can have a significant effect on all of the Site Collections in a web application.
In some cases, you might need more than one method of authentication for your SharePoint sites. The previous section described the authentication options that are available for your web application. Public websites can allow anonymous authentication and another method, but other combinations require some additional changes.
For example, you might want multiple forms of authentication for an extranet. You might use forms-based authentication for extranet users outside your organization so that you don’t need to add them to your internal directory. You also might use your existing Active Directory Domain Services to provide identification for your internal users so that they don’t have to learn a new password.
In this case, you would like your IT staff to extend the web application to include an additional authentication method at a new web address. In this way, you effectively have two doors into your SharePoint house. One is locked with Active Directory, the other with a database of external user names and passwords.
In the previous section, authentication is described as the way of identifying the person who has logged on to your SharePoint site; authorization defines what SharePoint resources the identified person is allowed to access. You can read about controlling permissions for Site Collections, sites, lists, libraries, and individual content items later in this book.
The User Policy setting is an important authorization setting that affects authorization on your sites; configuration of this setting is left up to the IT staff supporting your SharePoint web application. The User Policy setting defines global authorization rights to a user for all the Site Collections in a web application.
Caution
Ask for your IT staff to communicate changes made to this setting. Changes aren’t visible to site or Site Collection administrators. And, the user policy changes override the authorization set by sites and Site Collections administrators. There are some valid reasons for user policy changes, but understanding SharePoint security is crucial to getting the best value out of your SharePoint sites. You can put yourself in the driver’s seat of your Site Collection by requesting information such as this from your operational staff, if it is not already clearly documented in the support policy or service level agreements.
An IT professional can enable Self-Service Site Creation on each web application individually. This will give the specified users permission to create new Site Collections in a web application. Did you notice the disconnect between the last two sentences? The former uses the word site and the latter the words Site Collection. The former is the wording used in Central Administration, but it would be clearer if it used the words Site Collection in the place of the word site.
There is a big difference between creating a Site Collection and a site. As a site administrator, you control the permission of users to create sites below your site; however, those sites are all contained within one collection of sites. On the other hand, allowing creation of Site Collections can be useful, as well. Each Site Collection provides a unique security boundary, a storage quota, and a context boundary. Often, Self-Service Site Collection Creation is extended with customizations. For example, it might be useful to track the reasons the Site Collection is needed and the length of time it will be needed for. My Sites are an example of this type of customization that has been added to SharePoint Foundation in SharePoint Server. To start, each My Site is provisioned through Self-Service Site Creation when first accessed by the owner of the site. SharePoint Server includes a workflow for decommissioning the site when the user is deactivated in Active Directory. While it is not necessary to upgrade from Foundation to Server to use Self-Service Site Creation, the SharePoint Product team provides a model of this feature’s use in the prime example of extending SharePoint Foundation, SharePoint Server.
Forms-based authentication can be useful, as described in the authentication section earlier. However, it doesn’t work well in some situations such as SharePoint integration with older versions of Office. If your site uses forms-based authentication and the visitors to your site encounter problems with older versions of Office, you can ask to have this setting disabled at the web application level. Disabling client integration can prevent errors that otherwise are confusing. However, some features, such as the Edit In Datasheet option for lists in the browser will also be disabled for all users when client integration is disabled.
You’re probably familiar with encryption for purposes such as securing online banking. Banks add this layer of security because without it, all information passed over the Internet is sent in clear text that can be captured and read by anyone between you and your bank. If your SharePoint site contains information that is sensitive, you will want encryption configured for your web application. Ask your IT staff to purchase and install a Secure Sockets Layer (SSL) certificate on the web servers and configure your web application for encryption. You will know when you are accessing an encrypted site when the web address begins with HTTPS instead of the normal HTTP prefix.
Another situation for which encryption is important is when your site’s authentication doesn’t encrypt user names and passwords. For example, forms-based authentication should always be used in combination with encryption to ensure the security of your SharePoint sites.
Note
Windows authentication, either with claims or classic mode, securely authenticates users without the additional need for encryption to secure user names and passwords. However, it is still a good practice to encrypt your site if other personal or sensitive information might be sent to or from your website besides user names and passwords.