Use LINQ To Get Central Administration Web Applications

I needed a quick and dirty way to go through the SPWebService.AdministrationService to get a collection SPWebService.WebApplications and then test whether the SPWebApplication is the Central Administration application. To do this you need to use the SPWebApplication.IsAdministrationWebApplication boolean property. To keep things succinct you can just chain a LINQ query to return the representative SPSite of the desired administrative SPWebApplication. Consider the following RetrieveAdminApplication method that is consuming a SPContext object as a parameter:

public static SPSite RetrieveAdminApplication(SPContext context)
return SPWebService.AdministrationService.WebApplications.Cast().
Where(application => application.IsAdministrationWebApplication).FirstOrDefault().

This is probably not ideal, but will work!


Are SharePoint Developers Better Architects than Architects?

I was at dinner last night with a SharePoint-y friend of mine and the dialogue arose about distinctions in what is coined as a SharePoint developer and as a SharePoint architect. In a majority of SharePoint projects these are advised as key, mutually exclusive roles that are obligatory for project success. And while I to some extent agree with this notion (such positions being requisite that is), if you look at a arbitrary, indiscriminate company on like or something that is spinning up a freshy practice, staffing a client project, or doing a clean IT slate at a corporation, you are going to most likely see these positions listed. As a result, I just consider it the industry, while it might be exactly my personal, standard.

Defining the difference between an architect and a developer is prickly, and to be honest I think such arguments revolving around position semantics are at best lackluster. However there are a few things I think that deserve noting before I get a wee bit rantish with the remainder of this post.

SharePoint architects commonly are not considered to have mastered development tools and frameworks; generally you find them working closer with the operations group for the inclusive IT environment. Inferring then, it can be assumed that responsibility lies more with the physical / application network, SharePoint servers, SQL storage, management / operations / governance, server and SharePoint security, and miscellaneous other systemic qualities of SharePoint. Conversely, this implies that the other portions of the team pick up weight understanding and implementing the functional aspects of the product, or in relation to what was stated before development tools and frameworks. It is tough to place a multifarious job description in a succinct, single sentence however that is the best I can do for the time being and serves this particular argument pretty well.

Leveraging this as a definition, we then raised the question of not the differences that exist between the two positions (although this conjecture is important in the following argument), but whether SharePoint developers are better SharePoint architects than those that solely define themselves as architects.
The questioning is simplistic; the reasoning is slightly more convoluted. Consider two candidates for a project, one of them a SharePoint architect and the other a SharePoint developer. Furthermore, in order to maintain a equitable baseline, let’s assume comparable (obviously can’t be identical) backgrounds, projects, experiences, etc. Would you insist that the SharePoint developer will be more successful if given a series of requirements and turned feral on a SharePoint project? While this isn’t the structure of a particular staffing strategy for a SharePoint project, it’s the most extreme argument.

For me, the answer is a resounding yes!

Below are three principal reasons why this is the case in my opinion, which is obviously very, very subjective so take it with a grain of salt.

Inherent API Use Leads To Innate Architectural Understanding

Developing against a commercial OOB product such as SharePoint necessitates a majority of the knowledge that architects generally tout as requisite because of object, method, etc. use. As such, the thread that weaves the overall linen is already known, and while IMMEDIATLY the strands being put together properly might not be holistically identified, the knowledge does exist so the barrier to entry is lessened to an immeasurable extent. So while this might not immediately translate to the breadth of architectural knowledge having immediate applicability, I consider this more to be a lack of situational experience (which is even more subjective) easily garnished during a project therefore making a developer a more appealing candidate in the long term.

While there are a lot of examples, I am going to assume a more common one that I see to support such a claim. Consider the use of a UserProfile object and its tricky permissions requirements that require setting in the SSP. I can’t count how many architects I have caught with this on an interview question, but I have never really caught a reasonable developer off with it since when enumerating UserProfile objects in a UserProfileManager that they always get the pesky System.UnAuthorizedException due to personalization services permissions being malformed. As a result, they are already privy to such knowledge.

