Beyond Web Logs

There are two primary ways exist to create SPSite as a security context. One way is to use the current Windows or Forms identity, which is the default method whether you are accessing the site from the WSS Web application or an administrative console. This is also the method used with the SPSecurity.RunWithElevatedPrivileges delegate-the current principal that happens to be SHAREPOINT\system is used to create the site security context.

The other way to create the SPSite is by using an SPUserToken object. The SPUserToken is the token created upon authentication. It references the principal of the user from either Active Directory or the identity store with its groups and roles. In the case of a Windows identity, this token is used to query Active Directory for the TokenGroups property. These tokens time out after 24 hours, making them a good candidate for system code that needs to impersonate users in the case of workflow actions or post-processing of list data that happens slightly after the original action (not days later). This token timeout value can be set by using the STSADM console. Using the user token in the constructor of the SPSite enables code to make changes to the WSS object model just as if the actual user were making the changes. Using impersonation is a security-sensitive operation that requires the SharePointPermission with the Impersonate property set to true.

You can request the token for any user in the system by using the UserToken property of the SPUser class (provided that your code has the SharePointPermission with the Impersonate rights). If the current user is not the user requested, WSS builds the token on the fly from the user's Security ID and group membership. You can then pass this token to the SPSite's contructor to create a new impersonated security context.

For example, let's revisit the list event receiver from Chapter 6, "Lists and Content Types." On creation of a Litware Company record in either the Vendor or Customer list, we will create an announcement with the credentials of the user who created the item. When this code runs, it is in the context of the SHAREPOINT\system account, and we don't have access to the actual credentials of the user who created the item. To create the item under the impersonated security context, simply obtain a user token from the SPUser profile that created the object and pass that into the SPSite constructor. When the item is inserted into the announcements list, it will be as if the impersonated user created the item even though the event receiver is running under the identity of SHAREPOINT\system.

public override void ItemAdded(SPItemEventProperties properties) {
DisableEventFiring();
string CompanyName = properties.ListItem["Company"].ToString();
properties.ListItem["Company"] = FormatStringValue(CompanyName);
properties.ListItem.Update();
SPUserToken token =
properties.OpenWeb().AllUsers[properties.UserLoginName].UserToken;
using( SPSite site = new SPSite(properties.SiteId, token) )
{
using(SPWeb web = site.OpenWeb(properties.WebUrl))
{
SPListItem announcement = web.Lists["Announcements"].Items.Add();
announcement["Title"] = properties.ListItem["Company"].ToString();
announcement["Body"] = "A new company was added!";
}
}

In this code sample, we are using the AllUsers property of the site. Users are available through a reference to the site (the SPWeb class). Three user collections are available within the site, and choosing which one to use may be confusing. The AllUsers property lists all users, including members of the site as well as members of domain groups that are members of the site. The SiteUsers property contains the users who are members of the site collection, and the Users property is the smallest group, containing only users who are explicitly members of the site.

SharePoint