CAC Enabled Anonymous Sharepoint Sites

By: Noni Hernandez
Enterprise Architect

If you worked/have worked or plan on working within the DoD environment, security will be a subject that haunts your dreams. Not that security isn’t prevalent in the private sector, but given the nature of our work security is a top priority if not the number one priority. That being said, I have been working with the DoD’s PKI for the past few years so I am fully aware of the scope and implications of providing a secure computing environment. Recently I was tasked with bringing all of our publicly available servers to a secure standard. This involved deploying a load balanced ISA 2006 array and protecting all of our services available through the NIPRNET or commercial internet. One of my projects was securing our SharePoint farm by only allowing access through our ISA array. Normally this would be a task completed in one’s sleep, depending on the authentication model being utilized. However, being a DoD element brings on specific requirements that must be met to ensure the protection of our data. Enter the CAC, or Common Access Card, and the utilization of the DoD PKI to enforce a more secure environment.

Inherently, ISA 2006 has great support for the client certificate authentication model, but there are some constraints. The main one being ISA will only allow such a connection by querying your domain to authenticate an active member of your domain. This is perfectly fine, except for the notion of having a publicly available page with limited information, on an anonymous access model. This is where things begin to get tricky. As I stated earlier, one requirement handed down by the DoD is to secure all publicly available servers via CAC authentication. This means granting access to your public site to anyone with a valid CAC. If you are publishing your anonymous site and giving direct access to your farm, then deploying this scenario is rather simple, but you are leaving your server vulnerable to possible unauthorized access simply by giving direct access. So naturally we will need to publish this site through our ISA array to provide that layer of security. This is where I first ran into problems. If you are configuring an access rule in ISA then enabling client certificate authentication requires the user be an active member in your domain with their CAC registered to that account. If you choose to leave the certificate request on the web server and set the authentication request on the listener to ‘No Authentication’ and the authentication delegation to ‘No delegation, but client may authenticate directly’, you will most likely receive a 408/Request timed out error when attempting to access the page. I was stuck on this error message for weeks after attempting numerous combinations to make this work.

After many sleepless nights(and even worse, nightmares!) trying to create a solution to this problem, I finally came across the solution only after being requested to secure another server behind our array. So here is the method I developed to allow a user access to our anonymous SharePoint site, with the only stipulation being they have a valid CAC.

Step 1.

On your ISA array, instead of creating a SharePoing Site Publishing Rule or a Web Site Publishing Rule, select ‘Non-Web Server Protocol Publishing Rule’. Give it a meaningful name so your admins will be able to easily identify what the rule is performing, I chose ‘HQ Anonymous SharePoint Site[CAC Enabled]’. After you click next enter the IP either the individual server or the load balanced IP utilized to reach the site. After clicking next, you’ll need to click new to create a modified version of the HTTPS/SSL protocol, I named it ‘HTTPS[HQ Anon]’ to again reflect its utilization. After clicking next you’ll need to first create an Inbound TCP protocol using the Port Range 443 to 443. This is basically stripping down the methods used by ISA, i.e. compression, masking, to allow an SSL connection but still generating a proxy connection to our internal site to protect the data. After clicking OK, you’ll need to do the same thing and create and Outbound connection with the same parameters, this will allow the client certificate request to be passed back to the end user for a successful handshake. After clicking OK and then Finish you should see your new protocol in the ‘Selected Protocol’ dropdown list. Click Next and select the network that will be listening for these requests, most likely ‘External’ and then click the Address button. Since I am using a load balanced array I already have a VIP ready to be utilized for this published site, so I choose ‘Specified IP address..’ and then select the IP I will be using to publish this site and then click Add so this rule is only answering requests sent to this specific IP. After you select the IP and click OK, click Finish to complete the creation of the rule.

Step 2.

After you have created the rule, double click the new rule to view the properties. Click on the ‘To’ tab and change the ‘Request for the published server’ setting to ‘Requests appear to come from the ISA Server computer’. Once you have verified all the settings are correct from steps 1 and 2 then click ‘Apply’ and ‘OK’. This should conclude the ISA configuration portion!

