| A CMS Internet site is an external site that is available to any user for browsing. In this environment, we need to cater to various browsers; a common browser standard cannot be guaranteed. Depending on whether all areas of the site are open to all users, we can distinguish between two types of sites: Full public access sites: In a full public access site, all users have the same level of access; there is no need for users to log on. Public access sites with private areas: In this scenario, not all areas of the site are available to all users; there are areas that require a user to log on, for example, to view premier content.
Authentication and authorization mechanisms for these types of sites are significantly different. For a public access CMS site, only one user account for guest access and one CMS rights group are required. If the site has private areas, user authentication and authorization requires careful planning; in most cases, external authentication is used. Let's have a look at the settings for both scenarios. Full Public Access Sites With publicly available CMS Internet sites, any user can see the full site. No authentication is necessary; there is no logon/logoff link. Configuring security in this scenario involves several layers. IIS authentication: Configure IIS for anonymous access; disable all other authentication mechanisms. ASP.NET security: Use the default settings for authentication, authorization, and impersonation, as created by VS.NET in the web.config file at the root of the CMS Web application. No additional configuration is required. The default setting in web.config for authentication is as follows: <authentication mode="Windows"/> The default settings for authorization and impersonation are usually inherited from machine.config. These settings are as follows: <authorization> <allow users="*"/> <authorization/> <impersonate="false"/> NTFS permissions: The template files and static site files must have at least read permissions set up for the IIS impersonation account IUSR_<machinename>; other resources that are accessed from the template code must have read permissions for the default worker process account, such as the local ASPNET account in IIS 5. To provide this configuration, no additional setup is usually required, since the default file access control lists (ACLs) include read permissions for the Everyone group by default. CMS guest accounts: Using the SCA, enable guest access to CMS and specify the guest account. It may be a domain account or a local account. If you use a local account, define it as localcomputer\<account name>. If your CMS site is deployed in a Web farm (Figure 20-2) and you want to avoid using a domain account as a CMS guest account, make sure that each machine has local accounts with identical names set up as the CMS guest accounts. For example, you can create the local account MCMSguest on all computers in the farm. CMS user rights: Create a CMS rights group within a subscribers role and add a CMS guest account to this group; then assign this group to all containers, such as channels, template galleries, and resource galleries. CMS Web entry points: Using the SCA, configure the CMS Web entry point for production servers to be read-only. NOTE: Only the authoring/staging server connected to the internal network should have a Web entry point configured as read/write. It will be used to import content into the CMS database.
CMS authentication cookie encryption keys: If CMS is deployed in a Web farm, all CMS servers should be able to recognize each other's CMS authentication cookies. You need to use the Managekey utility to synchronize the cookie encryption keys between the servers. Refer to Chapter 19 for an explanation of the Managekey utility.
NOTE: Since there is no authentication and no requirement to authorize requests, you may consider removing the CMS Authorization module for the HTTP pipeline in web.config to provide additional performance for the site.
On a CMS site that is configured following these steps, processing of a page request includes the following authentication and authorization sequence: IIS receives the page request. Since anonymous access is enabled, IIS passes the IUSR_<machinename> identity to the worker process. The CMS Web application is configured to use ASP.NET Windows authentication; therefore, the IUSR_<machinename> user credentials from IIS are used for template file authorization. ACLs on the template files include the Everyone group; therefore, file access is authorized. After file authorization, the IUSR_<machinename> user credentials for an anonymous request are passed to the CMS Authorization module. The CMS Authorization module gets the anonymous request credentials and checks with the CMS content server whether guest access is enabled. Because guest access is enabled, the server authenticates the user as a guest and defines the CMS rights group membership for the CMS guest account. Because the CMS guest account belongs to the subscribers group that is assigned to all site containers, the request for a page in presentation mode is authorized. Then, a CMS authentication cookie with the guest user ID is attached to the HTTP response.
Public Sites Using an External Authentication Source A public site with an external authentication source is an Internet public site with private areas that uses an external system for authenticating users. There are sections of the site that are available to any Internet user, as well as premier content sections that are available only to registered users. Registered users are able to browse the public parts of the site, but to access premium content, they need to provide their credentials; therefore, the logon/logoff link is required. The authentication mechanism best suited for this scenario is ASP.NET forms-based authentication. However, it is unlikely that registered users will have Windows user accounts on your system. Since any Internet user may register on the site, you don't want to maintain millions of user accounts in your Active Directory domain, but you still need to validate the submitted credentials. The solution is to use an external authentication source. For example, you may maintain user account credentials such as user name and password in the SQL database; or you may maintain user account credentials using your company's customer relationship management (CRM) system; or you may decide to use Microsoft Passport or any other external source that is required by your business needs and is deemed appropriate by your company security policy. The external authentication source may also be used for user profiling. As we know, CMS requires a Windows user account for authentication and authorization of any request; CMS user rights can be assigned to a Windows account only, not to an external source account. Therefore, we need to provide mapping of externally authenticated users to Windows accounts. This mapping will be many-to-one (Figure 20-4) many external accounts will be mapped to one Windows account that will define the CMS permissions. The mapped Windows account may be a domain account or a local account. The number of Windows accounts required depends on the different types of access you need to provide on your site; each Windows user represents one type of access. Figure 20-4. Mapping of external accounts to Windows accounts 
The mapping algorithm depends on your business requirements. For example, you can have a mapping list that maps external users to Active Directory accounts. Because the list actually names the AD accounts, it should be secured. You will probably host it on your CMS site, not the external authentication site. In any case, you will need to define procedures for maintenance of the mapping list that is, how you add new mappings, how you make sure that changes to Windows accounts are reflected in the mapping list, and so on. Another possibility is to use a type instead of a mapping list, as shown in Figure 20-5. In this case, a flag is specified for each type of access to your site. You then need to map this type flag to a Windows account programmatically. The type flag provides the ability to group the external user accounts together depending on the access these users require to your site. Then, you map any member account of the group to a predefined Windows account on your system. This approach is more flexible than using a mapping list. It saves management overhead in maintaining the mapping list and doesn't expose your Windows accounts. The type flag is usually stored on the external authentication site as a property in the account information. For example, the type flag may be returned to you as an additional user attribute with the validation confirmation from an external source. Figure 20-5. Mapping of external accounts to Windows accounts using user types 
In any case, the mapping code will have to be written; it will differ depending on the external authentication source you use. Depending on the source, the user credentials may vary for example, an e-mail address and password; or a user name and password; or a user name, password, and an answer to a specific question; or just an e-mail address if you are not that concerned about security of access, but want to collect data for user profiling. The good news is that the CmsFormsAuthentication.Authenticate AsUser method allows us to use both the user-supplied user name and the mapped Windows account credentials to create a unique CMS authentication cookie for this particular user. The syntax is as follows: [View full width] CmsFormsAuthentication.AuthenticateAsUser( ServerAccountName, ServerAccountPassword,  ClientAccountName, ClientAccountType )
where ServerAccountName and ServerAccountPassword are Windows account credentials, ClientAccountName is the user account identifier supplied by the user, and ClientAccountType is the type of user account that we assign in the code according to our business logic. The runtime logic of the CMS authentication and authorization in this scenario is as follows: Get the user credentials. For example, a user authenticates himself as the user michael with the password pwd123. Validate the user credentials against the external authentication authority. For example, the external authentication authority may be your CRM. Assign a client account type for example, A. Based on the type, map the external user to a Windows account for example, CmsAccountA. Retrieve the Windows account password for example, A-pwd. Authenticate the user to Microsoft Content Management Server, using [View full width] CmsFormsAuthentication.AuthenticateAsUser( ServerAccountName, ServerAccountPassword, ClientAccountName, ClientAccountType )
and then verify that the returned CmsAuthenticationTicket is not null. In our example, ServerAccountName is CmsAccountA; ServerAccountPassword is A-pwd; ClientAccountName is michael; and ClientAccountType is A.
To implement this logic, you will need to write code in the login page, usually using event handlers. The event handler implements procedures for authentication against an external source, as well as mapping an externally authenticated user type to a Windows account and obtaining the account's password. You will need to write your own code for the event handler; it will be a general ASP.NET event handler and not CMS-specific. For example, you can write code for an event handler in global.asax that is, the AuthenticateRequest event handler. You may consider writing your own authentication HTTP module as well. NOTE: For an example of event handler structure, refer to Chapter 3 of the online book Integration Techniques and Strategies for CMS 2002, available from http://msdn.microsoft.com/library/default.asp?url=/servers/books/cms/integration.asp.
To set up security for a CMS Internet site using forms-based authentication mapped to a custom external source, consider the following steps. Windows mapped accounts: Create one account, either domain or local, for each type of access to your site's premier content. For example, your business needs require that one group of users is able to see section A of the site's premier content, and another group of users is able to see section B of the premier content. To provide this functionality, you need to create two Windows user accounts: one for the first type of access (for example, CmsAccountA) and another for the second type of access (for example, CmsAccountB). The settings for this example are listed in Table 20-1; the first four columns show mapped accounts by type of access. IIS security: Configure IIS for anonymous access. Make sure that the server certificate from a globally recognized CA is installed on your server and that SSL is enabled on port 443. Create a virtual directory on your server that will store the login page, and enable SSL for this directory for example, /login.
ASP.NET security: Authentication: Create a login page that implements the logic we discussed. In our example, the code in the login page will use an event handler that validates the user against an external source and provides the mapping of all externally authenticated accounts of type A to the Windows account CmsAccountA, and accounts of type B to the Windows account CmsAccountB. The type flags and the corresponding mapped accounts are shown in Table 20-1. Save the login page in the HTTPS-enabled virtual directory for example, as /login/LoginPage.aspx. 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: <authentication mode="Forms"> <forms loginUrl=" https://<server name>/login/LoginPage.aspx" name="MyFormsCookie" path="/" protection="All" timeout="30"/> </authentication/>
Authorization: Configure ASP.NET to allow access. Make sure that the following element is added to the web.config authorization section: <authorization> <allow users="*" /> <authorization/>
NTFS permissions: Verify the NTFS permissions on the ASPX template files to make sure that the worker process account has at least read permissions on the template files. Verify that the IUSR_<machinename> account has read permissions on the static site files that are not stored in the resource galleries.
CMS guest account: Using the SCA, enable guest access and specify the guest account. It can be a domain account or a local account. This account will be used for browsing the general areas of your site available to all users. CMS system account permissions: If you use AD mapped accounts, verify that the CMS system account has permissions to view the tree in the AD domain where you set up the mapped accounts for the site users. CMS user rights: Create CMS rights groups: Using the Site Manager, create subscribers rights groups for each type of users that will be supplying their credentials to view sections of premium content. Add Windows mapped accounts to these rights groups one account to one group. Create another subscribers group for your anonymous site users and add a CMS guest account to this group. Continuing with our example, you will need to create two subscribers rights groups in CMS for example, SubscribersTypeA, and SubscribersTypeB; then add the Windows mapped account CmsAccountA to the SubscribersTypeA group, and the second Windows mapped account CmsAccountB to the SubscribersTypeB group. You will also need to create a third subscribers rights group for anonymous site users for example, SubscribersAnonymous. Table 20-1 shows the mapped accounts and the associated subscribers groups in columns 4 through 6. Assign the rights groups to the site containers: Assign the subscribers groups you've created to site containers, such as channels, template galleries, and resource galleries, as appropriate for the user type each subscribers group represents. Assign the subscribers group with the CMS guest account to the channels and other containers that can be viewed by all users. In our example, you will need to assign the Subscribers TypeA rights group to the channels and other containers that provide information for section A, and assign the Subscribers TypeB group to the channels and other containers that provide information for section B. Then, assign the Subscribers Anonymous rights group to the channels and other containers that do not require authentication. Table 20-1 lists the subscribers groups and their rights to containers in columns 6 and 7.
Table 20-1. Mapped Accounts and CMS RightsUser Authentication | Parts of Site Where Access Is Required | Type Flag | Windows Mapped Account | CMS User Role | CMS Rights Group | Rights to Containers |
|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|
Externally authenticated | Premier content, section A | A | CMS AccountA | Subscribers | Subscribers TypeA | Channels in section A; template galleries and resource galleries required to view content in section A | Externally authenticated | Premier content, section B | B | CMS AccountB | Subscribers | Subscribers TypeB | Channels in section B; template galleries and resource galleries required to view content in section B | Anonymous | Publicly available | | <CMS guest account> | Subscribers | Subscribers Anonymous | Public channels; template galleries and resource galleries required to view content in public channels |
CMS Web entry points: Using the SCA, configure the CMS Web entry point for production servers to be read-only. CMS authentication cookie encryption keys: If CMS is deployed in a Web farm, all CMS servers should be able to recognize each other's CMS authentication cookies. You need to use the Manage key utility to synchronize the CMS cookie encryption keys between the servers. Refer to the previous chapter for an explanation of the Managekey utility. ASP.NET Forms authentication cookie encryption and validation keys: If CMS is deployed in a Web farm, all CMS servers should be able to recognize each other's ASP.NET Forms authentication cookies. You need to edit the <machineKey> element in the machine.config files on all servers to synchronize the ASP.NET Forms authentication cookie encryption and validation keys. Refer to the previous chapter for an explanation of the <machineKey> element and its attributes.
On a CMS site that is configured following these steps, processing of a page request includes the following authentication and authorization sequence: IIS receives the page request. Since anonymous access is enabled, IIS passes the IUSR_<machinename> identity to the worker process. The ASP.NET authentication mode in the CMS Web application is set to Forms; therefore, the identity passed from IIS is not used for authentication. ASP.NET checks whether a valid Forms authentication cookie is attached to the request. If not, it tries to pass the worker process default account identity to the CMS Authorization module. The CMS Authorization module checks with the CMS content server whether guest access is enabled and attempts authorization for the CMS guest account. If the requested page is available to all users, the request will be authorized and the page returned to the user, with a CMS authentication cookie attached to the response. If there is a valid ASP.NET Forms authentication cookie, the request is passed to the CMS Authorization Module, which checks whether a valid CMS authentication cookie is attached to the request. If both cookies are valid, the CMS Authorization module checks the mapped Windows user account rights, and if the Windows user is authorized, access is granted to the resource. Otherwise, CMS returns an access denied error to the application. If either of the cookies is not found or is invalid, the request is redirected to the login page using an HTTPS URL, where the user enters the required credentials. The login page verifies the credentials against the external source for example, using an event handler in global.asax. If authentication fails, an access denied error is returned to the login page, which displays a message to the user, usually within the login page itself for example, "Sorry, your login failed. Please re-enter your credentials." If the user credentials are successfully authenticated, the mapping to the Windows account takes place. The login page then authenticates and authorizes the Windows account in CMS, redirects the user to the originally requested page, and attaches two cookies to the outgoing response: an ASP.NET Forms authentication cookie and a CMS authentication cookie.
|
