Accessing Secured Web Services from Windows SharePoint Services Applications

  • Article

 

Peter Vogel
PH&V Information Services

August 2004

Applies to:
    Microsoft Windows SharePoint Services

Summary: Show how to access a secure Web service from a Microsoft Windows SharePoint Services application under Microsoft Windows Server 2003 and Windows Server 2000. (8 printed pages)

Contents

Overview
Implementing Delegation
Configuring Delegation in Windows Server 2000
Conclusion

Overview

In a service-oriented environment, managing the security credentials for an application that is accessing a Web service is a critical issue. This article describes how you can use the Kerberos version 5 authentication protocol and impersonation to secure a Web service accessed by a SharePoint application to ensure that only properly authenticated and authorized users have access to the Web service in Windows Server 2003 and Windows Server 2000 environments.

Scenario

Figure 1 shows an example of the problem: A user on a client workstation (on the left of the diagram) accesses a Microsoft Windows SharePoint Services application on the remote server (in the middle of the diagram). The user will have logged onto their workstation by providing a set of credentials explicitly (for example, a user ID and password) that the operating system can validate and use to assign an identity to the user. Or the user may have logged on to his or her workstation and, through Windows authentication, have his or her credentials presented to the application server on user's behalf (a kind of implicit logon because the user does not type the credentials). This logging on process authenticates the user to the desktop workstation.

When the user requests a page from the SharePoint application, the user must also be authenticated to the SharePoint server. In a Microsoft Windows intranet environment, with the SharePoint server using Windows Integrated security, the user's credentials from the client workstation will be requested and validated through the Kerberos version 5 protocol (for legacy clients that don't support Kerberos, the NTLM/challenge-response authentication protocol is used). After the user has been authenticated on the SharePoint server, the user's identity is checked against the SharePoint application's permissions list. If the user is permitted to access the application, the requested page is sent to the user. From the users' point of view, signing onto their workstation has given them access to the SharePoint application on another server.

Figure 1. Typical scenario requiring delegation of user credentials

After the user has logged onto the server, acquired an identity that is permitted to use the SharePoint application, and been permitted to access the application, the SharePoint application requests services from a Web service running the Web service server (on the right of the diagram). The SharePoint application must log onto the Web service's server and acquire an identity that the Web service's permissions will allow to use the Web service.

By default, SharePoint applications take on the identity of the user who logged onto the application server (provided that anonymous access for the SharePoint application has been turned off). The SharePoint application will use the user's identity to access the Web service. However, because the NTLM authentication protocol does not allow delegation of credentials, the user's credentials from the client computer cannot be passed on automatically by the SharePoint application to the Web service server. Without those credentials, the SharePoint application cannot successfully log on to the Web service server and acquire an identity that is permitted to access the Web service. Kerberos provides a solution to this problem.

Kerberos Security

The Kerberos network authentication protocol is designed to provide strong authentication for client/server applications. The Kerberos protocol uses "ticket based" security. A Kerberos service ticket is issued to a user allowing access to a specific secured resource (for example, the SharePoint application running on a Web server). When the SharePoint application accesses a Web service, the application can request a ticket to access the Web service, effectively delegating security from the client straight through to the Web service and extending the single sign-on experience through multiple tiers.

Both Microsoft Windows Server 2000 and Windows Server 2003 implement the Kerberos protocol. On a Windows Server 2003 server where the domain has been raised to the highest functional level (only possible if all domain controllers run Windows Server 2003), a constrained delegation model is available). For a discussion of when it is possible to change the functional level of your domain, see Microsoft Knowledge Base Article – 325894: HOW TO: Raise Domain and Forest Functional Levels in Windows Server 2003).

Note   On Windows Server 2000 or in mixed server domains, only an unconstrained delegation model is available. While the unconstrained model provides a minimal level of support for delegation, the constrained model of Windows Server 2003 is the most appropriate model for application servers. This article focuses on Windows Server 2003.

Implementing Delegation

For this discussion, we will start by assuming that the application and Web services computers are running some version of Windows Server 2003 and are part of the same Active Directory directory service forest. After discussing implementing Kerberos delegation in Windows Server 2003, we will discuss implementing Kerberos delegation in Windows Server 2000.

Note   For more information about implementing Kerberos delegation on other platforms, see Microsoft Identity and Access Management Series.

To implement Kerberos delegation, you must configure the following:

  • The client account to support delegation (this is the default).
  • The computer running SharePoint Portal Server to specify to which services it may present delegated credentials.

Let's walk through the steps to implement delegation.

Configuring the Client Account

To configure the client account

  1. Log on to the domain controller using an administrator account.

  2. On the Administrative Tools menu, click Active Directory Users and Computers.

  3. Under the domain for the user, find the user in the Users folder.

  4. Right-click the user you want and then click Properties.

  5. On the Account tab, ensure that the Account is sensitive and cannot be delegated check box is cleared (figure 2). This is the default.

    Figure 2. Configuring the client's account in Windows Server 2003