Step 3.

On your SharePoint farm, you’ll need to open the IIS settings and then navigate to your anonymous site and view the properties. When you have the properties open, navigate to the Directory Security page and then click Edit on the Secure Communications section. Here you’ll need to select ‘Require secure channel’, ‘Require client certificates’, and then ‘Enable certificate trust list’. Click New to create a new Trust list, click Next and then click ‘Add from File’. You’ll need to select the DoD Root CA 2 and I have also set DoD CLASS 3 Root CA from where you have these certificates stored. Click next and then give it a name, i.e. DOD CTL, click next and then Finish. After clicking OK all the way through to the Directory Security page of the anonymous site properties, you are done!

So as you see, it’s really not a complicated process. But in the grand scheme of things, we all know that we tend to over think and over complicate things to engineer solutions. I am more than guilty of this, I lost weeks of sleep to prove it! This configuration guide is set on a pretense that you do have some preliminary items configured, and that you reached the dead end at the same point I did. If did not being to lose your hair because of this, and have just begun your descent into madness, then you need to know that there are some steps that should be completed before reaching this stage.


Thank you Noni for agreeing to write this post! I think everyone will agree this is a valuable contribution to the DoD – SharePoint community!


SharePoint Recruiters Shouldn’t Suck At Their Jobs

Generally that is what I am discovering is the case, however terse that may appear. I normally don’t peruse recruiter sites, except I got this outlandishly awesome job offer housed in one. Before I knew it, I was searching for absolute randomness on the site for fun. As I was browsing for SharePoint jobs, I established what looked to be the average SharePoint job ad, and I chuckled a bit.

I will in fact copy and paste it directly from the offered advertisement text:

SharePoint Programmer / Developer / Architect: Must have at least 7 years practical work experience in C# with building solutions on top of SharePoint. 7 years Java experience to support conversions of J2EE to .NET solutions. To support this role, 5 years of Oracle and Delphi experience preferred. 5 years experience required with MFC/ATL and Crystal Reports.

Must have 5 years of deep architectural experience with building large SharePoint farms, and administrating them in the same capacity including deployed custom development. Several years architecting and developing against ISA and MIIS preferred and encouraged, however not required.

Interestingly enough, on recruiter sites you are able to spot precisely when the job was posted. The antiquated date appended to this made sense to me since this particular position has been open for over half a year, borderline 8 months. And I will wager that no sensible applicant has dared to apply to this gobbledygook.


Because not only does the ad undoubtedly convey that the posting recruiter did inadequate technical research because of the erroneousness of technical dating (which offends job seekers btw), but they must be looking for the fabled nine armed, four brained mythical programmer that they prophecies foretell of, because for all intents and purposes those requirements are outrageous.

First, let’s pick apart the ad.

7 years of C# development experience, while being feasible, is marvelously atypical since the establishment of the C# language in common commercial markets is roughly in late 2000. So, this organization is most likely looking for a C# beta tester for when Anders Hejlsberg was still calling it code name Cool. Needless to say, this would be exceptional and uncommon.

7 years of .NET development on top of SharePoint I can see being a qualification, if STS (2001) development actually used .NET. Then it would be cool. But it didn’t. So the basic arithmetic of the recruiter sucks. Even then, you would be subject to the same time considerations as described above, making it not necessarily common.

5 years experience with MFC/ATL? Huh? I mean, I did MFC / ATL programming for a long time (it paid for college), and I have to admit I really don’t use that skill set outside of the far reaching development concepts very often. It just isn’t obligatory for ordinary SharePoint business development (note the use of the word ordinary there).

I actually can understand the Crystal Reports one. I guess. I mean I don’t use it, but it seems like in some circles it could be interpreted as a pragmatic requirement. I guess.

