CMS Authentication and Authorization

CMS authentication and authorization is layered on top of IIS and ASP.NET security. Web.config in the CMS Web application contains security settings for authentication and authorization, with both Windows and Forms authentication modes supported. The authentication based on these settings is handled by ASP.NET authentication providers as usual. We will look into the steps for creating web.config elements for both methods shortly. However, before we do that, we need to understand how CMS handles authentication and authorization after ASP.NET has authenticated and authorized the request.

CMS Authorization Module

After ASP.NET has authenticated and authorized the user based on the settings in web.config, the request is passed to the CMS Authorization HTTP module, called CmsAuthorizationModule. The CMS Authorization module is defined as part of the HTTP module pipeline that is defined in web.config for the CMS application, as follows:

[View full width]
 <httpModules>       <add type="Microsoft.ContentManagement.Web.Security. CmsAuthorizationModule,  Microsoft.ContentManagement.Web, Version= 5.0.1200.0, Culture=neutral,  PublicKeyToken=31bf3856ad364e35" name="CmsAuthorizationModule" />       . . .  </httpModules> 

The CMS Authorization module gets the user identity from ASP.NET; it then passes the credentials to the CMS content server, which in turn determines CMS rights groups membership and thus the CMS permissions for the user. All CMS access, including guest access, must be authenticated against a Windows account, regardless of the ASP.NET authentication method used. CMS user rights can only be assigned to Windows security accounts, so any form of authorization must involve a domain account.

NOTE: Refer to Chapter 17 for a detailed discussion on setting up CMS user rights.

It is worth stressing that the CMS Authorization module in web.config is run before the template file is processed.

If no user credentials are supplied with the request, depending on whether the CMS guest access is enabled, one of the following two things happens:

• If guest access is enabled, CMS authenticates the request using the configured guest account, and permissions are defined on the rights groups that the guest account has been made a member of.

• If guest access is disabled, the CMS Authorization module will return an access denied error.

NOTE: Guest access is set up using the SCA; refer to Chapter 18 for details of the configuration steps.

Once CMS has authenticated the request, a CMS authentication ticket is issued to the browser. The ticket contains account information to indicate that a user has been successfully authenticated, as follows:

• User identity and access rights

• Date and time of issue

• IP address of the client

The ticket is encrypted using the CMS server machine key and put in a cookie called CMSAUTHTOKEN. Figure 19-7 shows an example of a CMS authentication cookie sent to the browser.

Figure 19-7. CMS authentication cookie

As we discussed in Chapter 18, the CMS authentication cookie's settings are configured using the SCA. You can set up the cookie's lifetime and whether the originating IP address of the client should be checked against the IP address contained in the cookie (Figure 19-8).

Figure 19-8. Cookie settings in the SCA

When CMS is deployed in a Web farm, it is important that all servers be configured with the same cookie encryption key. If the encryption keys differ between the servers, then a server will not be able to accept the CMS authentication cookie issued by another server, and therefore the user will be prompted for authentication again.

In this scenario, you need to use a tool provided by CMS called Managekey. It enables you to synchronize the encryption keys between the servers in a cluster; and it allows you to export the encryption key from the first server into a file and then import it into all the other servers in the cluster (Figure 19-9). The tool is located in the folder <installation drive>\Program Files\Microsoft Content Management Server\Server\bin.

Figure 19-9. Managekey utility

NOTE: CMS is not doing any impersonation of the user. That is, it matches the user name in the ticket against the user rights on the targeted CMS asset, but it is not changing the thread context of the request.

CMS Authentication Methods

As we mentioned already, the method of authentication used by the CMS Web application is defined in the web.config file. The methods of authentication that can be used by CMS are Windows and Forms. We will now look into configuration and development steps for each method.

Windows Authentication in CMS

In Windows authentication, the ASP.NET runtime uses the credentials obtained by IIS. The request is authenticated by IIS, and the credentials are passed to ASP.NET and then to the CMS Authorization module to determine the user permissions.

