http.sys Kernel Driver and aspnet_filter.dll

Before getting started into creating the most secure MOSS or WSSv3 site that we can, it is prudent to firstly understand how SharePoint processes the relevant requests that it is handling and serving to external clients with an internet facing, as well as an internal site.

When an initial request is made to SharePoint, it is possible that the request actual never makes it to have been parsed by the ASP.NET handler that will push out the relevant SharePoint page. The first layer of permissions processing that SharePoint will handle are those that are given by the Windows kernel, gaining support from that substance of the HTTP driver that will ultimately serve the request through the relevant pipe. This HTTP driver is known as http.sys which is the primary handler for the SharePoint request, and has some mechanisms that deal with information handling and serving that help to protect the overall server environment.

The first of these is minimizing the request throughput in regards to URL length that can exist within a SharePoint URL. Although it is relatively common within a SharePoint URL for the URL name to become lengthy, the overall URL and its associated request assets size may never exceed 16k, the path segments can never be above 255 segments, and the length of a specific segment should not exceed the length of 260 characters, although this is a rather generous size in any respect, particularly if you have taken the time to carefully name your SharePoint sub sites correctly. The actual body of the request is not handled at this point, rather it is handled by ASP.NET. In any respect, hitting this type of restrictions is atypical within a common SharePoint environment, however keeping them in mind will ensure that your uses have the most fluid and consistent user experience and your application architecture doesn’t subjugate itself to undo service downtime. This comes primarily into play when developing custom applications and WebParts that leverage the SharePoint framework that may implement query string values. When developing the specific WebPart, is important to keep in mind that the amount of characters that exist in the WebPart query string do not exceed 260 characters otherwise the kernel mode restrictions will come into play.

There is a good purpose behind this restriction type. Several types of attacks that may happen against a SharePoint environment take on the role of appending various characters against the overall URL structure, by which it would allow arbitrary commands or code to be executed on the server. As well, if a malicious user where attempt to try various types of these attacks against the SharePoint server, it would result in possible service disruption as SharePoint struggles to serve the malformed user request. In order to track these malicious requests as they happen against a SharePoint environment, it is best to maintain active study of the HTTP logs so that pertinent addresses can be blocked if necessary (i.e. booted attempts). This log exists with all the rest of the IIS logs in the system 32 log directory, and will give you all the GET requests that may have been malicious towards your SharePoint environment.

Once the kernel level checks are done on the request from the client, it is time for ASP.NET 2.0 to begin handling the request, since this is the underlying basis that SharePoint is built on. This is handled by aspnet_filter.dll, which is also known as the ASP.NET worker process routine. This is kicked in following the whatever other ISAPI filters are placed on the IIS virtual server outside of the ASP.NET runtime ISAPI extension, which, in the current version of SharePoint as opposed to previous versions is fortunately none. The important concept to grasp however is that the kernel mode HTTP driver is the first level that is subjected to the request.

aspnet_filter.dll is the following section that is implemented after the request has passed through the kernel mode driver. This happens before managed code is executed. The aspnet_filter is responsible for two main actions, protecting those directories that are under ASP.NET supervision, and translating cookie less tickets into HTTP headers. The last of these is very important, since cookies less tickets are imperative for session state functionality. The other is protecting the directories that are managed under ASP.NET, which is related to the cookie less tickets since it happens after the ISAPI filter processes those tickets. The URL that a user request will be processed, and if it stats a certain directory that ASP.NET deems as protected, such as: /bin, /app_code, /app_data, /app_globalresources, /app_localresources, /app_webreferences, or/app_browsers, IIS will take over and return an error to the user.

Share

Item Level Security Model (ILS), Securable Objects (SO), and Content Structure (SharePoint Site Definitions, Lists, Features, and Solutions)

One of the largest causes for complaints in previous versions of SharePoint was the lack of Securable Objects (SO) that existed only allowing end-users the option of securing items at the library level. Within SharePont 2007, this concept of Securable Objects is exposed and allows end users the option to bind a specific identity to a specific object. There are several different objects within MOSS that are allowed as securable procuring an environment that allows a very granular level of permissions:
  1. Web (Site)
  2. Library
  3. List
  4. Item