Developers Are Unquestionably More Learned in Orthodox .NET Concepts

SharePoint is often misconstrued as a mythical unicorn type thing from a platform standpoint that is built on a hugely disparate stack then the rest of Microsoft platforms. And while there were a lot of awkward things in V2 that would imply it really was a one off (for this, I am thinking more a lot of the ISAPI request handoff’s etc.), in V3 it is really just a ASP.NET 2.0 application (outside of fickle things like virtual path providers and what not which are never going away anyways), using the same underlying technologies as thousands of separate web applications across the world. Applications that .NET developers have written, and most convert SharePoint developers already have a fairly thick background in orthodox .NET development.

While interviewing architects for companies, something that I see is that architects stop learning technology once it crosses a certain cusp, in the terms of this post essentially pigeon-holing themselves into the SharePoint slot. While this has both pros and cons, the lack of understanding makes it more difficult when problems arise in a SharePoint environment that can be traced back to a deeper part of the MSFT technology stack, things not well handled by native SharePoint mechanisms.
Again, lots of examples of it. Pragmatic example wise, I always see it with claims aware SharePoint environments. Since developers are more accustomed to different identity contexts, when building claims based environments they are much more effective at putting together how a federated identity processes should flow.

Tend To Have a More Refined Pattern for Business Problem to Technology Translation

I think this one is going to be the toughest point to sell, however I really do believe because developers understand a much deeper portion of the how the overall platform functions (since they are accustomed to extending it) they can provide a more seamless transition of taking requirements and providing the end result. What I see more on projects, way more when I am doing architectural / planning reviews than anything is the use of technology by architects for the simple reason of using it because it was described on a MSFT product page as being a possible solution, so it MUST be the BEST solution. There is awfully little thought given to inclusive environment impacts, and most importantly demonstrated the solution flow so a customer is aware of the steps that are involved in application function.

The BDC is a terrific example of this. When doing please-unfuck-our-SharePoint-environment projects I see architects all the time spouting all these terrific things about the BDC. When implemented not ONLY will you be able to display disparate data, but everyone in the organization will lose thirty pounds, get their hair back, and their significant others will gain an untamable sexual appetite. But 9/10, the BDC is an awful, unmaintainable solution (Obvious FYI: I don’t like the BDC very much in its current form. If I can do it in 10 lines of managed code as opposed to 40,000 lines of XML, I’ll take the managed code option), and the persons ultimately responsible don’t even understand how the XML translation provides DAC, further abstracting the customer from the actual solution. While the BDC is touted as a non-code solution, I can at least walk through my managed code and DEMONSTRATE how the data, in real time, is called, massaged, and presented.

Boy, I could go on with this for a while, but I’m gonna call it quits here :)


SharePoint (ASP.NET 2.0) Forms Authentication

What is Authentication?
Authentication is a process of determining the identity of the user. Authorization is the process of determining what the user is eligible to access and what actions are legal for the user to take when sending a request to a SharePoint environment.

The SharePoint authentication process, at a very basic level, begins when the user requests to invoke a SharePoint WebForm after some level of protection has been implemented. When the request is invoked, depending on the authentication type, SharePoint will check if the user has has an authentication and/or role cookie that houses an authentication ticket. If the cookie is found, some plumbing will execute to route the request and determine the role of the user and relevant rights. When using forms-based authentication, if a cookie is not found the user will be re-directed a custom login page as specified in the web.config or the default login page used with the internet presence site template. Following, the user will log in with their specific user credentials. Afterwards, this information will execute a postback for authentication purposes. Once the information is posted back to the server, the server examines the cookie for details of the requested page. This authentication is in most scenarios configured for only a session.

