There are numerous ways of setting up and securing your MOSS environment from server hardening to IPSEC and SSL.  Going through all of these  are not the focus of this article.  However this article will go through an overview of Moss.  Next I will go into the security model, give an overview of the permissions and how they operate, including touching on what’s new.  I will provide you with a matrix of the permissions, permission levels and groups to help you plan your security options.  Then I will give you details on how to customize permissions and break free from the default permission inheritance.  Then I will go into how all that we have gone over will affect workflow, including starting, participating and reporting.  Then I will provide some wrap up and summary to ensure a complete picture is had.

So What is MOSS

 “Microsoft Office SharePoint Server 2007 is the successor to SharePoint Portal Server 2003 which provides  server capabilities such as comprehensive content management , enterprise search,  and collaboration.  MOSS also provides professionals and developers with a solid platform to take advantage of and build MOSS based applications or extensions.

What’s new in MOSS from a security perspective? 

Good

1.       Better 3 Tiered security Model

2.       New more extensive permissions.

Better

1.       Central administrators no longer have full access to content.  (however they can take ownership, but then would be audited and logged)

2.       Rights Masking.  Administrators can remove certain rights from even being available to site administrators to grant. Such as “Manage Alerts”

Best

3.       Security Trimmed user interface.  If you don’t have rights you don’t see it!

4.       ITEM LEVEL GRANULAR ACCESS

To better understand security in MOSS let’s talk about the basic security Model that makes up MOSS.  MOSS now has a true 3-tier administrative model.  This is going to make things easier for organizations to separate portions of administration and roles.  The 3 tiers are 1. Farm Administration 2. Shared Services administration and 3. Content administration.  As shown in (figure 1)

Overview of MOSS security Model

Figure 1.

The Layers

Farm Administration

Those who are in this role are responsible for the maintenance of all servers that make up a designated farm.  Members of this group have the rights to perform all tasks in the Central Administration website.  It is important to note that this group will not have access to the sites or the content inside them by default.  However it is possible for members of this group to obtain these rights through the administrative interface by adding themselves as a site collection administrator.   However this action will be audited and logged and provide for a evidence trail if this access was inappropriately used.  Another important note for farm administration is that by default the local administrators group can perform all administrative tasks and more including deploying new applications, or web parts, and, creating additional web applications. However as with Farm Administrators they have no access to content without explicitly taking action.

Shared Services and Shared Services Providers(SSP):

First off what is SSP?

•  SSPs are for managing a set of services such as  searching and indexing, my site hosting, Usage Reporting, Excel Services, and Business Data Catalog Configuration
• The SSP administration interface is a Site
• An SSP by default is a separate web app from the other web apps extended with SharePoint Technology
• SSP administration is not available with WSS

SSP administrators  can control which services are included in a Shared Services Provider (SSP) and configure settings for those services. Example tasks can include

·         Configurable portal usage reporting

·         Configuring permissions for specific services such as search, Excel services etc.

Content:  These are all your site collections, sites, lists, document libraries etc.

Administration at this level is made up of Site collection administrator and Site Owners: 

Site collection administrators:  Members of the site collection administrators group will have full Control permissions  on all web sites within a site collection. This means that they have access to content in all sites in that site collection, even if they do not have explicit permissions on that site.

Site owners:  By default, members of the Site owners group has the full Control permissions on that site. They can perform administration tasks for the site, and for any list or library within that site.

Keep in mind that every site collection is an island of security.  What I do in my site collection will not affect your site collection.  By default a child site will automatically inherit the permissions of its parent. Unless the permission inheritance is stopped and that site “breaks free” which I will speak to shortly.

For general site content the site administrator should assign appropriate permissions within the site to various document libraries, lists, wiki’s etc.  If the security model is such that there are people who maintain specific lists it would be their job to further restrict and maintain permissions for their various list items.  By default all lists and libraries will inherit the site permissions, however the list owner can then further restrict or open up access based on need.

Another aspect of administration and rights is the Web Application.  While the web application level does not have a dedicated “Web Application Administrators” group however Members of the “Farm Administrators” in addition to those local administrators do have the ability to define a “Web application policy” to grant people access at this level.  Be careful with granting this because adding in people in at this level does give them access to the content contained within that web application.

So how do permissions work in MOSS? Lets Identify some common security terms and concepts.

Permissions:  These  individual permissions (of which there are 33) will grant a certain ability to perform specific actions.  As an example Edit Personal  User information, this right once granted will allow the granted user to modify their own user information such as updating their picture.  In addition the list or possible permissions that can be granted can be “masked” so that they are unable to be granted to any user.