Therefore, a user can come into a site and bind identities to any of these arbitrary objects. For example, consider the following scenarios. There are several OOB permission levels that exist:
Permission Level Permission Level Description
Full Control Has full control.
Design Can edit lists, document libraries, and pages in the Web site.
Contribute Can view pages and edit list items and documents.
Read Can view pages, list items, and documents.
Limited Access Can view specific lists, document libraries, list items, folders, or documents when given permissions.
Approve Can edit and approve pages, list items, and documents.
Manage Hierarchy Can create sites and edit pages, list items, and documents.
Restricted Read Can view pages and documents, but cannot view historical versions or review user rights information.
SharePoint however allows you the option of divvying these up into groups, that you can use to more easily manage the access that is granted to your site. These groups follow the concept of AD groups in terms of aggregation, but are vastly different in functionality since they are exiled to exist at the SharePoint level. When using Secured Objects, you can optionally bind a group instead of an individual person:
Permission Level Permission Level Description
Approvers Members of this group can edit and approve pages, list items, and documents.
Designers Members of this group can edit lists, document libraries, and pages in the site.
Hierarchy Managers Members of this group can create sites, and they can edit pages, list items, and documents.
Quick Deploy Users Members of this group can schedule Quick Deploy jobs.
Restricted Readers Members of this group can view pages and documents, but cannot view historical versions or review user rights information.
Members Use this group to give people contribute permissions to the SharePoint site.
Owners Use this group to give people full control permissions to the SharePoint site.
Visitors Use this group to give people read permissions to the SharePoint site.
NT AUTHORITYAuthenticated Users Windows builtin user groups which represents authenticated users.
Each of these will have an association by default to the permission levels mentioned before that are rolled out by default. This allows the structure of a typically environment to be setup initially with little or no work.
SharePoint Group/Permission Level Full Control Design Contribute Read Limited Access Approve Manage Hierarchy Restricted Read
                 
Regular website                
Approvers         X X    
Designers   X     X      
Hierarchy Managers         X   X  
Quick Deploy Users         X      
Restricted Readers         X     X
Members     X          
Owners X              
Visitors       X        
NT AUTHORITYAuthenticated Users         X      

Scenario of Multiple Users and Item Level Security

We have two users, user A and user B, both heavy users of our collaboration environment running MOSS (SharePoint 2007). Both of these users are in different divisions and geographical disparate locations, user A is a member of the marketing group, and user B is a .NET developer, however the have been merged into a project group who is going to develop a custom SharePoint WebPart for reporting on marketing trends with regression analysis. The site is setup with the following SharePoint assets:

  • An announcements list for important project announcements
  • An event list for team building events
  • A task list for overall project tasks
  • Two document libraries, one for functional design specifications and the other for performance reports for management metrics
In order to orphan this site from the rest of the collaboration environment so only the users that need access to it can get to it, in the current context, user A and user B will be the only people to access the site, therefore we can either make a group for them and add them to it after assigning the appropriate permissions, or explicitly add them as users, with certain permission levels, to the site.

Afterwards, there are sensitive materials that are being placed into the collaboration environment, notably things that the developer might not need the marketing group to see, and things that the marketing group may not want the developer to see. Recall that there are two document libraries in the site, one for development functional design specifications and another for performance reports that the marketing department as the project sponsor are going to submit to management regarding the work done by the developers.

