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.
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.