Configuring the SharePoint Application Server

In the Windows Server 2003 constrained delegation model, you specify which services on which servers the SharePoint application computer may present delegated credentials.

Note   For application servers, Windows Server 2003 constrained delegation is more effective and recommended than Windows Server 2000 unconstrained delegation. For more information, see Microsoft Knowledge Base Article – 325894: HOW TO: Configure Computer Accounts and User Accounts So That They Are Trusted for Delegation in Windows Server 2003 Enterprise Edition.

To specify which services should be presented delegated credentials

  1. Log on to the domain controller using an administrative account.

  2. On the Administrative Tools menu, click Active Directory Users and Computers.

  3. In the Computers folder, select the server computer that the SharePoint application runs on.

  4. Right-click the server computer, and then click Properties.

  5. Click the Delegation tab, and then select Trust this computer for delegation to specified services only.

  6. Select Use Kerberos only.

  7. Click Add to open the Add Services dialog box.

  8. Select the services that you want to present delegated credentials.

    The services listed in the dialog box (figure 3) will be presented delegated credentials from the computer.

    Figure 3. Configuring the domain server in Windows Server 2003

Configuring the Web Service

You do not need to configure the Web service's account or server to support delegation. However, you must configure the Web service's permissions to accept the identity used by the SharePoint application. For SharePoint applications using impersonation, you must configure the Web service's permissions to accept the identity of the user who originally requested the SharePoint page.

Configuring Delegation in Windows Server 2000

On Windows Server 2000 or on Windows Server 2003 servers in an environment of mixed Windows Server 2000 and Windows Server 2003 servers, an unconstrained delegation model is supported. In the unconstrained model, you configure the server to delegate credentials to any application on any server. This lack of control on how credentials are passed on to the next tier of the application is less secure than the constrained model implemented in a Windows Server 2003-only domain.

Note   If you must use unconstrained delegation, all server systems should be running Windows Server 2000.

Configuring the Application's Account

To configure the application's account

  1. Log on to the domain controller using an administrative account.

  2. On the Administrative Tools menu, click Active Directory Users and Computers.

  3. Under the domain for the application, find the account in the Users folder that the application runs under.

  4. Right-click the account and then click Properties.

  5. On the Account tab, select Account is trusted for delegation (figure 4).

    Note   For application servers, Windows Server 2003 constrained delegation is more effective and recommended than Windows Server 2000 unconstrained delegation. For more information, see Microsoft Knowledge Base Article - 325894: HOW TO: Configure Computer Accounts and User Accounts So That They Are Trusted for Delegation in Windows Server 2003 Enterprise Edition.

    Figure 4. Configuring the client's account in Windows Server 2000

Configuring the SharePoint Application Server

To configure the SharePoint application server

  1. Log on to the domain controller using an administrative account.

  2. On the Administrative Tools menu, click Active Directory Users and Computers.

  3. In the Computers folder, select the server computer that the SharePoint application runs on.

  4. Right-click the server computer, and then select Properties.

  5. On the General tab, select Trust computer for delegation (figure 5).

    All services in the domain can now be presented delegated credentials from any application running on the computer. The absence of the ability to limit which applications to trust makes the Windows Server 2000 unconstrained delegation model less effective than the Windows Server 2003 constrained model.

    Note   The unconstrained delegation model in Windows Server 2000 is not the recommended approach. For more information on the constrained delegation mode in Windows Server 2003, see Microsoft Knowledge Base Article - 325894 - HOW TO: Configure Computer Accounts and User Accounts So That They Are Trusted for Delegation in Windows Server 2003 Enterprise Edition.

    Figure 5. Configuring the application server in Windows Server 2000

Conclusion

We have described how, on Windows Server 2003 and Windows Server 2000, you can use the Kerberos version 5 authentication protocol and impersonation to secure a Web service accessed by a SharePoint application to ensure that only properly authenticated and authorized users have access to the Web service. The constrained delegation model available in Windows Server 2003 environments provides the highest level of control and is the recommended practice. However, in Windows Server 2000 or mixed Windows Server 2000/Windows Server 2003 environments, the unconstrained delegation model can help provide a minimal level of access control.

About the Author

Peter Vogel (MBA, MCSD) is a principal in PH&V Information services. PH&V specializes in .NET and XML development. Peter has designed, built, and installed intranet and component-based systems for Bayer AG, Exxon, Christie Digital, and the Canadian Imperial Bank of Commerce. He is also the editor of the Smart Access, wrote The Visual Basic Object and Component Handbook (Prentice Hall), and is currently working on a book on Web Parts for SharePoint Services and ASP.NET 2.0 (Wrox). Peter teaches for Learning Tree International. His articles have appeared in every major magazine devoted to Visual Basic-based development and in the Microsoft Developer Network (MSDN) Library. Peter also presents at conferences in North America, Australia, and Europe.

This article was developed in partnership with A23 Consulting.