In the development document library, we are going to detach permissions from the parent so that unique identities can be bound to the library or object in the document library. For a functional design specification, there are typically two versions that developers have, one is “sanitized” and another is “dirty”. Dirty functional design specifications are usually what developers use between them selves since the linguistics in it may be past the comprehension of the client, therefore, we would bind the unique identity of this document by selecting “manage permissions” of the object and setting it to the developer’s account. Firstly, select the appropriate manage permissions link from the context menu of the object in order to bring up the “Permissions” page which will allow us to breakdown and assign permissions at a very granular level.

 
Site Definition and List Breakdown Structure
Site definitions (STS and MPS, along with the SPS prefixed definitions) were the most typical way in WSS 2.0 to provide flexibility and control over an entire site, from design to WebPart provisioning through the ONET.xml file. Site templates, although manually heavily to make modification to either the ASP.NET WebForms or relevant XML files were the most beneficial option in terms of performance, and give power over the overall feel and functionality of the site. Those that have worked with these before know of the pains of working with CAML (Collaboration Application Markup Language), in terms of validation and testing modifications and enhancements, and the repetitive changes that are needed to promote uniform branding across relevant files.
The Two Largest Differences in MOSS
The two largest changes to the concepts of site definitions are the introduction of features and solutions, each which serve a very different purpose, making SharePoint site developers lives much easier. In order to create a site definition in WSS 2.0 it was often necessary to copy the complete site definition file, i.e. making a copy of the STS folder and renaming to something more relevant to your project task, and then making a new WEBTEMPS.XML file that would allow SharePoint to become aware of the new directory in order to populate it to the templatepick.aspx page. This causes the creation of an entire new site, and therefore a fair amount of work to complete the task of creating a new site. The introduction of features cuts down on the amount of work needed for a developer to introduce changes into the SharePoint environment by componentizing packages to push against a site. Developers will be comfortable with the environment of a feature, since it highly resembles that of a site definition with the similar file formats, XML files based off of CAML and ASP.NET WebForms. Instead of having to create a new site definition however to create a list template, or make modifications to the default WSS site directory, features allow you to package one change, and deploy that change to single, or multiple sites depending on your requirement.
The Old Way Of Doing Definition Switches
Many people are aware of the trick to switch a site definition by making the modification to the Site ID in the _SITES database in order to convert an existing site, which carries its own implications since it is not a supported Microsoft technique and is not always 100% effective. Features however solve this paradigm by allowing you to apply them for an existing site, on any site that exists within a farm. The method of deployment can vary depending on requirement, however can be done through:
  • Command Line
  • Code
  • GUI