Introduction To SharePoint Forms Based Authentication
Since SharePoint 2007 builds on the ASP.NET 2.0 framework, there are a number of new classes that weave into authentication mechanisms allowing new functionality to be exposed. The relevant authentication classes derive out of the System.Web.Security namespace, which has a variety of exciting features, one of most core to authentication being the MembershipUser Class.
In relation to forms based authentication, the main classes that are used with the Microsoft Office Server System:

  • FormsAuthentication class
  • Roles class

These two classes provide a number of static methods as discussed in previous articles. Along with these, the personalization feature that has been built into MOSS will help you store user profiles and preferences and any custom information about your users. The authentication process along with the personalization process provides the user with a powerful and personalized user experience.
The Membership Class
The Membership Class, which is detailed more exhaustivly in other articles, uses the Membership Provider specified in WCAM and the web.config file of the relevant web application to work with the membership data store, and like the other classes relating to authentication, the methods of these classes are static. There are variety of features that are available in the membership class, but most notably these methods can be used to create and delete users (or catch membership exceptions) as well as retrieve and update data that is stored in the MembershipUser class. When implementing forms based authentication, the custom login form that is available within the internet presence site, or when creating a custom login form use the ValidateUser method of this class to authenticate the user when the credentials are submitted.
Modifying the Authentication and Role Providers

The data provider class contains the code that reads and writes data for users and roles. When it is linked with membership, then this class is known as membership provider while the one linked with roles is called the role provider. Both these providers are stored in AspNetSqlProvider. The database is known as AspNetDB.mdf and is stored in the App_Data folder of the website. This database is automatically created and works well for prototyping.

The attributes of the data provider can be changed or modified to redefine the way the provider behaves. The strict password requirements can be relaxed for instance by copying the membership element from the machine.config file to the web.config file of your application and editing the Name attribute of the element to create a unique name for the modified provider. The minRequiredPasswordLength and minRequiredNonAlphanumericCharacters attributes can then be redefined. Finally you can add the defaultProvider attribute to the element so that the application begins to use this provider. The architecture of ASP.NET 2.0 allows you to use different providers or custom provider if you so desire.
Using the Visual Studio 2005 Login Controls

Once the user roles and access rights have been defined, users must be allowed to register themselves and then login and browse the pages of your web application. The first step that is usually taken is the creation of the Login.aspx page. ASP.NET 2.0 creates all the login functionality the moment you drag and drop a login control onto your page in design view. The login control has two text boxes one for user id and another for password. It has a button for submitting the login information. The login status and the LoginName controls have to be dragged and dropped on to the application pages to provide the additional functionality of checking whether the user is logged in or not and his name.

A number of views of the Login control are inbuilt into ASP.NET 2.0. It can be automatically formatted by right clicking the control and selecting the AutoFormat command. Then the format of your choice can be selected from the dialog box that opens. The formatting properties of the control will change according to the selection made. The Login control can be set to force the user to use a secure connection.

Links can be created for users who have forgotten their password or want to register as a new user. The hyperlinks can be designed to open the relevant pages. The CreateNewUser Wizard Control and PasswordRecovery control can be placed on NewUser.aspx and PwdRec.aspx pages of your application to get the necessary inputs from the user. The membership provider is used to write the data to the appropriate data source. The ChangePassword control is used to allow the user to change his password. The code files are automatically created providing all the necessary functionalities for this purpose. The Autoformatting feature available for the Login control is also available for the CreateUser control, the PasswordRecovery control and the ChangePassword control.

 Creating Users and Roles


Roles are disabled by default and are optional. To create user roles, developers must enable roles while creating users and access rules. All this can be done in one place and you will be spared t he necessity of having to go back again and again to define roles and access rights of users.Click on Enable roles button under the roles column of the page and navigate to the screen that enables you to add roles. Once the role is created, a link will appear at the bottom of the roles column and you can create or manage roles by adding access rules to the role. As a result, a change in the access rights of a role will change the access rights of all users under a role. If you have already created a number of users, you can now click on the manage link to add users to the role by selecting the users from the list of users. If you have not created users, you can now create users by clicking on the create user link and filling in the details of username, password and security question. ASP.NET 2.0 has a default password policy which requires that the password should be at least seven characters long and one of the characters must be non-alphanumeric. This policy can be relaxed by the developer by adding certain attributes to the membership provider. ASP.NET 2.0 has a default password policy which requires that the password should be at least seven characters long and one of the characters must be non-alphanumeric. This policy can be relaxed by the developer by adding certain attributes to the membership provider.

