MSDN Magazine - February 2008 - (Page 56) Figure 2 Creating a New WSS Group SPWeb site = SPContext.Current.Web; SPUser currentUser = site.CurrentUser; // create new group site.SiteGroups.Add(“Site Members”, currentUser, currentUser, “Site Group created at “ + DateTime.Now.ToString()); // assign permission level to new group SPGroup NewGroup = site.SiteGroups[“Site Members”]; SPRoleAssignment roleAssignment = new SPRoleAssignment(NewGroup); SPRoleDefinition permLevel = site.RoleDefinitions[“Contribute”]; roleAssignment.RoleDefinitionBindings.Add(permLevel); site.RoleAssignments.Add(roleAssignment); SPWeb site = SPContext.Current.Web; SPUser currentUser = site.CurrentUser; SPGroup group = site.SiteGroups[“Site Members”]; SPUser user1 = site.SiteUsers[@”LITWAREINC\BrianC”]; SPUser user2 = site.SiteUsers[@”LITWAREINC\AllFTE”]; group.AddUser(user1); group.AddUser(user2); Identity, Elevation, and Impersonation While the WSS security model represents external security principals as SPUser objects, it also provides WSS groups as a means to ease the configuration of permissions within the scope of a site collection. For example, you can design a set of WSS groups within a site collection for specific user roles, such as Site Members, Content Manager, and Site Administrators. Once you have done this, you can configure the site’s security settings by simply assigning permission levels to WSS groups instead of assigning permission levels directly to SPUser objects. The obvious benefit to creating WSS groups is that they help to eliminate the ongoing need to reconfigure permissions as new external users and groups are added and removed. Instead, you can configure permissions once and for all when the site is created. Then, moving forward, you simply add and remove exThe Windows SharePoint ternal users and groups to Services security model and from WSS groups. WSS often forces developers groups really follow the exact same design principles to differentiate between as Active Directory groups, Windows identity and WSS with the main difference user identity. being that WSS groups are defined and exist only within the scope of a single site collection. WSS groups are represented in the WSS object model as SPGroup objects. The SPWeb object exposes two collections of SPGroup objects, named Groups and SiteGroups. The Groups collection includes all the WSS groups that have been directly assigned permission in the current site, while the SiteGroups collection is a super set of the Groups collection and includes all of the WSS groups that have been created inside the current site collection. When you want to create a new WSS group, you should call the Add method exposed by the SiteGroups collection and then assign the new WSS group with one or more permission levels within a target site. Figure 2 shows an example of creating a new WSS group named Site Members and assigning it the built-in Contribute permission level within the current site. Once you have created a new WSS group, it is pretty easy to add external users and groups as members. An SPGroup object exposes an AddUser method, which accepts an SPUser object, which in turn allows you to add external users and groups: 56 msdnmagazine Office Space WSS Groups The worker process for a WSS Web application is controlled through IIS Application Pools. The worker process identity for a Web application warrants your attention and is configurable through the SharePoint Central Administration application. You should configure the worker process identity for a Web application in terms of domain accounts (such as LITWAREINC\ SP_WorkerProcess) instead of relying on local accounts (such a NETWORK SERVICE). Note that the worker process identity for a Web application must be a privileged Windows account that has been configured with SQL Server permissions to read and write to one or more content databases. The worker process identity for the Web application running the SharePoint Central Administration site must be even more privileged since it requires read/write permissions to the farm’s configuration database. When the code behind a Web Part or a custom application page executes in response to a user request, the code does not execute under the worker process identity of the hosting Web application. Instead, WSS uses impersonation to switch the Windows security context over to another Windows account. In fact, if you look inside the web.config file for a WSS Web application, you will see the following entry: When a request is executed for a user that has been authenticated against a Windows account, the request impersonates the current user’s Windows identity. However, the same approach is not possible for FBA users because FBA authentication does not create a Windows security token and has no Windows identity. Therefore, requests for users running under FBA authentication impersonate the identity of the Windows account that has been configured for anonymous access. The default assignment for this account in IIS is the IUSER_MACHINENAME account, but you can—and typically should—reconfigure this to point to a domain account. Now it’s time to step back and view WSS security programming at a higher level. The WSS security model often forces developers to differentiate between Windows identity and WSS user identity. This might not be so obvious within a request where the current Windows identity and the current WSS user identity both point to the same Windows login. However, in scenarios that utilize FBA, things get a bit more complicated. For example, the WSS user identity could point to an FBA user named Andrew while the underlying Windows identity is based on the IUSER_MACHINENAME account. As your code attempts to access WSS objects, WSS runs access checks using the user’s WSS identity. And as your code at-
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.