MSDN Magazine - September 2008 - (Page 46)

FeatureActivated executes during feature activation, and it accomplishes two important things. First, it fully enables audit logging for the entire site collection. Second, it creates a few security objects specific to the AuditingDemo solution. In particular, the code inside FeatureActivated creates two new SharePoint groups and two new permission levels that allow the site-collection administrator to add users into the roles of Auditor and Audit Manager. The ManagerWeb permission is required for users who need to adjust audit settings. Note that the code in the FeatureActivated event handler calls the two utility methods named CreatePermissionLevel and CreateGroup. The reason I wrote these was to ensure that any preexisting security objects with the same name as those being created were first deleted. Each method then creates the requested security object (permission level or group), adds it to the appropriate collection within the top-level site, and returns a strongly typed security object to the caller. The CreatePermissionLevel method returns an SPRoleDefinition object that represents the new permission level, and the CreateGroup method returns an SPGroup. Figure 1 The FeatureActivated Event Handler public override void FeatureActivated(SPFeatureReceiverProperties properties) { using (SPSite siteCollection = (SPSite)properties.Feature.Parent) { SPWeb TopLevelSite = siteCollection.RootWeb; // Turn on auditing flags. siteCollection.Audit.AuditFlags = SPAuditMaskType.All; siteCollection.Audit.Update(); // create permission levels SPRoleDefinition AuditorPermissions, AuditManagerPermissions; AuditorPermissions = CreatePermissionLevel( "Auditor Permissions", "Can view audit logs", "Read"); AuditManagerPermissions = CreatePermissionLevel( "Audit Manager Permissions", "Can configure auditing support", "Design", SPBasePermissions.ManageWeb); // create Auditors group SPGroup Auditors = CreateGroup( "Auditors", "for users who need to audit user activity"); SPRoleAssignment AuditorRoleAssignment = new SPRoleAssignment(Auditors); AuditorRoleAssignment.RoleDefinitionBindings.Add(AuditorPermissions); TopLevelSite.RoleAssignments.Add(AuditorRoleAssignment); // create Audit Managers group SPGroup AuditManagers = CreateGroup( "Audit Managers", "for users who configure WSS auditing support"); SPRoleAssignment AuditManagerRoleAssignment = new SPRoleAssignment(AuditManagers); AuditManagerRoleAssignment.RoleDefinitionBindings.Add( AuditManagerPermissions); TopLevelSite.RoleAssignments.Add(AuditManagersRoleAssignment); Note that I designed the CreatePermissionLevel method with several overloaded implementations that make the third and fourth parameters optional. The third parameter is for passing the name of an existing permission level that is used to make a copy for the new permission level. For example, the AuditorPermissions permission level is created by making a copy of the built-in Read permission level. And the AuditManagerPermissions permission level is created by making a copy of the built-in Design permission level. The fourth parameter to the CreatePermissionLevel method is of the SPBasePermissions type, which is used to pass one or more extra permissions that are then used to initialize the new permission level. For example, the call to CreatePermissionLevel that creates the SPRoleDefinition object AuditManagerPermissions passes a value of ManageWeb for the fourth parameter. This means that the new permission level is created with the same permissions as the builtin Design permission level plus the ManageWeb permission. The ManageWeb permission is important because it’s required for users who need to adjust audit settings. I will cover two security trimming techniques later in this column that can be used to display menu items to just those users that have this permission. The CreateGroup method does a little more than add a new group to the top-level site. It also adds the new group to the associated group’s collection and adds the ID of the new group into a site-level property named vti_associatemembergroup. This extra code is important if you want the new group to show up in the group’s QuickLaunch bar and inside the combobox of the Add Users page, which makes it far more intuitive for the site-collection owner to add users to the new group. Creating a Page to Support Auditing Configuration The AuditingDemo project provides three custom app pages— AuditConfig.aspx, AuditLogViewer.aspx, and ItemAudit.aspx— that were developed using best-practice techniques. For example, these application pages are deployed within a solution-specific directory named AuditingDemo inside the LAYOUTS directory. The code that provides the behavior for these pages has been written in codebehind files (such as AuditConfig.cs). The codebehind files are then compiled into the project’s main assembly, AuditingDemo.dll, which is installed and loaded from the Global Assembly Cache (GAC). The AuditConfig.aspx application page provides a user interface for configuring WSS auditing support. I added a CustomAction to the AuditingDemo feature so that users with the ManageWeb permission will be presented with a link on a site-settings page that allows them to navigate to AuditConfig.aspx: } Note that I created this custom action with a GroupId attribute value of SiteCollectionAdmin and a Sequence attribute value of 0. This is Office Space 46 msdn magazine

Table of Contents Feed for the Digital Edition of MSDN Magazine - September 2008

MSDN Magazine - September 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Cutting Edge Hierarchy ID New Features for Microsoft SQL Server 2008 Prism Data Services Advanced WPF Test Run Security Briefs Foundations { End Bracket }

MSDN Magazine - September 2008

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.