Permission Levels:  These are essentially a defined set of permissions to perform related actions.  For example the contribute level contains many rights such as Add items, Edit Items, Delete items and others.  For a complete matrix see figure x.   Similar permissions can be included in numerous levels and the existing levels can be customized to meet the needs of the environment.  However I would recommend creating new levels rather than editing the default out of the box levels.  Each of these permissions levels are also inheritable to child sites.

User:  This is a person that can be authenticated through whatever authentication provider that is available, in MOSS you are no longer restricted to AD.  These users can be assigned permissions levels by themselves or they can be part of a broader group that gets assigned certain permissions levels.  Going the group route is a far better choice. 

Groups:  This is a collection of users.  A group in the SharePoint context can be a SharePoint group such as “Site Owners” or can be an Active Directory group such as “Accounting Department”

Securable Objects – The above mentioned users and groups are going to have certain permissions levels for a specific securable object: such as a document library, a task list or any SharePoint item.  By default these permissions are automatically set to inherit from their parent site.  This can be changed however be very careful when doing this as it adds more administrative overhead.   There are some new securable objects available to administrators in MOSS they are

·         Website

·         Lists

·         Libraries

·         Folders

·         Documents or files

Getting into the permissions themselves in detail, hopefully the permission matrices in the following sections help in planning your strategy.  There some additional new permissions available to be used.

New Permissions:

Permissions to Permissions Level Matrix

One item to point out after reading these matrices is what “Limited Access” is. Limited Access is required for any user to use/view the common items that cross all we sites  such as the various navigation bars, themes etc.  This is truly the base permission level, and is fairly meaningless unless you are granted other permissions.

To summarize how permission work in MOSS You will have Individual permissions such as Manage Alerts.  Then you also have Groupings of permissions for common roles such as contributor which includes several individual permissions that are common to a role.  Then you can have Roles such as Member, Owner, Visitor that are assigned these permissions groups.  You can modify and customize these in order to effectively grant and maintain effective permissions you must first understand the permissions and when each are assigned based on the default groups and permissions levels. When planning these permissions you can use the appropriate matrices you can use to better understand this.

Now that you have seen all of the permissions, and roles and have a general understanding of how these pieces work the next item to discuss is how to break away from the default permission inheritance to set your own permissions on a specific securable object.

Breaking Away

With the heavy inheritance model in MOSS administrators need to have a way of blocking this process.  Administrators can through the use of “Breaking away” prevent the inheritance from the parent and set a new set of permissions in their securable object.  So If  I have a sensitive list or library contained in a more open site I can restrict the access to my list or even child site by breaking away the permissions from my parent and not allowing it to inherit the base level of permissions, and only have the permissions I want.  In figure 2 I have clicked on edit permissions and am warned of the effects.

Figure 2

The fantastic part of breaking away is after I break away I can easily re-join by clicking on “inherit permissions” in the drop down menu.  A great way of testing and rolling back.  As shown in Figure 3

Figure 3

How does all this affect workflow in brief?

Since workflow in MOSS is primarily List, and document library based administrators need to plan appropriately and make sure that users who will be participating in workflow have enough permissions to effectively participate in the workflows but not too many rights that they can inappropriately take action and or effect workflow when they should not(Least Privilege principal).   Administrators need to be aware of how security affects users ability to not only participate in workflow, but also initiate the workflow, create new workflows, view currently running workflow and view history reports on workflow.  One item to keep in mind is that if you are going to be using SPD or the office client integration anywhere you will need to assign the following 2 permissions to anyone that will interface in that way.

·         Use Client Integration Features

·         Use Remote Interfaces

Let’s go into some of the details about each area of workflow and break each function down.

Security for workflow participants

Simply participating in workflow can require different permissions based on the workflow type and what actions they may need to take.  However for most workflows involving the usual list or document library item.  Workflow participant should have at least the following rights

·         Edit Items

·         View Items

·         Open Items

·         View Application Pages

·         View Pages

·         User Remote Interfaces

·         Use Client Integration features –Required if doing workflow through office clients

·         Open

Fortunately the “Contribute” permission automatically provides all of these permissions which is part of the Site\Members group. However this permission level also adds a few more such as

·         Delete

·         View Versions

·         Delete Versions

·         Create alerts

·         Browse Directories

·         Use Self Service Site Creation

For this reason some organization may wish to create a specific permission level, based on a more restrictive need.  I highly recommend for at least for your confidential workflows to create your own History Lists and possibly even task lists.  As an user that can “View” items in a list I will have the access to both view the tasks that everyone is working on as well as run reports on currently running or historical workflows, even if I was not part of that workflow.  You will find it very difficult to modify the permissions on the default workflow history list. This is another great reason to have MOSS create a special list just for that workflow. See figure 4 below for a screenshot.

