- Measuring Return on Investment for Content Management
- Content Management Options
- Site Framework for Content Management
- Content Management Server Overview
- Site Framework for Content Management Server
- Starting the Portal Site in MCMS
- Creating Templates
- Content Creation and Approval Process
- Defining Channels
- Multilingual Sites
- Web Page Workflow Implementation
- Enabling Security on MCMS
- .NET and Web Services Integration
- Content Management in SharePoint
- Integrating SharePoint with Microsoft Content Management Server
- Custom Content Management
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Enabling Security on MCMS
Because MCMS is so important for all types of portals, it is likely to be the first line of defense in your security scheme. The information and guidance offered in Chapter 6 apply here as well. This section provides special notes regarding security implications for MCMS. You must configure access in three locations: Internet Information Server (IIS), ASP.NET Web.config file, and the MCMS Server Configuration application. The entries you make in these locations depend on the usage scenario and your security preferences. These guidelines are for the most common scenarios.
Internet
A public web site should be available to anonymous users, with no authentication required. By default, a new MCMS site requires user authentication, even to view pages. To make your site visible to guests (anonymous users), you must change the configuration from the default as follows:
-
In the ASP.NET Web.config file, remove or comment out the following line:
<add type="Microsoft.ContentManagement.Web.Security. _ CmsAuthorizationModule, Microsoft.ContentManagement. _ Web, Version=5.0.1200.0, Culture=neutral, _ PublicKeyToken=31bf3856ad364e35" _ name="CmsAuthorizationModule" />
-
In the MCMS Site Manager, create an account to use as the guest account, and add this account to the subscribers rights group.
-
Go to the MCMS Server Configuration application in the MCMS program group and click Security.
-
In the Guest Visitors section of the Security Configuration dialog box, click the Yes radio button for Allow Guests on Site. Enter the name of the account to use as the guest account for the site.
If you want to provide some content exclusively to authenticated users, you can follow the guidelines in the following extranet section in addition to allowing anonymous users.
Intranet
Intranet sites use integrated Windows authentication. MCMS supports both Active Directory and Windows NT authentication. Integrated Windows authentication is suitable under the following conditions:
-
All users have Windows NT or Active Directory accounts.
-
The intranet is located inside the firewall.
-
The entire site requires authentication and does not allow anonymous users.
-
All users use Internet Explorer to access the intranet.
As you might imagine, Integrated Windows security is quite secure and even allows users to authenticate the servers that are attempting to authenticate them. It also spares the user from entering a username and password by using the current user information on the client computer for authentication. Of course integrated security also means one fewer username and password combination to manage for the user.
Extranet
Now that you know how to handle security for an intranet and an Internet site, the case of the extranet is simple, as it is nothing more than a combination of the two, with a portion of the site allowing anonymous access along with a private, secured channel that is accessed via the Internet.
The baseline configuration for the extranet is the same as for an Internet site. Handle all the pages that are unrestricted in the same way as you would for any public site. This part of the site should support multiple browsers and not be based on browser-specific technology such as ActiveX controls.
The restricted access sections should be protected with MCMS rights groups. This means that the administrator must grant access to the user of a particular channel, folder, or gallery using the MCMS Site Manager. For instance, you could grant author rights to the legal notices section of a site to the legal department.
You may want to configure MCMS as an extranet to enable access for content managers. By doing so, you allow your site to be maintained from remote locations rather than just by users in your domain. For instance, content authors could create new pages and editors could participate in page review from home.
There are three general approaches to authentication on an extranet: forms-based authentication, digital certificates, and custom authentication schemes. You can combine these approaches with one another (for more on choosing an approach, see Chapter 6). The following examples show how you can use these authentication approaches to grant access on an extranet to MCMS administrative functions.
Forms-based authentication uses a cookie that stores a ticket indicating that a user has been authenticated. The system checks the cookie first on subsequent access attempts. You should use secure sockets layer (SSL) to protect the contents of the cookie so users cannot falsify that they have been authenticated. Remember that SSL imposes a performance penalty, so don't apply it to pages where anonymous access is granted anyway.
Forms-Based Authentication
Forms-based authentication routes unauthenticated users to an HTML form in which they enter their credentials. When authentication succeeds, a cookie is written and they are granted access to subsequent pages upon request. Chapter 6 provides examples of how to implement forms-based authentication. The basic steps are:
-
Design a logon page in Visual Studio.NET. Define fields for the username and password along with a Submit button. Be sure to use the Password field as the control to accept the password.
-
Right-click each of the controls dropped onto the page, and select Run As Server Control.
-
Add the following code to the Submit1_ServerClick event handler:
CmsAuthenticationTicket ticket; ticket = _ CmsFormsAuthentication.AuthenticateAsUser _ (strServerAccount, strServerPassword, txtUserName.Text, "FirstName"); if( ticket != null ) { string strReturnUrl = _ Request.QueryString["ReturnUrl"]; CmsFormsAuthentication.SetAuthCookie(ticket, true, _ false); StringBuilder strUrl = new StringBuilder(); strUrl.Append("http://"); strUrl.Append(Environment.MachineName); strUrl.Append(strReturnUrl); Response.Redirect(strUrl.ToString()); } else { Label1.Text = "Your username or password are _ incorrect. Please re-enter your username and _ password."; } -
Add the following code to the Page_Load handler:
if(!Request.IsSecureConnection) { StringBuilder strSSL = new StringBuilder(); strSSL.Append("https://"); strSSL.Append(Environment.MachineName); strSSL.Append("/"); strSSL.Append(Request.Url.PathAndQuery); Response.Redirect(strSSL.ToString()); } -
Save your changes and build the solution.
Digital Certificates
Certificates are digital keys installed on a particular workstation. They contain information that uniquely identifies the user to applications accessed by the workstation. Certificates can be mapped to Active Directory or Windows domains. Users are issued certificates by a certificate-issuing authority, and these certificates are downloaded to their workstations. Windows 2000 comes with a certificate server so you can manage certificates.
The key difference between forms-based security and digital certificates is that certificate-based authentication does not require the user to enter authentication information on a login page. Authentication is more seamless and virtually invisible to the user. Therefore, certificates are more appropriate for processes that have no human user at all, such as the automation of the supply chain to post orders from a buyer to a seller.
You can set up your site so users without certificates are treated as anonymous users while those with certificates are mapped to the permissions and roles of the certificate user. You can establish unique certificates for each individual user or map many users to a single account. For more information on certificates and Windows security, see TechNet security how-tos at www.microsoft.com/technet/itsolutions/howto/sechow.asp and Michael Howard's book Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press, 2000).
Custom Authentication
The third form of authentication for extranets is custom authentication. This approach uses another directory service and maps users back to related Active Directory accounts. For instance, user information might be stored in Commerce Server for means of site personalization. Users might be authenticated by a third party such as Microsoft Passport. The custom security scheme would then look up the appropriate Active Directory account and grant permissions based on that account.
Custom authentication is the least commonly used form of the authentication approaches discussed here. This approach may be selected when there is a limited amount of content or functionality to provide to authenticated users, and the site is therefore rather simple to administer.
Although it is technically possible, I do not recommend using databases to store authentication information. Active Directory and other directory servers are more hardened to security threats.