This obviously has implication in how development of site definitions should be structured and planned, since features can be referenced across a farm from any site. List types can be spread and referenced from differing sites, therefore allowing a container of reusability and cutting down on the amount of work required for a developer to make sites and site collection that are more intelligent and tiered towards business purposes. As a developer, this is a must have feature that has immediate ROI. Typically, to make new types the process described above (copying the STS site definition etc.) is needed if you simply want a new list type, however leveraging the WSS 3.0 allows you to solely develop a singular features without having to make new definitions, and extend these references to the feature throughout differing portion of the farm.
Deploying New Site Definitions
Developing and deploying features is not that different than creating new site definitions, so should be familiar to those who have created site definition in WSS 2.0 (besides the introduction of the 12 hive). Features in WSS 3.0 are created by creating a folder in
C:\Program Files\Common Files\Microsoft Shared\web server extensions \12\templates\features
When you create a new folder, you can place all the relevant features files that you wish to include, however the one file that MUST exist is the feature.XML. The feature.XML file is the basis for the entire feature, providing the structure of the feature by exposing base properties and other supporting features. Within the feature.XML file, you can point to other relevant assets that will build up your aggregate feature, such as rendering resources or assembly files. Your feature file can also only contain the feature.XML file, depending on the requirements of your project and what type of logic is needed in order to complete the requirements of your feature.
Breakdown A Feature, and Then Build A New One
Features are really easy to dissect because typically unless it is a very intensive feature the amount of files that exist within them is very, very small. As mentioned before, this may be just the feature.XML file which is the only file that is actually required for the feature to be implemented within the SharePoint 2007 environment. Provisioning this file out into your environment as described above is rather easy and unproblematic, and can be done in a variety of fashions depending on user preference.
Before you get started writing the feature though, it is best to define who exactly you are tailoring to write the feature for! Is it for a site? Is it for the whole server to be able to active? (Remember, this is going to be available for users throughout the SharePoint GUI so it is best to plan the feature scope.
There are four main kinds of scopes that exist in relation to features, Site, Site Collection, Virtual Server, and Server Farm. The differences should be rather apparent; however for the sake of being complete, here is a little breakdown.
Assume you are developing a list feature that establishes a different type of view that applies to a product inventory list within your company. This feature doesn’t have much application in relation to other sites since this list really only exists at one site within your entire environment, most likely on your inventory management site (or site collection, which we will get to in a minute).

Solutions, Site Definitions, and Features

The other major change that exists within site definitions is that of a solution, whose structure should be very familiar to WebPart developers. The idea of a solution replaces that of using a .CAB file (deployed typically using the wppacker method) for a WebPart deployment, and extends the possibility of packaging other SharePoint assets such as site definitions. So why should the structure be familiar? Within WSS 2.0 a WebPart typically had a manifest file, and .dwp, and a related assembly that acted as a container of business logic. The .dwp played the role of establishing the connection between the presentation layer and the assembly describing things such as Title, TypeNames, and Assembly Names. The manifest handled many roles most importantly that of making the safecontrol entry into the web.config file so that the WebPart could actually run correctly. Within a solution, the same context of using an XML file within a .CAB solution which can describe the package and method of unpackaging and delivering the assets onto the server. Typically however with WebParts, the wppacker method had to be run to drop the assembly and relevant assets onto the front end web server. This is no longer the case, since the WSS 3.0 as described in other sections is more dependent on the database for storage of assets that would otherwise be stored in other location in WSS 2.0. When the solution is deployed onto one of the servers into the farm, it is housed within the configuration database, after which a job is tripped which will deploy the WebPart to the remaining front-end web servers that exist within the SharePoint farm.

Auditing List Changes With A Workflow

A common requirement within a collaborative environment is to implement a workflow for critical assets to be routed and intelligently automated throughout an enterprise. More often than not, this is a Microsoft Office document of some nature, and in most businesses this is typically a Microsoft Word document. Encompassing certain documents and tasks within a defined and standardized process is something that is typically a largely manually task, often resulting in redundant information being sent to both parties. This process could also be largely housed within persons head, not transparent to the rest of the parties involved in the business processes, and therefore remaining loosely defined and subject to several mistakes.

Windows Work Flow Foundation (WinFX/.NET 3.0)
WSS 3.0 however solves this common dilemma by introducing new technology called Windows Workflow Foundation (WinFX) which forms a basis of methods at a workflow developer’s disposal to build intelligent foundations to automate these business processes. There are all types of workflows, which break down further when examining how the workflow is supposed to be structured around the human element. The two workflows that are supported on the WSS 3.0 platform are sequential and state machine workflows, both of which can be tailored around arbitrary business processes, however the latter being well-suited or tasks that largely involved a human element. Sequential workflows are like a software development lifecycle; you define requirements, build the software, test, and go production with the push build. It builds a series of events up that in turn will happen one after another, executing when one event expires. A state machine workflow exists on different states, an event may occur is a certain state is adjusted whereas that same event may not occur, establishing a grey area and therefore the introduction of the human element.
Using a workflow within a SharePoint site can be extended in many different fashions, such as on a document that exists within a document library or on an item that exists within a list. One of the most typical processes is an approval routing workflow, whereby a document is sent between different parties to achieve signoff until it hits executive signoff to end the workflow. This can be routed in multiple ways, through serial, where a document goes one by one through a workflow route or through a parallel (also known as shot gunning), where the approval is sent to multiple parties or signoff after an event is tripped. Assume that there is a sales document that has to go through multiple parties, originating at the sales department, but going through the graphics department for design, marketing department for corporate conformity checks, financial department for verification of metrics and statistics of the document, and finally getting executive sign off before the document goes production. This is an example of a serial route, where the document will be routed to each department in a single step fashion, getting sign of until it reaches executive management where the final threshold of the workflow is satisfied and the cycle ends.
The built in workflows when first using WSS 3.0 are fairly rudimentary, however let you explore the options that are available when exposing Windows Workflow Foundation since they are built upon the same technology. One of those workflows is the example given above, setting up an approval route on an arbitrary document that you wish to route through your company in a fashion that you deem appropriate based on the given requirement.
Workflow Across Relevant MS Sister Server Systems
SharePoint by design has always had the ability to integrate with sister server platforms offered by Microsoft, and Windows Workflow Foundation provides the same types of facilities. Because Microsoft Exchange has close ties with how workflow functions within a company, it also provides the hooks so that the workflow can be integrated across relevant client applications. This extends further to the entire 2007 Microsoft Office suite, allowing you to build workflows intelligently integrated directly into your office applications.
Windows Workflow Foundation Run-Time Engine
The heart of SharePoint workflow is run by a component known as the Windows Workflow Foundation Run-Time Engine, the same entity that is responsible for the generation of workflow elements as they exists within the entire WinFX engine. The reason that there is one entity that is the heart of WinFX is that it is specifically built to keep active during periods off activity that other programmatic elements might have trouble surviving in, such as when your SharePoint server reboots. In essence, WinFX plugs into SharePoint similar to a puzzle piece, there are two sides of the equation that are unique to each other but they have common sides that are provided by both ends. The workflow however is the base piece, it is the base engine whereas SharePoint is the higher level functionality that plugs into this workflow to implement its own custom routines. It is possible to mimic this type of functionality through the SharePoint API and exposing programmatic elements as thus, so you are not restricted to building just one type of workflow to conform to a SharePoint standard. This is my task right now!
Fortunately, creating these workflows is easy through the Visual Studio 2005 interface, there is even a visual designer that cuts down significantly on the programmatic effort that is required to do so.
Share

SharePoint MySites and Pluggable Authentication Providers

Introduction To Problem with MySites and Pluggable Authentication Providers
A problem that people commonly encounter in a SharePoint site that they are facing externally on a perimeter is they want to use SharePoint MySites, however also want to implement a pluggable authentication provider that will allow them to give their external users easy access to the environment. The problem that arises is that when you implement pluggable providers, the MySite control that normally appears in a default sites:

< SharePoint:DelegateControl ControlId=”GlobalSiteLink1″ Scope=”Farm” runat=”server” id=”DelegateControl1″/ >

(why it wasn’t given a friendly name, I am not exactly sure)

will disappear when you install the pluggable provider and navigate to the default instance of your site.
This is a large problem for persons that want to implement MySites in SharePoint for a perimeter facing deployment that will allow customers to have their own little space. Although when you implement forms based on your portal the problem is not immediately resolved by the system, it is relatively straight-forward, simple fix that requires a little text editing and the bulk of the labor done through various SharePoint GUI’s.

On the good end, this was a larger problem without the concept of pluggable providers as provided because it typically required the users to be added into the local domain or for local users accounts to be added to the server in SharePoint 2003 which tended to be a user management nightmare and complicated the Active Directory forest.

Analysis of the Problem and The Proposed Solution
The reason that the problem arises is because by default you are going to have two config instances that exist that are going to look their own authentication routines, each acting as you specify it to. If you enable the sqlmembershipprovider and implement Forms Based Authentication on your core SharePoint site this is only going to effect one configuration element, what about if other application elements exist outside of your primary SharePoint web application?

As an example, let’s assume that there are two web application instances that exist in your environment, one with Windows, and another that exists under your FBA routine that resolves to the default SQL membership provider, so it would look like the below:

This is, in essence, is what you get by default when you solely implement a membership provider on your main SharePoint site, so in central administration you have made the changes for only one web application, and specified for external users that they can use the SQL membership provider (we are ignoring the concepts of Zones and AAM right now since we are only examining the overlying problem that is encountered). You can see that your mySites are generally pointing to a different web application in your at _layouts/PersonalSites.aspx or navigate to your SharePoint Service provider through WCAM and then select “My Site Settings”.

In the image referenced above this is demonstrated, two different web applications, one is your main SharePoint site and the other is your mySite, each using a different authentication routine to resolve itself, Web Application 1 is using Windows Based Authentication, whereas Web Application 2 is using Forms Based Authentication. In this scenario, Web Application 1 will have the MySite link available, whereas Web Application 2 will not have the MySite link available.

The evidence for why your are not seeing this link should be becoming more clear, and even has a formal definition (at least in multi-access security models)!. It is called in multi-level, MAC based environment, with various sensitivity label providers (for a brief introduction to MAC and sensitivity labels select here), “Cross-Provider Clashing”. When there are multiple applications that have inherent dependencies on the security routines that are provided for environmental, not local, cross-application stability, the inherent provider store must remain aggregate and assimilated by all the inherent assets. Meaning, if you are using forms based authentication with a custom authentication provider on one web application that provides security trimmed functionality to another web application, you MUST used forms based authentication with the same authentication provider for those related web applications, if you indeed do wish to to share those security trimmed objects.

How Can I Accomplish This?
Solving this problem is as simple as implementing Forms Based Authentication, even less so since the backend data store has already been setup. Seeing as that if you have run into this issue, you have already implemented a custom provider of some sort, you simply have to follow the same steps that you did in the other web application that is housing the other content that is cross context, and then make some changes to some administration sections in WCAM and WAT. So, both web applications that you have should use the same provider:

To do this:

1) Navigate and open the web.config file of both of your web applications (the less labor intensive way to find them and negate having to figure out the GUID’s is to open up the IIS MMC snap-in, select the virtual server, and select “Explore”) and make sure that the connection string and provider settings are identitical since you will be using the same provider for both your SharePoint Web Application and MySite Web Application (and as a best practice you should be encrypting your connections strings as detailed in my TechNet article here).