The conversions requirement made me sort of laugh, since that is a pretty specific skill set to want out of a developer. Because of this, as well as the larger noted SharePoint development experience, I think the organization might be more successful with breaking this into two separate jobs. To me, it’s kind of like walking into a barbershop, getting a haircut, and then asking why the barber didn’t go wash your car and walk the dog. Lazy bastard. I think coupling a C# developer that has rudimentary Java skills with a Java developer with basic C# skills would produce higher quality code conversion, most likely in a more reasonable time frame since those two programming schools tend to stay siloed in their language of choice. Even though in my experience code conversions just end up being a software rewrite anyways.

When the recruiter starts to talk about wanting the SharePoint developer, architect, and administration full package, I start to get a little frustrated. While there are certainly people that can wear all these hats, very well too, generally they become too busy divvying themselves up between tasks spawned from owning those assorted roles habitually those tasks never near completion. Only little increments are accomplished, never leading to closing. People often times like to specialize in a certain aspect additionally, and pride themselves in knowing all the ins and outs of that niche. I like doing architecture, but I love doing development. Furthermore, I simply loathe administration. It doesn’t mean I can’t do it; I just don’t enjoy it as a job role. It doesn’t blow my hair back.

The ISA and MIIS requirements are asinine if it is anything but a proof of concept or a small deployment. This should be principally noted with the MIIS requirement; the recruiter should be looking for someone that continually focuses on identity management systems when standing that up. Knowing those concepts to the metal vastly increases chance of project success. Like I said in a previous point, you don’t ask your barber to cut your grass. Unless your barber is just genuinely charitable and bored.

Consequently what happens when you are the recruiter that placed this ad out into the wild? You do a dance of joy because low and behold you found a hidden genius that satisfies hopeless requirements (not just meaning that they are hard, they really are impossible)! Yeah! Diamond in the rough! You rule! And he is willing to do it for 40k a year!

But what does your organization end up with?

The quintessential, yesss-sssir guy, whom only has the qualification of being a professional impostor and habitual liar. Fundamentally you have someone with an archetypal psychological complex tailored around satisfying people even though that satisfaction is bogus. Meaning, they are full of shit. I am not saying that to satisfy all the requirements is impossible (assuming that technology timeframes were right). It’s not, however it is decidedly unlikely. More than likely, they might *know* these buzzwords, read about it a bit, but don’t have deep experience. I have minimal Delphi experience, and very, very brief Oracle experience. Although I have used these, I don’t list them as skill sets of mine. I am not proficient enough. If they were mentioned at a job interview as required, I would throw sand in the interviewer’s eyes and flee on foot.

So I propose the following to SharePoint recruiters…

Firstly, be sensible with your project needs. I know it would be nice to have a methamphetamine IV feed developer that consistently practiced other technology facets locked in the closet that only required fish heads for substance doing your project work. I wouldn’t mind one of those myself. But it isn’t rational. When defining roles for a SharePoint implementation during the project planning process, it is healthier to have more jobs divvied up based on specialization rather than constrained numbers trying to overexert themselves out of their specialty. The former has proven, at least in my personal experience, while taking a large toll on budget tends to lead to enhanced quality of deliverables and probability of aggregate project success.

Secondly, tailor their SharePoint job ads to be more specific. Don’t be so vague. You clearly have a project, with a defined project scope (hopefully), project WBS’s (even though you are mocking people), and other project documentation. I don’t understand why this isn’t kept in mind when you are making your staffing decisions. I appreciate keeping it ambiguous because who doesn’t like the brain-surgeon-that-worked-charities-while-saving-puppies-from-burning-houses-but-now-does-awesome-SharePoint-development-guy, but your advertisement requirements are not practical. One of the most important portions of project planning is to define the roles filled by project team members and the responsibility of each role. I really doubt that there is just one role defined as everything besides the project manager.

Lastly, for Christ’s sake, research the technology that you are advertising for. You don’t have to know it very well, you just have to know it enough to *find* someone that knows it a whole lot more than you do. If I wanted to find a good dairy farmer to get some milk, I don’t have to know how to milk a cow or manage a farm, I just have to know the basics of the milk I want. The same goes when you are building technology requirements. Kinda.


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.