| A CMS intranet site is only accessible by users within a company's corporate network. The site may be very simple, or it may be big and complex. In an intranet environment, all users have Active Directory accounts, and it is usually possible to assume that everyone uses a common browser standard. It is also a common assumption that users can be authenticated using their Windows credentials. NOTE: For CMS internal sites, it is a good practice to use AD groups to organize and manage CMS users according to their roles in the publishing process as well as their rights to parts of the site.
There are different authentication mechanisms that can be used for internal sites. If there are no firewalls for internal traffic on your company network, and you can control the installation of IE on users' Desktops, then IIS Integrated Windows authentication may be the authentication method best suited for your environment. Windows authentication provides a high level of security, and because of the automatic logon feature in IE, users will not be prompted to enter their credentials if they are already logged on. Authentication credentials are maintained for the browser session; therefore, the only way to log off is to close the browser; there is usually no logon/logoff link on the site. However, in certain scenarios in an intranet environment, Windows authentication is not suitable for example: You have a variety of browsers in your organization. You have a complex network topology that spans multiple sites and uses firewalls, even for internal traffic. The security policy in your company requires separation of the operating system logon from an application logon.
If any of these apply to you, then instead of Windows Authentication, you can use either IIS Basic authentication over SSL, or IIS Certificate authentication, or ASP.NET forms-based authentication over SSL. The most frequently used method is ASP.NET forms-based authentication for several reasons. Basic authentication is supported by all browsers; it is widely used and easy to configure. However, if you want to use Basic authentication on your site, you have to enable SSL because otherwise user credentials are sent unencrypted from the browser to the server. With Basic authentication, SSL must be enabled on all site resources. This creates overhead and leads to performance degradation because all traffic between the client and the server is encrypted for all site resources. Certificate authentication requires that all users have their certificates issued and installed in their browsers. This means, among other things, that your company must have a Public Key Infrastructure (PKI) environment that issues, renews, and revokes user certificates. PKI companywide systems are quite costly to maintain and manage, and they are not very widely used. Although server-side certificates are commonplace and are used everywhere in a corporate environment, client-side certificates are usually issued only when business needs require enhanced security; not all company employees who are likely to use the CMS intranet site will have them. Forms-based authentication is the most flexible authentication mechanism. It does not require certificates on the client side, and it requires SSL only for the login page itself so that user credentials are encrypted for transfer between the browser and the server. You may of course use SSL for the rest of the site for additional protection if required. This leaves us with two authentication mechanisms widely used on CMS intranet sites: Windows authentication, and forms-based authentication. Configuring security for a CMS intranet site includes configuration and settings on multiple layers. The authentication method defines some of them, but not all. Let's look into how to configure CMS intranet site security for each of the authentication methods. Internal Sites with Windows Authentication To set up security for your internal site using Windows authentication, consider the following steps. IIS authentication: Configure IIS for Integrated Windows authentication. Disable anonymous access. ASP.NET security: Authentication: Configure ASP.NET for Windows authentication. To do this, open the web.config file from the root on the CMS Web application and make sure that the following is configured in the authentication section: <authentication mode="Windows"/> Authorization: Configure ASP.NET to deny anonymous access. Make sure that the following element is added to the web.config authorization section: <authorization> <deny users="?"/> <authorization/> Impersonation: Decide how you want the CMS application to access resources such as files, registry keys, and the Active Directory: as an IIS authenticated user, with the default worker process identity, or with a fixed process identity that is different from the default (refer to Chapter 19 for details on ASP.NET impersonation). Depending on your decision, configure ASP.NET impersonation in web.config for example: <impersonate="true"/>
NTFS permissions: Set up read permissions for Active Directory user accounts on site files, including template files and static files, such as images, cascading style sheets, and client-side JavaScript. CMS guest access: Using the SCA, disable guest access to CMS. CMS system account permissions: Verify that the CMS system account has permissions to view the tree in the AD domains to which the site users belong. If the intranet site is companywide, the CMS system account needs to have enumeration rights on all AD domains that maintain user accounts. CMS user rights: Create CMS rights groups: Using the Site Manager, create CMS rights groups within CMS roles; add Active Directory user and group accounts to these rights groups. It is a good practice to create AD security groups for CMS-specific roles, add user accounts to these groups, and then add these groups as members of the CMS rights groups. This approach allows you to use only AD for maintenance of user rights in the CMS environment. For example, create an AD security group called CmsGeneralUsers and add to it all groups and user accounts that are allowed to browse the general areas of the site; if you want all employees to be able to browse the general areas of the site, add a Domain Users group for all AD domains. Then, create an AllSiteSubscribers rights group within the CMS subscriber role, and add the CmsGeneralUsers AD group as a member of the AllSiteSubscribers CMS rights group. Create another group called CmsFinanceUsers and add accounts of all employees who work in the finance department. Then create a FinanceSubscribers rights group and add the CmsFinanceUsers AD group as a member of the FinanceSubscribers CMS rights group. If you want to change who is allowed to browse the general area of the site, you only need to change the membership of the AD group CmsGeneralUsers. Similarly, if you want to change who is allowed to browse specific financial areas on the site, you only need to change the membership of the AD group CmsFinanceUsers. Although this approach requires some planning for mapping between CMS rights groups and AD groups, this is only a one-off effort. After the initial stage, the management of such an environment is much easier and cleaner than managing multiple individual users' AD accounts within the CMS rights groups. You may need to set up different groups for production, authoring, and development sites. For production sites, you need to set up at least one subscribers group. Depending on the business requirements for the site, you may need to set up more than one subscribers group so that you can grant different group rights to different parts of the site. For content authoring sites, you need to set up the publishing workflow for the site. Depending on your environment, you will need one or more authors, editors, moderators, resource managers, and channel managers groups. You will also need a subscribers group for full site testing so that, for example, authors can see the parts of the site to which they don't have authoring rights. For development sites, you need at least one template designers group and a subscribers group for testing. Assign rights groups to the site containers: After you've created the CMS rights groups, you need to assign them to containers, such as channels, template galleries, and resource galleries. User rights are defined by the role to which the group belongs. Continuing with our example, you will need to assign the AllSiteSubscribers rights group to the parts of the site that provide general information available to all intranet users, and the FinanceSubscribers rights group to the part of the site that contains information for the finance department only.
On a CMS site that is configured following these steps, processing of a page request includes the following authentication and authorization sequence: IIS authenticates the client request using Integrated Windows authentication; the user credentials are passed to the worker process. The CMS Web application is configured to use ASP.NET Windows authentication; therefore, the user credentials from IIS are used for template file authorization and then are passed to the CMS Authorization module. The CMS Authorization module calls the CMS content server, which authenticates the user and defines the CMS rights group membership for this user. If, based on the role permissions for the groups the user is a member of, the user is authorized, then access is granted to the resource, and a CMS authentication cookie is attached to the HTTP response. Otherwise, an access denied error is returned to the Web application and then to the user.
Internal Sites with Forms-Based Authentication With forms-based authentication, some of the security settings are similar to those for Windows authentication. However, others are quite different. To set up security for your internal site using forms-based authentication, consider the following steps. IIS security: Configure IIS for anonymous access; enable Integrated Windows authentication as well. Anonymous access will be used for page processing and forms-based authentication. However, static site files, such as cascading style sheets or images, are not processed by ASP.NET. Therefore, we need to enable Windows-based security for these files. Install the server certificate and enable SSL on port 443 on your server. Create a virtual directory on your server for example, /secure and enable SSL for this directory. After you've enabled SSL, all files in this directory are available only using HTTPS. For example, if there is a file called test.htm in the /secure directory, to obtain a page, the following URL should be used: https://<server name>/secure/test.htm.
ASP.NET security: Authentication: Create a login page that authenticates the user against AD security accounts for example, by using the CmsFormsAuthentication.AuthenticateAsUser(AccountName; AccountPassword) method with the user-supplied credentials and verifying that the returned CmsAuthenticationTicket is not null. Refer to Chapter 19 for the sample code. Save the login page in the HTTPS-enabled virtual directory for example, as /secure/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>/secure/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 identity account has at least read permissions on the templates. Set up permissions for AD users on the static site files that are not stored in the resource galleries for example, cascading style sheets and JavaScript files. That's why we enabled Integrated Windows authentication on IIS in step 1, so that the NTFS permissions are used for authorization of access to these files.
CMS guest account: Using the SCA, enable guest access and specify the guest account. This account will be used for browsing the general areas of your site available to all users. CMS system account permissions: These settings are the same as before. Verify that the CMS system account has permissions to view the tree in the AD domains to which the site users belong. If the intranet site is companywide, the CMS system account needs to have enumeration rights on all AD domains that maintain user accounts. CMS user rights: Create CMS rights groups: Using the Site Manager, create CMS rights groups within CMS roles; add Active Directory user and group accounts to these rights groups. As before, it is advisable to create AD security groups for CMS-specific roles and add user accounts to these groups; then add the AD group to the CMS rights group. This approach allows you to maintain the membership of CMS rights groups within the Active Directory, by adding or deleting user accounts to or from the AD security groups. However, with forms-based authentication, you don't have to create a companywide group for all site users; you can use the CMS guest account instead. You may need to set up different groups for production, authoring, and development sites. For production servers, set up a subscribers group and add a CMS guest account to this group. Depending on the business requirements for the site, set up another subscribers group for protected areas of your site. For content authoring servers, you need to set up the publishing workflow for the site. Depending on your environment, you will need one or more authors, editors, moderators, resource managers, and channel managers groups. Make sure you set up a subscribers group with a CMS guest account for site testing. For a development environment, you need at least one template designers group and a subscribers group containing a CMS guest account for testing. Assign rights groups to the site containers: After you've created the CMS rights groups, you need to assign them to containers, such as channels, template galleries, and resource galleries. Assign the subscribers group with the CMS guest account to all containers; assign other groups to containers as appropriate.
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 to see whether a valid Forms authentication cookie is attached to the request. If not, it tries to pass the worker process default account identity (ASPNET) to the CMS Authorization module. The CMS Authorization module checks whether guest access is enabled and attempts authorization of 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 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 user rights, and if the user is authorized, access is granted to the resource. Otherwise, an access denied error is returned to the application. If either of the cookies is not found or is invalid, the user 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 AD domains and the CMS server, and if they are authenticated, it attaches two cookies: an ASP.NET Forms authentication cookie and a CMS authentication cookie. 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, "Invalid user name/password. Please re-enter your credentials."
|