To configure CMS for Windows authentication, perform the following steps:

1. Configure IIS authentication using either Basic, Digest, or Integrated Windows authentication.

   NOTE: For additional security, you can use client certificates with Windows authentication. We will look into this configuration in Chapter 20.

   
   

2. Edit the web.config file to enable ASP.NET to use Windows authentication and to impersonate the user account that IIS authenticates before handing the request off to ASP.NET. To do this, set the authentication mode to Windows, and set the impersonation element to "true," as shown in the following example:

    <authentication mode="Windows"/> <identity impersonate="true"/> 

   NOTE: You don't have to enable impersonation to make sure that the user identity passed from IIS is used to access the ASPX templates on an NTFS file system this will be done in any case. You need to enable impersonation to make sure that the user identity, and not the ASP.NET process identity, is used when resources such as files, folders, registry keys, and Active Directory objects are accessed programmatically from the code at runtime.

   
   

3. Edit web.config to ensure that the ASP.NET authorization settings deny anonymous access, as follows:

    <authorization>    <deny users"?"/> </authorization> 

4. Depending on your requirements, either enable or disable guest access in the SCA.

5. Check the NTFS permissions on the ASPX template files to make sure that your users have appropriate permissions for the ASPX files. The Read permissions are required for template files. For example, if all your template files are stored within a folder called Templates, in the Security tab of this folder's Properties, add the Authenticated Users group if it's not there already, and ensure that this group has at least read permissions (Figure 19-10).

   Figure 19-10. NTFS permissions for the folder storing ASPX template files

   

Forms Authentication in CMS

Forms authentication requires the CMS user to enter credentials using form fields on a Web login page rather than using the standard mechanisms of IIS. The web.config file contains an entry for the location of this login page in the <forms> element.

No default login pages are provided in CMS; you need to develop your own. The login page must perform the following tasks:

• Authenticate and authorize the user

• Issue an ASP.NET Forms authentication cookie

• Issue a CMS authentication cookie

Please note that two cookies will be issued during the CMS authentication and authorization process. The first cookie will be used by the ASP.NET Forms Authentication module; the second one will be used by the CMS Authorization module. These cookies must share the same timeout value; otherwise, the user will be prompted to reauthenticate when either of the cookies expires.

To help you with the login page development, the CMS Publishing API provides classes that are used for authentication and authorization in the CMS environment.

• CmsFormsAuthentication is a class that wraps the functionality of forms-based login tasks. This class's methods authenticate the user against Windows domains; there are also methods that provide management of both the CMS authentication ticket and the ASP.NET Forms authentication ticket.

• CmsAuthenticationTicket is a class that contains the CMS authentication ticket that we discussed in the previous section.

• CmsAuthorizationModule is an HTTP module that we discussed in the previous section.

• CmsSecurityException provides access to security exceptions raised when your code is executed.

These classes are defined within the Microsoft.ContentManagement.Web.Security namespace. When you develop a custom login page, you use the methods of the CmsFormsAuthentication class as shown in Table 19-1.

NOTE: When developing ASP.NET forms-based authentication login pages, you use the FormsAuthentication class. This class manages the logon process and handles the issuing of cookies containing ASP.NET authentication tickets. The CmsFormsAuthentication class provides similar functionality to the FormsAuthentication class, but it issues both the ASP.NET and CMS cookies.

When a nonauthenticated user requests a CMS page, the user is redirected to the login page. When the user enters the credentials in the form fields in the login page and clicks the Submit button, the Submit event handler in your code within the login page code behind will start with generation of a CMS authentication ticket. Once that is created, a CMS authentication cookie containing the ticket, as well as an ASP.NET Forms authentication cookie, must be returned to the client browser, and then the browser should be redirected to the originally requested page. Your code will be similar to the following example:

