Authentication and Authorization

In CMS, every user is associated with a Windows account. The identity of a user is verified through authentication, and then access to the requested site resources is authorized according to the rights associated with the user's account.

As we have already discussed, authentication and authorization in CMS spans multiple layers, including IIS, ASP.NET, and CMS server. Figure 20-3 shows the high-level logical architecture of the CMS authentication and authorization process for accessing Content Repository objects. Access rights for objects on the file system are defined by NTFS permissions; this process is not shown in Figure 20-3 for simplicity.

Figure 20-3. CMS authentication and authorization process

When setting up authentication and authorization for your site, you need to consider the security settings on the following layers:

• IIS security: Considerations include IIS authentication mechanisms and use of SSL. We discussed IIS authentication mechanisms in the previous chapter; in this chapter we will focus on their use in different scenarios.

• ASP.NET security: Considerations include ASP.NET authentication, authorization, and impersonation settings and their configuration at different levels. Once again, we discussed ASP.NET security mechanisms in the previous chapter; in this chapter we will concentrate on using them in different ways in different scenarios.

• CMS content server security: Considerations include enabling or disabling guest access to the site, creating CMS rights groups within CMS roles, adding members to these rights groups, and assigning the rights groups to the site containers.

  After a user has been authenticated, CMS right groups membership defines user access to containers such as channels, template galleries, and resource galleries. Refer to Chapter 17 for a detailed discussion of setting up user rights.

  In ASP.NET-based sites, the CMS Authorization HTTP module enables CMS Web applications to use CMS content server authentication and authorization.

• NTFS permissions: Considerations include setting up access to site files such as ASPX template files and static site files for example, images, cascading style sheets, and client-side JavaScript files.

  Depending on the combination of IIS authentication configuration and ASP.NET authentication and impersonation settings, the ASPX files must have at least read permissions for either the default worker process account or the IIS impersonation account IUSR_<machinename>, or the appropriate Windows user accounts.

  For static site files, you need to consider setting up permissions in a different way, simply because these files are not processed by ASP.NET. Depending on whether anonymous access is enabled in IIS, the static site files that are not stored in the CMS resource galleries must have read permissions for either the IIS impersonation account IUSR_<machinename> or the appropriate Windows user accounts.

  We looked into CMS user identities and the necessary NTFS permissions in the previous chapter; in this chapter, we will see examples of assigning these permissions to different accounts.

We will now look into setting up security for CMS sites in different scenarios, as follows:

• Intranet site with Windows authentication

• Intranet site with forms-based authentication

• Internet site with full public access

• Internet site with public access and private areas that use an external authentication source

• Extranet site with forms-based authentication

• Extranet site with certificate-based authentication

NOTE: When we discuss the authorization and authentication of a user request in these scenarios, you may need to refer back to Figure 20-3.