Searching For Users and Roles
The Search user feature can be used if there are a large number of users in your application. The search can be by selecting the email address of the user from the drop down combo box or by entering the email address in the text box. * and wild card characters can also be used to search for users in the application or you can click on the alphabets to display all emails beginning with a specific alphabet and then browse through the list to select the user you want.

Applying MOSS Access Rules

Access rules restrict the user from accessing all parts of the application. To apply access rules to the entire application you can select the root directory of the application and apply the rule. This will make this rule applicable to subfolders of the application also. If you want to restrict rights to a specific subfolder, you need to apply the rule to the subfolder only. However, it is common to allow users access pages which are placed in the root directory and to restrict rights to pages placed in other directories of the application.

To create access rules for each role click on the create access rules link under the Access Rules column of the web browser page under the security tab. You can optionally add access rules to control access to the whole Web site or to individual folders. Rules can apply to specific users and roles, to all users, to anonymous users, or to some combination of these. Rules apply to subfolders. The following page will be displayed. Set the access rules after selecting the role and the user. Once the access rules have been created the same can be managed by clicking on the manage access roles link in the web browser page of the tool under the security tab.

As have been discussed, forms authentication is one of the most common security implementations that happens on a perimeter facing network in order to build the most comprehensive user experience. Forms authentication is a very important portion of SharePoint since there are various types of SharePoint sites, those that range from quite large implementations to incredibly small, all optionally siloed from each other using a variety of architectural options, and forms authentication can span all implementations regardless of purpose, size, or environment.

AuthenticateRequest and AuthorizeRequest

We have seen how IIS handles the request process when a data packet is initially injected into the pipeline, but how exactly is a forms request handled from initial request implementation to authentication and authorization request acceptation or rejection? The process is quite simple, and very similar to the forms process that was introduced with ASP.NET 1.x. Similar to the routine that happens when a user enters an arbitrary web asset, there are two major processes that happen, authentication and authorization. This is done by two requests, AuthenticateRequest and AuthorizeRequest, each with their own respective logic and concepts that deserve study to understand how each functions and the implications of each.


The first process that happens during the request handshake is that the request has to be validated, determining whether a ticket initially exists or not, dealing with the first the authentication portion of the request routine, as stated in the previous section AuthenticateRequest.

This is done by an asset called FormsAuthenticationTicket. FormsAuthenticationTicket will check the validity of the ticket on the client, in essence firstly determining whether it exists, and if the ticket does exists, doing some rudimentary checks on that ticket. There are two obvious scenarios that exist in this, the ticket exists, or the ticket doesn’t exist. If the ticket doesn’t exist, one will have to be created to carry across future sessions. However, if the ticket is found, there is some logic that has to execute in order for it for determination of whether that ticket is valid or not. Since during the authentication process one is concerned with validating a tangible identity of a requesting party, the ticket will look at the current user, or Current.User, provided by the FormsIdentity. FormsIdentitiy is incredibly important, which we will see shortly in subsequent sections of this article.

The next portion happens with authorization, or as stated in the previous section, AuthorizeRequest. There can be complex logic that is associated with this request. There are two branches that can happen with AuthorizeRequest, either the request can be denied or accepted. There has to be an authenticated user that is preexisting for AuthorizeRequest to be successful. If this request fails, then the termination phase of the request initiates, which is handled by EndRequest. If the EndRequest is called and initiated, then there is a small redirect that happens which will point the failed request to the forms authentication login page, which is controlled in the web.config file. All of this is of course, assuming that the requesting user is pulling up any page besides the web form that contains the login logic.

