Security in MOSS2007 can be simple or it can be complex depending on the business requirements and the security needs of end-users and site owners. The benefit/advantage in using MOSS2007 is that you now have greater flexibility and control to manage access to your content. Along with that can bring more complexity and a greater responsibility for the user managing those permissions. I will provide a general overview and description and then discuss the security model I have used in almost every SharePoint project I’ve implemented. Security for SharePoint can be complex because unlike before, we can break it down, break it apart, and apply it at a granular level. This couldn’t be done in previous versions of SharePoint but has now been added as a new feature in MOSS2007.

Setting Permissions Down to Item Level.

If you go to a document library, and then click on the document and click the dropdown menu or Edit Control Block (ECB), you will see listed in the menu “Manage Permissions” whereby you can set unique permissions for that item. This would break the permission inheritance from the library and you would then be customizing permissions for that item. Customizing means that the permissions applied are different from the object or container above it and can be different from any other part of SharePoint.

This leads to the main premise behind a typical security model in MOSS2007. You either inherit permissions from the top or you create your own custom permissions for your sub site, lists, libraries, or documents. If you decide to break inheritance then you’re left to manage those permissions for that object yourself. Before I go into more detail on how to manage permissions on a lower level, I will explain how security is setup at the site collection level, the root site. I will also explain SharePoint groups and permission levels. But first, we need to know the different administration levels and their assigned level of responsibilities.

The different levels of administration are as follows from a top to bottom hierarchy:

• Local Machine Administrator (Server Administrators)
• Web Application Administrator (IIS Application Pools)
• SharePoint Farm Administrator (can be different or the same account)
• Central Administration (SSP) Shared Services Provider
• Site Collection Administrator (Administration of all content – Has full control and can override all Site Owners
• Site or Sub Site Administrator Site Owners
• Libraries and Document or List Item

When creating the top-level site (root site or Site Collection - all the same), SharePoint out-of-the-box by default is setup to use three SharePoint groups for use with the three different permission levels. By default if using the Team site template SharePoint uses three groups. Depending on the site template there can be additional groups added by default. For example; the Publishing template will add five additional groups but depending on business requirements I usually don’t use all of them. I might even create a custom permission level that allows a user to create sites only. Therefore, the following groups are for all team sites that are created underneath the root site and are inheriting only those groups from the root. If the name of the Site Collection root is “Company” then those groups will be named accordingly.

• Company Owners
• Company Members
• Company Visitors

• Owners: Full Control - Has Full Control
• Members: Contributor – Can view, add, update, and delete.
• Visitors: Read - Read-Only

• Full Control
• Design
• Manage Hierarchy
• Approve
Contribute
• Read
• Restricted Read
• Limited Access(used only by SharePoint for accessing resources)

“You are about to create custom groups and custom permissions for this site. Changes to the parent groups and permissions will no longer affect the site.” You don’t need to do this! You will lock out all users and then have to customize all the different permission levels. This would be a security management nightmare.Here is a screen shot of the page that allows you to modify a particular permission level. This one happens to be “Contribute”. At the Site Collection Level you cannot modify the Full Control permission level. If you click Full Control you will see it’s shaded out. Click the Contribute link and take a look at the different permissions.

I have found some administrators customizing permission levels at both the Farm Level and the Site Collection Level. Think about the difficulty of managing permissions and creating custom permission levels at both the Site Collection and Farm Level. Not a practical solution and also not necessary.

You are using the Publishing template and you want to give a group of users the ability to create sites only. You cannot grant those users administrator rights so you need to create a custom permission level that will allow those users to create sites only.

Unless you change and customize permissions the Finance sub site will inherit permissions from the root. That is not the way it is currently setup. Based on site security requirements provided by each site owner, we are provided a list of all areas within each department sub site that required different permission settings from the root. We had to break inheritance and customize permissions to meet those needs. We broke inheritance by changing permissions for all sub sites and creating new SharePoint Groups for each sub site and then used the same SharePoint permission levels.

• Finance Owners
• Finance Members
• Finance Visitors

Remember permission levels explain above That’s correct! Done the same way but now I will explain the difference when we use Active Directory. Active Directory and SharePoint Active Directory is used to better manage groups of users. Instead of placing individual users into each one of these SharePoint groups, we have Active directory create groups for use in SharePoint.

As we all know, because active directory provides the Authentication mechanism for establishing and verifying a user’s identity, or any object in AD, but through the use of SharePoint groups we can assign unique permissions/access right Authorization to access resources in SharePoint. So we use Authentication and Authorization and we use Active Directory in conjunction with SharePoint to do both?In SharePoint the Active Directory ACL is assigned at the Site Collection level. What SharePoint does is verify the user’s identity using theAccess Control List, which by the way, is listed on the userInformationList.aspx page that is hidden at the Site Collection level. So each Site Collection has its own Access Control List and they’re not replicated from one Site Collection to another. The ACL is scope at the Site Collection level along with its policy layer that makes it an administration nightmare having to replicate SharePoint permissions to another Site Collection. Initially, all sub sites or all objects within the Site Collection inherit this ACL but this can be changed through the UI by disabling inheritance. When you Stop Inheritance SharePoint makes a copy of the Site Collection ACL where you can then modify and create your own ACL by way of creating unique SharePoint groups that can be assigned different AD users or groups or adding individual users. Implementing the Security Model The first thing we do is to request that the Active Directory administrator create the three groups for each Department sub site. This should be all planned out ahead of time and done for each sub site that will have custom permissions. We then find out who the site owners will be and request from them a list of users that are assigned to each SharePoint Group. Those users will be placed in each Active Directory group.

• Company\Finance administrators (usually just two users)
• Compnay\Finance editors (users that are allowed to modify and upload documents)
• Company\Finance visitors (All Finance users allowed access to the sub site with read-only rights)

This allows Active Directory administrators to keep control of users in each group and it makes it easier for a SharePoint administrators and site owners to manage permissions and users when customizing security for a sub site, or any other object. If a person or user is not in a particular Active Directory group you can always put them in the SharePoint group individually. At the top level the Active Directory group we use for read-only access is the “SharePoint Users” group. All Company employees that require access to SharePoint will be put into the Active Directory “SharePoint_Users” group. We then put the AD “SharePoint_Users group into the Company visitors (Site Collection) SharePoint group. That means they will only have “READ” rights because the SharePoint group Company visitors is assigned “READ” permissions. This will also apply to all sub sites that inherit from Company.

Using the SharePoint_Users group provides additional security and ensures that only those users authorized can access the company intranet. DO NOT USE NT\ALL AUTHENTICATED USERSThat’s how it works. Based on requirements we requested from each site owner:

• Who do you want to visit your site?
• Who do you want to edit (collaborate) on files (documents)
• Who do you want to manage (admin) your sub site (department site).

Example Now, it comes down to this, we don’t want to inherit the permissions from the root site and I want to create different permissions for my new sub site. This is the tricky part that requires some thought and preparation. This is where we need to plan how we apply our security and how we want to keep track of it. Keep in mind that we are dealing with containers i.e., Site Collection and Sub Sites. So if we break inheritance and apply custom permissions to a sub site, all items underneath will inherit from that sub site. But it’s simple because we are now familiar with SharePoint groups and the way groups are setup in Active Directory.

Where will my site be created? Under the root site, under a department sub site, or under another sub site several levels underneath a department sub site? This is important because depending on where my sub site is created, I will inherit those permissions from the site above me and that may not be the permissions I want to use. Then you would have to break inheritance and create your own.

If we want to create our own security for our sub site and move away (stop inheriting from root) we first need to create our own sub site (department) groups, and then apply our own permissions for each group. This is how it’s done.

• Site Actions
• Site Settings
• People and Groups
• Click Groups
• Click Settings

Scroll down and click “Set Up Groups”Click “Create a new group” We don’t want to use the Company groups, an existing group.Now we can apply our Active Directory Groups. (Using Test site as an example) If you decide to allow all users to access you site with read-only access then click the people picker and search Active Directory for “SharePoint_Users” group. This will give all those people in that group access to your site. Throughout this discussion we’ve been talking about managing permissions at site level. Now let’s talk about permissions at item level. I mention this because there is a slight difference in the way you can apply permissions. Take a look at the following example.Security requirements for the Marketing sub site Calendar is as follows:Read/Write Access = Everyone in Marketing Dept.Read Only Access = Everyone only in Marketing Dept.

So your client would like for you to provide a custom branded master page and would also like it delivered as a feature at the site collection level. No Problem! Before developing the solution you need to create the new master page. That means you need to fire-up SharePoint Designer 2010 and go through the process of creating a custom branded master page along with the files and folders required. How do you do that? Well, make a copy of the v4.master and rename it to a name of your choice. In my case, I named it jtwebnet.master like you see here. You can do this with either a Team Site template or the one I used for my Site Collection (root), the Publishing template.

Then, under the Style Library I created a folder called "jtwebnet" and under jtwebnet another folder called "images". I also created a new CSS styles sheet called "jtwebnet.css" under the jtwebnet folder. Here is a screenshot:

Work your magic ( on your development environment) and make the adjustments and tweaks required, and when your happy with the final look create a folder on your desktop and save the master page, images, and CSS file. I did it this way but you can choose to do it differently so long as you have access to those files when it comes time to adding them to your solution.

You can point the project to the sandbox or the farm and you can create this solution in either SharePoint Foundation or SharePoint Server. It will work either way because you are deploying all the required branding files using template files and Modules and the solution is not picking up any server dependencies. Take a look at the folder structure of solution.

Double click the Main.EventReceiver.cs file and add the following event handlers. Remember Syncronous/Asyncronous? Syncronous provides a blocking action to a running thread and only continues when an another action completes. Asyncronous provides action after-the-fact using another thread (two threads) for a method, or somethig like that. Ok, I'm getting off track and I'm sure I'll get mail on this one.

FeatureActivated

FreatureDeactivating

Now let's add two Modules shall we, I named them "MasterPageGallery" and the other one "Style Library". Right-click the MasterPageGallery folder and add existing file and add the master page (remember where you saved your files?).

Open the elements.xml file and add the following markup. You must add the following attributes and properties in order to correctly deploy the master page. This is the SharePoint beast! You want to know the difference between typical ASP.Net web developing and SharePoint? Well, aside from all of the many differnt methodologies and the difficulty in debugging your solutions, you need to learn Collaborative Application Markup Language (CAML).

We don't have to modify the elements.xml file under the Style Library Module so you can just add the existing files such as the .CSS file and images. Yes, right click the Style Library and add the .CSS file and right click the images folder and add existing files, IMAGES!

Before Deployment

Deploy the solution and then navigate to the home page.

After Solution Deployment

Now go to site actions and click site settings. Under Site Administration click Site Collection Features and deactivate the feature.

Now you can deploy this solution to any farm and better yet, an easier way to migrate your solution to the next version, we hope, right?

Creating custom site definitions are now a thing of the past. Microsoft now recommends using the component "Site Provisioning Provider" as best practice for providing a custom site template. This is not new and was also available WSS3.0 but instead of creating a custom site definition, we add custom provsioning code to the out-of-the-box site template.

Step One:

Fire up Visual Studio 2010 and create new project using the "Empty SharePoint Project".

Step Two:

Before you start working on your new project, open the properties page and on the "Application" tab, make sure that the target framework is set to ".Net Framework 3.5". SharePoint 2010 is not using .Net Framework 4.0.

Then select the "Build" tab and by default the platform target will be set to "Any CPU". Change this to x64. Just do it!

Right click the solution name and choose "Add" and right click "SharePoint Mapped Folder". We want to map the SharePoint root so click the very top "SharePointRoot" The solution explorer should now like this:

Step Four: Now add the following folder structure underneath your sharepoint root like this:

Step Five: Next, add an XML file underneath the XML folder like so:

The XML will contain the following provisioning instructions and it will look like this:

Step Six: Next, add a Class file and give it a name. This is your "Provisioning Provider". Add the Microsoft.SharePoint referrence and if you're a newbie, you'll find it underneath the "ISAPI" folder underneath the SharePoint "Root". What was it called in MOSS2007? The 12 Hives folder, but for SharePoint 2010 it's now called the "SharePoint Root". In Ted Pattison's "The Great SharePoint Adventure 2010"  development training course, we were told that the new SharePoint product team changed it to "SharePoint Root". Nonetheless, I've noticed that some are referring to it as the 14 hives.  Also make sure the Microsoft.SharePoint.Security referrence is also added. Build your project here. Or you can wait until you've added the code. I've gotten into the habbit of buidling my projects often, even for SharePoint.

Look at the top line. You are inheriting from the SPWebProvisioningProvider base class and overriding virtual methods to create your own Site Template Provisioning Provider.

You're actually overriding the "Provision" method of the Provisioning Provider base class. When you implement this virutal method, you can now specify custom configuraton properties by calling the "ApplyWebTemplate" method. This makes it possible to customize out-of-the-box site templates with our own customized provisioning instructions. Very cool!

During the execution of code, the out-of-the-box site template is created through the "ApplyWebTemplate" method using the "Blank Site" template "STS#1". The rest of the code is added to provide the required site elements for the custom site template.

Again, build your solution. Then deploy it like this:

Your Done!

After deploying your solution and no errors are reported, you can check your new category and templates using several different ways. First, if you have "Self-Service Site Creation" enabled, and I hope you don't, you can click the link "Self-Service Site Creation" under "Annoucements" on the home page.

Then click the "http://your site/_layouts/scsignup.aspx" link and you will navigate to the following page.

As you can see, the category "JTWebNet" is listed, and underneath this category are the "JTWebNet Standard Team Site" and "JTWebNet Consultant Site" templates. You don't see an image for either template because I haven't added one to the layouts/images/jtwebnet/ folder. I chose the "JTWebNet Consultant Site" template for my first custom templated site. After SharePoint provisions the site by default your taken to the SharePoint security groups setup page where you specify which Active Directory groups are to be used. As you can see the site owner/administrator is already plugged into both the member/contributors and admin groups. After you setup your SharePoint security groups you are now ready to start customizing your new site with web parts and content.

Very easy to implement and provides a professional looking custom site template for your client. Now you can take it a step further by deleting the other categories thereby eliminating the option for creating out-of-the-box site templates. Go to site settings and click on the "page layouts and site templates" link and set the following:

If the site owner/administrator decides to create a subsite, there is only one category diplayed and only those custom template options will be available. For the farm administrator that is a different story. Although I may have always provided that customization with a custom site definition, I will not show you how to delete those categories with this solution.

Before I move on to feature stapling, I think I will post the branding solution first.

It's very easy to customize the Server Ribbon using a Feature custom action and ribbon XML. Follow these steps to get you going:

• Fire up Visual Studio and on the File menu point to New, and then click Project.


• In Project Types, under C#, select "Empty SharePoint Project".
• Type UnserInterfaceActions as the project name, Click OK
• In the SharePoint Customization Wizard, select Deploy as a sandbox solution. Click Finish.


• In Solution Explorer, right-click the UserInterfaceActions project, select Add, and then select New Item.


• In the Add New Item dialog box, select the Empty Element template. Enter UserInterfaceActions as the Name.


• Open the Elements.xml file and add the following xml markup.


• This is the final solution!

This is very simple but demonstrates how you can modify the Server Ribbon and add custom actions. To learn more about the Server Ribbon in SharePoint Foundation click here.