Securing Client Communications

Having a secure network and server is not enough to ensure the security of your data. With users working in coffee shops, airports and hotels, we also need to be sure that their data is encrypted on its way from their clients to the servers in your datacenter. Once we have made sure that the packets going from the client to the server are secure, we then need to turn our attention to the authentication mechanism being used to determine who is at the other end of the connection as well as what they will be able to do once connected. Some authentication methods are more secure, while others will perform better across a network. Business and environmental factors must be assessed before selecting the best method for an organization.

In this section we review the various authentication methods available and provide suggestions and guidance to help you select the best way to communicate with the clients in your environment. We wrap the section up with the steps need to successfully configure SSL.

Authentication

A client connecting to MOSS or WSS can take the form of a Windows PC saving a document from Word or the same PC uploading a document to a WSS site via a browser. A client may also be a hand-held device accessing MOSS via a mobile URL or a Mac PowerBook accessing a site page via a Mac browser. There are many client options for access to MOSS and WSS, but only a limited number of supported authentication methods.

The default method is Windows Authentication, but MOSS 2007 supports multiple authentication methods as shown in Table 10.2.

Forms-based authentication

Another of the exciting features of MOSS is forms-based authentication. This is a pluggable feature based on ASP.NET 2.0 that allows your users to authenticate without an NT Login prompt. Instead, you could build a customized signup/login process to obtain information about your users. Forms authentication uses encrypted cookies and authentication tickets.

Scenarios for successful forms-based authentication implementation are broad, but would include:

• Allowing anonymous and unauthenticated users access to unrestricted, public areas of your sites—an ecommerce store for example.

• Allowing users to fill out a custom form to create a user profile, where they could then log in and access restricted areas of your site—to view previous orders, for example, or to add new items to the catalog if the user had the appropriate role.

The following steps detail how to configure forms-based authentication:

1.	Choose Central Administration Application Management Create or extend Web application, as shown in Figure 10.4. Select Create a new Web application. Fill out the settings as you normally would. Leave NTLM as the Authentication provider and turn on Anonymous Access. Figure 10.4. Create New Web Application screen [View full size image]
2.	Navigate to Application Management Create site collection, as shown in Figure 10.5, and select your Web Application. Leave the creation location as root and enter the username of the Primary Site Collection Administrator and Secondary Site Collection Administrator. This will change later. Figure 10.5. Create Site Collection [View full size image]
3.	Before you change the Authentication Provider, go to your newly created site and log in with the normal NT prompt. Append the URL _layouts/setanon.aspx to the root of your site, which takes you to the Change Anonymous Access Settings page, as shown in Figure 10.6. Set your anonymous access level and click OK. Figure 10.6. Change Anonymous Access Settings [View full size image]
4.	Go to Application Management Authentication providers and select your Web Application. Click the Default Zone. In the Edit Authentication page, set the Authentication Type to Forms and check the Enable anonymous access box (you can leave “select”). For the Membership provider name, enter AspNetSqlMembershipProvider and save the changes.
5.	You can get SQL Server Express and SQL Management Studio from http://msdn.microsoft.com/vstudio/express/sql/. Open a Visual Studio Command Prompt and run aspnet_regsql. This opens the ASP.NET SQL Server Setup Wizard, as shown in Figure 10.7. Figure 10.7. ASP.NET SQL Server Setup Wizard [View full size image] Select Configure SQL Server for application services and click Next. Add your connection information and click Next. Confirm your settings summary and click Next again to create the database. Click Finish.
6.	The next step is editing your web.config files—the one in your SharePoint virtual directory folder and also the web.config for SharePoint Central Administration. You need to add the <connectionStrings> node to both of these files, with the credentials you set up for the database in the previous step. Outside and directly below the <system.web> node in each web.config file, add the <connectionStrings> node: <connectionStrings> <remove name="LocalSqlServer" /> <add name="LocalSqlServer" connectionString="Server=servername;Database=aspnetdb;uid=usern ame;pwd=pass;" providerName="System.Data.SqlClient" /> </connectionStrings>

Now we will add a role and a user to the aspnetdb with which you can log into your site. The painless way of doing this is to open Visual Studio and create a new Web site.

7.	Open Microsoft Visual Studio 2005 and choose File New Web Site. You can keep the default settings in place. Open the web.config created and add your <connectionStrings> node from the previous step. Change the <authentication mode> node attribute to Forms: <authentication mode="Forms" /> Save the file and build your project.
8.	From the Website menu, select ASP.NET Configuration to open the ASP.Net Web Site Administration Tool (Configuration Manager). Click the Security tab. If Roles are not enabled, click Enable roles as shown in Figure 10.8. Figure 10.8. ASP.Net Web Site Administration Tool [View full size image]
9.	When roles are enabled, click Create or Manage roles. You will see the Create New Role screen as shown in Figure 10.9, and then you can add your new role. Figure 10.9. ASP.Net Web Site Administration – Create New Role [View full size image]
10.	Click Backto return to the Security tab. Click Create user and fill out the fields as shown in Figure 10.10. Figure 10.10. ASP.Net Web Site Administration – Create User [View full size image]
11.	Select the role you created and ensure the Active User box is checked. Click Create User. The Security tab should now show one user and one role created, as shown in Figure 10.11. Figure 10.11. ASP.Net Web Site Administration – Security [View full size image]
12.	The last step to take is adding the user you created as the Site Collection Administrator in Central Administration. Navigate to Application Management Site collection administrators, and you will probably see an error upon opening that page that the selected user could not be found. Replace the site collection administrator name with the user you created and press Ctrl+K to check that username, as shown in Figure 10.12. Figure 10.12. Site Collection Administrators page [View full size image]
13.	Open a new browser and navigate to the root of the site collection you created. You should have access to the site without having logged in because you enabled anonymous access. Click Sign In to open the Login Form, and enter your user credentials you created with Visual Studio, as shown in Figure 10.13. Figure 10.13. Sign In page [View full size image]

