Understanding User Access Management and Personalization

Before you learn how to manage access to any SharePoint site, you need to understand two very important concepts in SharePoint related to the users who connect to your sites:

• The difference between access management and personalization

• How users log in to a SharePoint site

Understanding these concepts helps you learn how to effectively manage a site, protect the site’s integrity from users who shouldn’t have access to certain information, and make the user experience as productive and problem-free as possible.

What Is the Difference Between User Access Management and Personalization?

Imagine you work for a company where users from around the globe share information related to their various business activities. There are different divisions such as Sales, Marketing, Finance, and Legal. Members of a specific division can log in to their portal site and stay up-to-date on projects and initiatives as well as work with others in their divisions and teams. For this to happen effectively, you must configure the SharePoint environment to support the following:

• User access management:   There are rules that determine what a user can do on a site. To ensure that users can access only the content they need to perform their work, you apply permissions to each divisional site. Within a specific division, users may have different roles and privileges. For example, some users only view content, while others can add or approve new content.

• Personalization:   Ensures that content is relevant to the users of a site. You use personalization and audience features to do this. Personalization allows users to view only content that applies to them. You may accomplish this by providing them with the ability to customize the interface to display only items that are relevant to them, or it may mean creating certain views that only display items where their username is displayed in a specific column, such as the Assigned to column. In some cases, you may want to target specific content elements such as a document, list item, or Web Part to members of a role. Through audiences, you can identify the groups of people that would find information relevant as you publish it. Perhaps in the Sales division, for example, certain promotions and sales procedures are only relevant for the North American region, and distracting to sales personnel from the other regions. Therefore, when publishing these promotional documents, the content manager would select a North American audience.

Before you try to personalize content, it’s very important that you solidify the underlying content access. With that in mind, the chapter covers user access features of SharePoint 2007 first, and then discusses audiences and other personalization features in greater detail.

How Do Users Log In to a SharePoint Site?

SharePoint 2007 greatly improved its interface to address alternate authentication providers, user switching, and security trimming. Before delving into these improvements, you need to understand how a user logs in to a site. When users click a link or enter the web address of a SharePoint site, they are either logged into the site automatically because they may already be authenticated to the site, or they are prompted for a username and password via a dialog box or form. In some cases, there may be no need for authentication because the site is configured for anonymous access. This chapter primarily reviews scenarios where the user is connecting in an authenticated environment.

Once users are logged into the site, they will see only content and user-interface elements that they have been given permission to view. The content that users view and edit is determined by their SharePoint site group membership. Site groups are specific roles in SharePoint that determine what a user can do within a site.

Tip 

For more on the different site groups, see the section “Working with Site Groups and Permission Levels.”

Most organizations using SharePoint in a corporate or enterprise setting, such as an intranet, will use Active Directory to manage user profiles and determine how users log in to the network, which is also known as the authentication process. Since SharePoint 2003, Active Directory has been used to authenticate users and build user profiles using basic personalization features. This means that if your organization uses Active Directory, SharePoint becomes a great browser-based tool in which to work because a user who logs in to the domain does not typically need to enter credentials again to access a SharePoint site. This is because when the system administrator configured the SharePoint server, it was added as a member of your Active Directory domain. Therefore, when you enter your username and password to connect to the network, the SharePoint environment recognizes you as a member and therefore does not require you to specify your username and password again. In addition, SharePoint allows you to connect to sites based on your site group membership and retains your permissions as you access various other Windows-based systems such as file shares or printers. Most users prefer this type of experience because it can be tedious and confusing to manage both multiple usernames and passwords.

A site manager can add specific Active Directory users to a site group by typing his name or email address into the site membership interface. See Figure 9-1 for an example of how this can work.

Figure 9-1

However, in organizations with thousands of users, it’s more realistic to add Active Directory security groups to a SharePoint site group. This not only reduces administrative overhead when you first set up a site, but also means the site’s membership stays up-to-date as new users join or leave the organization. As you add users to the Active Directory security group, they are automatically assigned to the SharePoint site group that has been associated with the security group, as shown in Figure 9-2.

Figure 9-2

The rest of this chapter looks at specific access and authentication examples based on an underlying assumption that Active Directory is the primary membership store.

Other Authentication Methods

In SharePoint 2007, you can connect your membership database to stores aside from Active Directory or Windows. In fact, because SharePoint is built on the .NET 2.0 Framework, any membership provider that you can use in ASP.NET 2.0 can control access to the SharePoint environment using forms-based authentication.

Although Active Directory and other membership provider services, such as a SQL Server database or custom application, provide some great benefits to SharePoint 2007, you’re not required to use them. In fact, users can log on to SharePoint sites if they have a local user accounts on the server.

Although enabling forms-based authentication is beyond the scope of this book, you can use custom membership databases as well as existing non-Active Directory connections. For more information, see Professional SharePoint 2007 Development

Try It Out-Sign In as a Different User

In this example, you’ve already logged in to a site with a user account and need to sign in as a different user with a different set of credentials. Depending on how your organization is using SharePoint, you may have entered login information when you first accessed the site, or you may have automatically logged in because your organization is using Active Directory.

Follow these steps to sign in as a different user:

1. From the home page of your Intranet Portal site collection created in Chapter 8, click the Welcome link as shown in Figure 9-3.

   
   Figure 9-3

2. Select Sign in as Different User. A login box appears.

3. Enter the credentials of the user you want to log in as.

4. Click the OK button. You now see the name of the user you logged in as in the welcome menu.

How It Works

Signing in as a different user is a new capability for SharePoint 2007 - previous versions of the application, especially those associated with Active Directory, did not support it. This capability is important when you start applying special access settings or configurations to your environment and you need to validate your configurations by logging in under test user accounts. For example, if the members of the reader group for your site should not have access to a specific document library, you can set up a test user account in the reader group and log in as that user to confirm that the library is not accessible. Also, if you support an environment and users claim that they cannot perform a specific action or see a particular menu item, you can log in as a test user with the same access rights as that user to troubleshoot the problem.