Types of Tickets

There are various types of tickets that exist in SharePoint when leveraging forms authentication. Although in ASP.NET 1.x there was the option to use forms authentication with web applications, this was not the case in SharePoint 2003 which required using the CustomAuth ISAPI extension in order to get a proper forms authentication implementation going for such an environment. When using forms authentication in ASP.NET 1.x, there was the option to use two types of tickets, persistent and non-persistent, and these tickets were always stored in cookies. As we can gather from the previous section, the ticket can play a very crucial role in the authentication and authorization process when a user requests any web form besides the login form, it is one of the first pieces of logic that is checked when the request is made and can significantly impact the overall experience.

With persistent cookies in ASP.NET 1.x, the time to live field was always a cause for concern, since the field values was exceptionally high, 50 years to be exact, however this concern is remedied in ASP.NET 2.0 whereby persistent tickets are handled in a different fashion. Like many of the settings that effect your SharePoint portal, these settings are effected by the edits that implemented within your web.config file, based on the cookie timeout value, which by default will be 30 minutes. This values is obviously much less than that of 50 years which is excessive, and much more tiered toward a properly secured architecture, otherwise the time to exploit said assets is more than available. Although SharePoint end-users may begin to complain (since it requires more login attempts by the user when the cookie session expires),

Tickets and Ticket Security

In regards to signed tickets, there are security attributes that are related to those signed tickets that need to be taken into consideration, some of which relate back to the security considerations that were introduced with ASP.NET 1.x. In ASP.NET 1.x, there was some concept of security that was introduced with tickets, namely algorithms that were used in regards to ticket signing. In ASP.NET 1.x the tickets were signed with the SHA1 algorithm using a keyed hash, and this type of technology was carried over in ASP.NET 2.0 (deriving out of the System.Security.Cryptopgraphy.LMASHA1 class), since there are several variants that exist with SHA encryption, and by variants I mean the bit count that is required from plain to cipher text translation.

SHA encryption has been around for some time, and has gone through some vast changes. There are several flavors, that although deriving out of the same base functionality have various levels of encryption functionality. The ones that are pertinent for the security professional, SHA1, SHA256, and SHA512 are the most common, and the only difference as you can see within the name suffix is the encryption strength routine that is implemented, meaning, the later ones implemented higher bit counts and therefore when conversion from plain to cipher text representations some are generally more secure cryptographically than others.

Each of these representations can be used as a string value that are helpful in hash functions. When creating the algorithm to use in the hash functions, you can use the various algorithms as described above when implementing HashAlgorithm.Create, so that you can control which algorithm is implemented in regards to the hash function.

Using Cookies / Cookies less Mode and Forms Authentication

Some of the cookies options that are available with forms authentication has already been discussed, however there are several other options that are available that help to enhance security. As well, with a new introduction of technology in ASP.NET 2.0 it is also possible to use the option of a cookieless environment that will effect the function of a forms authentication process with SharePoint.

The first of these that is carried over from ASP.NET 1.x is cookie based forms authentication, which was incredibly common when writing applications in ASP.NET 1.x, and since forms authentication didn’t exist OOB in SharePoint 2003, wasn’t existent. Cookie based forms authentication is still the most common setting in forms authentication, since it has enhanced properties that don’t exist with cookieless forms authentication.

Adjusting a Cookie Enabled Forms Environment to Require SSL

The first of these is the most commonly set, dealing with implementing Secure Sockets Layer (SSL) which is the best security practice with perimeter facing environments. We have seen that when implementing forms authentication, the main element that is adjusted is in the web.config file, specifically in the < forms > element, which is automatically adjusted when making the modifications through SharePoint WCAM. This is good for authentication purposes, but what about securing the pipe in regards to how cookies are handled within the SharePoint environment, ensuring that the cookie communications are only transmitted across a secure pipe is an increasingly important configuration setting when implementing forms based authentication that implements a cookie based environment.