Web Single Sign-On

The Single Sign-On (SSO) capabilities provided with MOSS allow you to configure stored application passwords for individuals and groups. This offers smooth, integrated access between applications without continual password prompts to irritate users. Additionally, SSO gives you the capability to provide application access to groups of users that you would not normally give individual access to without having to distribute the username and password information. You can embed application integration within SharePoint and provide seamless information access.

The following components of MOSS can leverage SSO capabilities:

• Excel Services

• InfoPath Services

• Business Data Catalog

• Key Performance Indicators

• SharePoint Designer DataForm Web Part

• Custom Web Parts

To configure SSO, follow these steps:

1.	Use terminal services or directly log on to the physical machine that will be the SSO master secret server.
2.	Open SharePoint Central Administration from Start Administrative Tools SharePoint 3.0 Central Administration.
3.	Click the Operations tab.
4.	Select Manage settings for single sign-on in the Security Configuration section.
5.	Select Manage server settings and enter the farm admin account in the Account name field in the Single Sign-On Administrator Account section and the Enterprise Application Definition Administrator Account section.
6.	Enter the timeout value in the Ticket time out (in minutes) field for how long you would like the ticket to stay valid between the time it is issued and the time the enterprise application validates it. The recommended value is 2 minutes.
7.	Click OK.

Starting the Single Sign-On Service

To start the Single Sign-On Service, follow these steps:

1.	For each front-end server and application server, go to Start Administrative Tools Services and select the Microsoft Single Sign-On Service.
2.	Configure the Startup type selection as automatic as shown in Figure 10.14. Figure 10.14. Setting the Microsoft Single Sign-on Service to start automatically
3.	Click the Log On tab, select the This account radio button, and enter your farm admin service account and password, and then confirm the password again.
4.	Click Apply.
5.	Click the General tab and click the Start button.
6.	Click OK.

To create a new SSO encryption key, follow these steps:

1.	Use terminal services or directly log on to the physical machine that will be the SSO master secret server.
2.	Open SharePoint Central Administration from Start Administrative Tools SharePoint 3.0 Central Administration.
3.	Select the Operations tab.
4.	Select Manage settings for single sign-on in the Security Configuration section.
5.	Select Manage encryption key.
6.	Click Create Encryption Key and click OK on the Create Encryption Key page to re-encrypt stored credentials with the new key. This allows user credentials to be stored with the new key without the users having to re-enter their passwords.

To create an enterprise application definition, follow these steps:

To set the password for the application definition, follow these steps:

Modifying your application definition to use SSO

After SSO has been configured, you will need to modify the LOBSystemInstance parameters to use SSO authentication.

 <LobSystemInstances>
  <LobSystemInstance Name="AdventureWorksSampleInstance">
   <Properties>
    <Property Name="AuthenticationMode"
Type="System.String">WindowsCredentials</Property>
    <Property Name="DatabaseAccessProvider"
Type="System.String">SqlServer</Property>
    <Property Name="RdbConnection Data Source"
Type="System.String">ServerName</Property>
    <!-- If you are connecting to an instance use format
       servernameinstance -->
    <Property Name="RdbConnection Initial Catalog"
Type="System.String">DatabaseName</Property>
    <Property Name="RdbConnection Integrated Security"
Type="System.String">SSPI</Property>
    <Property Name="RdbConnection Pooling"
Type="System.String">false</Property>
    <Property Name="SsoApplicationID"
Type="System.String">ApplicationDefinitionName</Property>
<! —This name should match the Application Definition name as
   defined in SSO. -->
    <Property Name="SsoProviderImplementation"
Type="System.String">Microsoft.SharePoint.Portal.SingleSignOn.Sps
   SsoProvider, Microsoft.SharePoint.Portal.SingleSignOn,
   Version=12.0.0.0, Culture=neutral, PublicKeyToken=
   71e9bce111e9429c</Property>
   </Properties>
  </LobSystemInstance>
 </LobSystemInstances>

Implementing SSL

We highly recommend implementing Secure Sockets Layer (SSL) to secure the communications between your client and server computers. If you don’t use SSL, passwords and other sensitive data are at risk as they are sent from the client to the server because the data packets can be picked up by a network-sniffing type of device.

Configuring SSL

The following is a simple example that would apply for some environments. The intent is for you to be able to apply and substitute the steps for your unique situation. Configuring SSL is generally composed of the following steps:

• Creating a server certificate using the certificate wizard. You can also obtain a certificate from a certification authority or from any publicly trusted authority.

• Assigning an existing certificate.

• Creating alternate access mappings in Central Administration.

Creating a new certificate

To create a new certificate, follow these steps:

Assigning an existing certificate

To assign an existing certificate, follow these steps:

Creating alternate access mappings

After you have SSL enabled on your IIS site, you need to add an alternate access mapping so that the site can be accessed via https.

Click Save to complete the process.