2) Open up SharePoint Central Administration (WCAM) and ensure that both of your web applications (core SharePoint Web Application and your mySite web application) are set to use forms authentication, this is done by navigating to Central Administration>Application Management>Authentication Providers which should place you at _admin/authenticationproviders.aspx. This can optionally be configured by manually editing the < authentication > < forms > elements in the web.config file, either way the end result will be same. Ensure while you are in this screen that the membership providers are identical that you have configured previously in the first step of the solution. If these is not the case, set them now to the custom provider and check the settings in the web.config for sanity purposes and to eliminate possible issues during the remaining configuration steps.

3) Following, you are going to have to change the site collection administrator settings, because there are both primary and secondary options here it is of no concern so a normal user account / service account can still retain some management options. Firstly, you have to change the site collection administrator of both sites (it is important to make this change for both of the site collections) to the admin user that you created in WAT (Web Site Administration Tool), for a better overview of the WAT tool select here. You should also add the ASP.NET admin account as an administrator in the Shared Service Provider. This can be done through the command line:

stsadm.exe -o editssp

        -title

        [-ssplogin ]

        [-ssppassword ]

        [-ssl ]

or you can optionally achieve it through the GUI by navigating to Central Administration>Application Management>Manage this Farm’s Shared Services>the SSP you need to change>Edit Properties>SSP Service Credentials.

In essence, this administrator account should become a secondary service account to those which you used when setting up the SharePoint implementation, and as the administrator will become your crutch account for troubleshooting administration issues as they arise.

4) RUN an IISRESET /noforce and your link will appear and be fully functional.

Is This A Bug?
This is in no way a bug, and I would imagine that Microsoft designed this flow to act as it does. To expect the option for an authentication provider to immediately blanket the rest of the provider settings would take away from the pluggable architecture that is introduced in this new version of SharePoint. Although it does require due diligence of the SharePoint administrator to really look at the changes that they are making to the authentication providers for all web applications, it ensures that your users are having the exact entry experience that you design them to have.

Share