| A CMS extranet site is an external site that is available to predefined users only. All users must be authenticated; there is no anonymous or guest access. For example, an extranet site can be used by your company and its preferred business partners, but will be closed to anybody else. Although it is an external site, only authorized employees of your company and the partner companies are able to use it. Because we cannot control other companies' environments, a common browser standard cannot be guaranteed. We will start with looking into the security settings for an extranet site with forms-based authentication; we will then concentrate on an extranet site with certificate-based authentication. Extranet Sites with Forms-Based Authentication This form of authentication is normally used for CMS production servers on an extranet. A CMS production server in an extranet environment must explicitly authenticate all users; there is no guest access. Because an extranet CMS site usually needs to serve a variety of clients, the most flexible authentication mechanism is forms-based authentication over SSL. It is likely that all extranet users will have Windows accounts; therefore, your login page will use the CmsFormsAuthentication. AuthenticateAsUser(AccountName; AccountPassword) method with the user-supplied credentials for authentication However, if the extranet users do not have Windows accounts for example, because of your company security policy restrictions you may be required to map the extranet user credentials into Windows accounts that are created to reflect the type of users. These accounts are sometimes referred to as role-based accounts because we create one Windows account for each type of user based on the role they can play on our site. Usually, the user credentials are held in a dedicated SQL database. In this case, you will need to write event handlers to authenticate the users against the SQL-held data, and then, if they are authenticated, map the request to a Windows account based on the user role on the site. The user role must be held in the SQL database as well. Then, the login page will use the CmsFormsAuthentication.AuthenticateAsUser (ServerAccountName, ServerAccountPassword, ClientAccountName, ClientAccountType) method with the mapped account credentials, the user-supplied user name, and the user role extracted from the database. As always in CMS, configuring security for a production site involves several layers. IIS security: Configure IIS for anonymous access. Install the server certificate and enable SSL on port 443 on your server. The certificate must be issued by a CA that will be recognized by all companies using the site. Create a virtual directory on your server for example, /login and enable SSL for this directory.
ASP.NET security: Authentication: Create a login page that authenticates the user using the CmsFormsAuthentication.AuthenticateAsUser method and verifying that the returned CmsAuthenticationTicket is not null. 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 for 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. 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, disable guest access. CMS system account permissions: Verify that the CMS system account has permissions to view the tree in the AD domain where the AD accounts for either the site users or mapped user roles, in the case of mapped authentication, are defined. CMS user rights: Using the Site Manager, create subscribers rights groups for each type of user access to the site. If your users have AD accounts, create an AD group for each type of access and add these groups to the appropriate subscribers groups. If you are using AD mapped accounts, add these accounts to the appropriate subscribers groups one account to one group. 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.
CMS authentication cookie encryption keys: If CMS is deployed in a Web farm, use the Managekey utility to synchronize the CMS authentication cookie encryption keys between the servers. ASP.NET Forms authentication cookie encryption and validation keys: If CMS is deployed in a Web farm, synchronize the settings in the <machineKey> element in each server's machine. config file.
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 it is, 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, and if they are authenticated, attaches two cookies to the response: 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."
Extranet Sites with Certificate-Based Authentication This form of authentication is used when CMS authoring servers are accessible using an extranet. So far, we have seen content authoring done on an internal network. However, often content authors and editors are required to submit content over the Internet. Sometimes, to save costs, production and content authoring environments may be combined and run on the same servers. More frequently, they run on different machines but share the same database. An externally accessible CMS authoring server usually has security settings similar to those of an extranet production server. The IIS security settings, ASP.NET security settings, NTFS permissions, and CMS system account permissions are the same; and CMS guest access should be disabled as for a production server. However, the CMS user rights are different. For content authoring servers, you need to set up the publishing workflow. Depending on your environment, you may need to create one or more of authors, editors, moderators, resource managers, and channel managers rights groups and assign them to appropriate containers to reflect your user privileges on the site. You may also need to create at least one subscribers group so that the content authors are able to test their work. There are scenarios where additional security is required for content authoring servers. It usually happens in a business-to-business (B2B) environment, where a publishing workflow break-in represents a serious security threat for both companies involved. If this is the case, then Certificate authentication can be used. With such high security requirements, all authorized users must either have their own Windows accounts or be mapped to Windows accounts. User certificates can be mapped to Windows accounts on either a one-to-one or a many-to-one basis (many certificates to a single account). In order to be able to map certificates, you need to have a copy of all the certificates the users are going to use when connecting to your server. If you don't want to map certificates, or if you are required to provide two-step authentication both by a certificate and by a user entering their credentials then instead of certificate mapping, you can enable Basic authentication in IIS. In this case, each user must have a security account; user credentials are validated against this account. To configure a CMS server for Certificate authentication, consider the following steps: IIS authentication: Install the server certificate and enable SSL on port 443 on your server. The certificate must be issued by a CA that will be recognized by all companies using the site. For the directory that hosts your CMS Web application, enable secure communications, and specify that client certificates are required. You may need to enable a certificate trust list (CTL) to define the certification authorities from which you accept certificates. If you need two-step authentication, configure IIS for Basic authentication. If you don't need two-step authentication, enable certificate mapping and map the certificates to the Windows accounts.
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: Depending on your requirements, you may need to configure ASP.NET impersonation in web.config for example: <impersonate="true"/>
NTFS permissions: Set up read permissions for the appropriate Windows accounts on the template files and the static site files. 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 where either the user accounts or the accounts mapped to the certificates are maintained. CMS user rights: Using the Site Manager, create CMS rights groups within CMS roles to reflect your publishing workflow. Assign the CMS rights groups you've created to the appropriate containers.
Cookie encryption keys: If the CMS site is deployed in a Web farm, use the Managekey utility to synchronize the CMS authentication cookie encryption keys between the servers. To synchronize the ASP.NET Forms authentication cookie encryption and validation keys, use the settings in the <machineKey> element in each server's machine.config file.
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 request using the client certificate. If the client does not present a valid certificate issued by a CA listed in the CTL, the request is denied. If the certificate is accepted, then one of two things happens: If Basic authentication is enabled, the user supplies a user name and password; then IIS authenticates the user credentials against a Windows account. If certificate mapping is enabled, the user certificate is mapped to a Windows account. The user identity is 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 the template file authorization and then are passed to the CMS Authorization module. The CMS Authorization module calls the CMS content server to authenticate the user and to define 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.
|
