MSDN Magazine - February 2008 - (Page 54) Many of the programmatic aspects of the SharePoint security model are exposed at the site level through SPWeb objects. This is the case if you want to discover which users are members of the current site. An SPWeb object exposes three different collections of users, as shown in this code fragment: SPWeb site = SPContext.Current.Web; SPUserCollection c1 = site.Users; SPUserCollection c2 = site.AllUsers; SPUserCollection c3 = site.SiteUsers; Figure 1 PeoplePicker Control ing external principals and configuring permissions. The high-level design of WSS intentionally isolates each site collection so that a user’s security settings in one site collection do not impact permissions or access control policy in another site collection. The WSS object model represents external security principals using SPUser objects. You can retrieve the SPUser object for the current user through the current SPWeb object: SPWeb site = SPContext.Current.Web; SPUser user = site.CurrentUser; string DisplayName = user.Name; string Login = user.LoginName; string EMail = user.Email; string User Notes = user.Notes; The SPUser object exposes properties of an external security principal, such as login name, display name, and e-mail address. These properties are usually retrieved from an underlying user repository, such as an Active Directory domain, when What may be confusing the external principal is is that SPUser objects added to a site. The SPUser do not always represent object also exposes properties that track WSS-speactual users. They can also cific metadata, such as the represent Active Directory Notes field. groups and ASP.NET roles. WSS maintains the profile data for external users, groups, and roles in a hidden list, which is known as the User Information List. Every time WSS provisions a new site collection, it automatically creates the User Information List as a hidden list in the top-level site. WSS then adds a new profile for each external principal the first time that principal is assigned permission or the first time it passes a security check to access a securable object. Note that the user profile stored in the User Information List does not extend across site collections—when users update their profile settings in one site collection, there are no changes to that user’s profile settings in other site collections. Another potential source of confusion is that SPUser objects do not always represent actual users. SPUser objects can also represent Active Directory groups and ASP.NET roles. WSS tracks a profile for each of these external principal types in the User Information List along with the profile data for external users. 54 msdnmagazine Office Space The Users collection has the smallest membership of these three collections. This collection includes all the external principals that have been explicitly assigned permissions within the current site. The AllUsers collection includes all members of the Users collection, plus external users that have accessed objects within the site using implicit permissions through group or role membership. For example, imagine a user named Brian with the login of LITWAREINC\BrianC that has never been given explicit permissions to access a site and view a particular list. However, he might still be able to view the list because of his membership within an Active Directory group that has been configured with list view permissions. When Brian first accesses the site or one of its objects (say, a list using implicit permissions), he is added as a member of the AllUsers collection, but he is not added as a member of the Users collection. The SiteUsers collection is an aggregation that combines membership for each AllUsers collection within the current site collection. The membership of this collection includes all external principals that have been assigned permissions to any object within the site collection as well as all external users that have been granted access to any of the site collection’s objects using implicit permissions. So how do you create a new WSS user profile for a user that has authenticated using an Active Directory account? If you need to create a custom user interface component that allows standard users or the site collection owner to select a user or group from an Active Directory domain, you really should learn how to use the PeoplePicker control (see Figure 1). This is a handy, reusable control type that ships with WSS. You can add this control to a custom application page or a User control using a control tag that looks like this: Adding Authenticated and External Users In this sample, I have configured the PeoplePicker control by assigning the SelectSet property with values of User, SecGroup, and DL. These SelectSet settings configure the control to allow the user to select and resolve a user, group, or distribution list against Active Directory. You can programmatically access the PeoplePicker control properties to retrieve the associated login account names for the underlying accounts after the user has selected one or more security
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.