[View full width]
 CmsAuthenticationTicket Ticket = CmsFormsAuthentication.AuthenticateAsUser(Fullname,  Password); if(Ticket !=null) {       CmsFormsAuthentication.RedirectFromLoginPage(Ticket,true,false); } else {       //Render a message that username/password are not valid } 

Table 19-1. CmsFormsAuthentication Methods

Method	What It Does
RedirectFromLoginPage	Redirects an authenticated user back to the originally requested URL; issues both a CMS authentication cookie and, optionally, an ASP.NET Forms authentication cookie for an authenticated user
SetAuthCookie	Creates both a CMS authentication cookie and, optionally, an ASP.NET forms authentication cookie for an authenticated user and puts them in the outgoing response
GetAuthCookie	Creates a cookie corresponding to a supplied CmsAuthenticationTicket, but does not set the cookie as part of the outgoing response
AuthenticateAsUser	Validates the supplied name and password for a Windows account, and creates a CmsAuthenticationTicket corresponding to that account
AuthenticateAsCurrentUser	Creates a CmsAuthenticationTicket corres ponding to the current Windows user
AuthenticateAsGuest	Creates a CmsAuthenticationTicket corresponding to the CMS guest account
AuthenticateUsingWindowsToken	Creates a CmsAuthenticationTicket corresponding to a Windows account token

In this example, the AuthenticateAsUser method authenticates the user credentials against the Windows security accounts, authorizes the user, and returns the CMS authentication ticket. The RedirectFrom LoginPage method redirects based on the contents of the ReturnUrl parameter in the query string; if it doesn't exist, it redirects to default. aspx. This method has three parameters.

• AuthenticationTicket contains a CmsAuthenticationTicket representing an authenticated user.

• SetASPNetCookie defines whether the ASP.NET Forms authentication cookie should be set in addition to the MCMS cookie; if true, the ASP.NET cookie is created.

• createPersistantCookie defines the type of CMS authentication cookie to issue; if true, a persistent cookie will be issued; if false, an in-memory cookie will be created.

To configure CMS for Forms authentication, perform the following steps:

1. Configure IIS for anonymous access.

2. Create a login page and save it in the virtual directory on your server. For public access Internet sites, to provide security, your login page should be located in a directory protected by SSL. We will look into this configuration in Chapter 20.

3. Edit the web.config file to enable ASP.NET to use Forms authentication and to point to the location of the login page. To do this, set the authentication mode to Forms, and specify the login page details in the <forms> element, as shown in the following example:

   [View full width]
    <authentication mode="Forms">    <forms loginUrl="LoginPage.aspx" name="MyFormCookie"  path="/" protection="All"  timeout="30"/> </authentication/> 

   NOTE: The cookie lifetime specified in the "timeout" attribute of the <forms> element applies to the ASP.NET Forms authentication cookie only; the CMS cookie lifetime is set up using the SCA.

   
   

4. Make sure that the authorization settings in web.config allow access, as follows:

    <authorization>    <allow users="*"/> </authorization> 

5. Depending on your requirements, either enable or disable guest access in the SCA.

6. Verify the NTFS permissions on the ASPX template files to make sure that the ASP.NET process identity account has appropriate rights on the the template files. The default ASPNET account is a member of the local Users group; if you use the default account, check that the Users group has at least read permissions on your templates.

When CMS is deployed in a Web farm, all CMS servers should be able to recognize each other's CMS authentication cookies and ASP.NET Forms authentication cookies. To enable this, you need to synchronize several encryption keys between the servers in the cluster.

To synchronize the encryption keys used for CMS authentication cookies between the servers, you need to use the Managekey utility that we discussed earlier in this chapter.

To synchronize the keys for encryption and validation of the ASP.NET Forms authentication cookies, you need to edit the <machineKey> element in the machine.config file on all servers in the cluster. Before we discuss the <machineKey> element, let's look into how Forms authentication cookies' encryption and validation are defined. Whether encryption and validation are enabled is defined by the value of the "protection" attribute in the <forms> element in web.config. If the "protection" attribute is set to All, the cookies are encrypted and validated, which is the best level of protection and the recommended approach. Other values include Encryption and Validation, for enabling either only the encryption or only the validation of the cookies.

If the keys for validation and encryption on servers in the cluster are not synchronized, the user will be asked to reauthenticate each time a server in the cluster gets a request previously authenticated by another server.

The <machineKey> element defines those keys. For each server, the <machineKey> element and its attributes need to be specified in the machine.config file. The settings must be the same for all servers in the cluster. The syntax of this element is as follows:

 <machineKey validationKey="AutoGenerate|value"             decryptionKey="AutoGenerate|value"             validation="SHA1|MD5|3DES" /> 

The validationKey attribute defines the key used to validate the cookie. The default value is AutoGenerate. This is not suitable to our environment, because the generated values will be different on different servers. Therefore, we need to supply the value for this key manually. The recommended key length is 128 hexadecimal characters (64 bytes). The decryptionKey attribute defines the key used for the cookie's decryption. Again, the default value is AutoGenerate, which is not suitable for Web farms; therefore, we need to supply the value for this key manually. Once again, the recommended key length is 128 hexadecimal characters (64 bytes). The "validation" attribute defines the hashing algorithm: MD5, SHA1, or 3DES. The hash is computed from the cookie data using an algorithm defined in the "validation" attribute with the validation key, and is then sent to the client with the cookie data. Both the data and the hash are encrypted. When the cookie is returned, the server decrypts it and then validates it by reapplying the hashing algorithm using the validation key.

User Identity

As we have seen in this chapter, the user identity in CMS depends on a combination of settings within IIS, ASP.NET, and CMS itself. Table 19-2 lays out the resulting identities for permutations of the key security settings in CMS, as follows:

• Worker process identity: You can get this identity programmatically using the WindowsIdentity.GetCurrent method.

• User account authorized in the CMS content server for the current HTTP request: This account identity is available programmatically from the CmsHttpContext.Current.User.ServerAccountName property.

• User account identity within the CMS ASP.NET Web application for the current HTTP request: This account identity is available programmatically from the HttpContext.Current.User.Identity. Name property.

Table 19-2. CMS and ASP.NET Identities

web.config Authentication Mode Setting	Is CMS guest access enabled?	Is IIS anonymous access enabled?	web.config Impersonate Setting	Windows Identity.GetCurrent	CmsHttpContext.Current.User.ServerAccountName	HttpContext.Current.User.Identity.Name
Windows	Yes	Yes	true	IUSR_<machinename>	<CMS guest>	blank
Windows	Yes	Yes	false	ASPNET	<CMS guest>	blank
Windows	Yes	No	true	<Windows user>	<Windows user>	<Windows user>
Windows	Yes	No	false	ASPNET	<Windows user>	<Windows user>
Windows	No	Yes	true	<Windows user>	<Windows user>	<Windows user>
Windows	No	Yes	false	ASPNET	<Windows user>	<Windows user>
Windows	No	No	true	<Windows user>	<Windows user>	<Windows user>
Windows	No	No	false	ASPNET	<Windows user>	<Windows user>
Forms	Yes	Yes	true	IUSR_<machinename>	<CMS user>	<CMS user>
Forms	Yes	Yes	false	ASPNET	<CMS user>	<CMS user>
Forms	Yes	No	true	<Windows user>	<CMS user>	<CMS user>
Forms	Yes	No	false	ASPNET	<CMS user>	<CMS user>
Forms	No	Yes	true	IUSR_<machinename>	<CMS user>	<CMS user>
Forms	No	Yes	false	ASPNET	<CMS user>	<CMS user>
Forms	No	No	true	<Windows user>	<CMS user>	<CMS user>
Forms	No	No	false	ASPNET	<CMS user>	<CMS user>

In Table 19-2, <Windows user> refers to the currently logged-on Windows user account, <CMS guest> refers to the CMS guest account, and <CMS user> refers to the Windows account authorized in CMS when the forms-based login is used.