Figure 4

Starting and Participating in workflow

Essentially the same permissions that allow me to participate in a workflow will also allow me to kick one off that has already been associated. Weather this is from the SharePoint web interface or the office client interface  For some additional security requirements It is possible to require the “Manage Lists” permission to initiate workflow by selecting this option during association as shown in figure 5.

Figure 5

If I have “design” or greater rights I have the ability to impact workflow even if items are not assigned to me.  For example if I have these rights and browse to a workflow in process. I will be able to add additional people to the workflow, add comments, or even cancel it.  Simple contribute rights will not allow this to happen so give out design rights as sparingly as possible.  However even with full control permission I would not be able to “approve” an item if it were not assigned to me. 

Reviewing  workflow items

Members can see task items and look at their details even if they are not assigned to them.  Visitors can see the task item but cannot open unless they are assigned that work item.  Basically what this can mean is they can see what workflows are running, who they are assigned to the dates and descriptions.  In many cases this won’t mean much but in some it can, so it should be planned for.

Redirecting

Delegating or redirecting a workflow is part of the configuration options for each workflow as seen in figure 6.  When planning also be aware that the person who is being re-directed to will need appropriate rights.  So when planning the use of workflows you should plan these rights appropriately.

Figure 6

Completing Tasks

Completing one’s own can be done even with visitor rights by default.  There should be no additional rights necessary. 

Creating and or Associating New Workflow

Before one of the Out of the box workflows can be used in document library or list, that workflow must first be associated with that library or list.  However for those workflows created with SPD the association is done automatically.  In order to associate workflows you need the designer level or if desired you can use contributor level and add the additional right of manage lists.  This will now expose and make functional the workflow settings item in the list or document library settings.  However some organizations may not want to give these rights to all those that may ask for them.  It may be best in these cases to appoint a “workflow” role that can be assigned or delegated by the “Site Administrator”.  Another option is to create a custom permissions group that would include the necessary rights at not only the Library or list level but also for the site level.  This is because even if you have full control over the list or library, you may not have the rights to associative workflow with that list as this is a site level right. 

Those with the Full Control permission in a specific site or the Manage Website added to the design level can connect, and modify or create workflows via the SharePoint Designer interface.  Most organizations will place those with the need to use SPD to customize sites with the owner role.  When this is the case, you can prevent them from modifying certain document libraries or lists by modifying the permissions “Breaking Free” and not inheriting from the site.  Once this is done if they don’t have rights they will not even be able to see it in SPD.

Workflow reporting

By default even visitors of a site can access the workflow history list and run reports which are done through excel.  This is a great reason to create dedicated history lists and restrict rights to them.

Workflow Tasks

Site visitors will still be able to see all tasks, however they would not be able to open any of them to see what their contents are.  Those with member rights will be able to look through each items.  Those with contribute rights will even be available to open the task items and action them even if they are not assigned to them. 

Wrap Up

Now that you have an idea of what is required and hopefully have some idea of the permissions needed.  Will the default levels, groups and permissions fit your organization and how your users work?  My guess is that they will work as is for a significant amount of customers out there.  However their certainly are valid reasons why you would not only want to create additional permission levels but also additional groups.  As an example if I have specific workflow needs that may be of a more sensitive nature I need to make sure that only those with a need to know have access to view ANYTHING about that workflow or the data within it.  I would need to make sure that no one even had read writes to the list itself. I would also want to create a dedicated task list and history list to ensure complete security/confidentiality.

Let’s take a look at how this would work.

if you were setting up a workflow for an HR group and the content of the document and or the comments etc should not be viewed by anyone other than a specific few.  Restrict the rights on the library, create a new workflow associated with that doc library and have it create a new workflow history as well as a dedicated task list, as shown in figure 7.

Figure 7

Next take the new history and task list, break it free from inheritance and apply new permissions to it restricting the permissions.   Now you have a more secure workflow and can be assured a more advanced level of confidentiality in these workflows.

Conclusions

So by now hopefully this makes some sense to you, there are a lot of little nuances based on different situations and you security and workflow needs.  I feel that it is necessary to give a short wrap up/summary to ensure the core concept here is clear.  What this can boil down to is a few points

1.        If you have a site where you there is workflow being utilized through MOSS and there are no special security or confidentiality concerns special permissions will probably not be necessary.

2.       If you have a site where there are possible confidentiality concerns where some members of a site should not be able to participate or see information contained in some specific workflows.

3.       There are new rights that can be assigned in MOSS administrators should take some extra time to determine if the default permissions and groups are appropriate for their needs.