Security In Cross Domain Web Services

(Eiditor's Note: This is part 1 of a multi part post on Cross Domain Web Service Security)

So what is the problem?

Today, small tobig sized enterprises end up with multiple domains due to various technical and business reasons. Creating a forest trust between two Windows Server forests provides a one-way or two-way, transitive trust relationship between every domain residing within each forest.

This inevitably results in the need to move data between those domains, which can be a challenge in the security realm if there isn’t a trust between those domains. The wide scale adoption of web services to exchange data in such situations has resulted in a new challenge – Security in cross domain web services.

We will try to illustrate some of the wide array of approaches available today which we have seen used in the Microsoft.com team at Microsoft. Let’s get some basic terminology out of the way first.

Terminology

We are assuming you are familiar with the following terms. The explanations are fairly well understood, and we will leave this out in the interest of brevity.

· Domain, Forest

· Confidentiality, Integrity, Authentication

· Web service, SOAP

Solutions – The Stack

At Microsoft.com, we have typically design our security approach as an amalgamation of security in three layers. This can be illustrated as a stack below:

Figure: Security Stack or Defense in Depth

This is roughly aligned with the OSI stack:

· Host Layers: Web Service, OS and Domain, Transport

· Media Layers: Network Layer.

 A “living" layered security infrastructure is certainly not a static, one-size-fits-all proposition. As network environments become more complex--involving partner extranets, VLANs, application portals, Web services, secure remote connectivity, Internet/POP mail, instant messaging and so on--architecting defense-in-depth into the strategy becomes more and more difficult. We will attempt to cover the web service related security aspects below in this first part of the blog.

Web Service Security Strategies:

 

Figure: Web Serices Enhancements 

Web Services Enhancements (WSE) 2.0 for Microsoft .NET provides benefits such as end-to-end message-level security, content-based routing, and policy by leveraging the WS-Security, WS-Addressing, and WS-Policy specifications. WSE is an implementation of many of the WS-* specifications as defined by WSS (WS-Policy, WS-Trust, WS-Privacy, WS-Secure Conversation, WS-Federation, and WS-Authorization.).

WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies.

We have a set of Secure Services that are used to create Web Services Enhancements (WSE) security tokens which hold user and/or application identity information. Our secure Services accept these tickets to authenticate users and applications.

To use Secure Services ticket authentication, Internet Information Services (IIS) is configured for anonymous access and Secure Services components are used to perform authentication instead of IIS.)

Secure Services tickets are useful because they may cross domain boundaries. In contrast, typical auth and auth credentials do not flow well across domain boundaries because their cookies are generally scoped to a specific domain. Remember, we are discussing the typical case where Trust Relationships aren’t involved – say in extranet communication.

Windows credentials are also problematic when crossing domain boundaries because the Active Directory server for the Windows domain is not accessible from the computers with services in other domains.

The Police Interceptor (PI):

We have a PI which is a WSE SOAP extension which intercepts Web Services calls before the Web Method is allowed to execute. The PI examines the caller’s credentials before allowing the web method to execute. An XML authorization policy file is used to specify authorization requirements for each web method in the web service. Any caller of the web service must authenticate and supply the correct credentials specified in the authorization policy file for the web method to be authorized. If not authorized, the web method is not invoked and an error result is returned to the caller. The PI may also be configured to construct a custom object which is available to the web method to perform additional authorization checks if necessary.

Here is an illustration for a tenant made web service using the Secure Services PI to perform authorization:

Custom SOAP Extension Authorization 1

1. Web Service makes a call to another cross domain service with credentials.

2. The PI intercepts the SOAP Request, and compares auth info for the web method specified in the XML policy file.

3. In very few cases, a web method will do additional checks if necessary.

4. A return value (error or web method result ) is returned.

We can see that WS-* specifications can be used to compose various components to build a wide array of security architectures using a variety of technologies. We believe that WS* is a vital part of the security stac in order to have a holistic approach to Web Service Security.

The security architect or team for enabling WS*-should plan for integration with existing business processes and technology sets while being agile in adapting to the dynamically changing nature of security requirements of your enterprise applications.

Such custom SOAP extensions by extending and leveraging existing security technology and assets will enable customers and organizations to more rapidly develop secure, interoperable Web Services.

In the next part of the blog, we will visit the other Security Techniques we can leverage to make cross domain WS’s more secure.

Till then, keep safe.

Comments

• Anonymous
  May 08, 2007
  I like how you layer all 3. Very often we forget that we can use windows and domain and network security. I like the idea of  a soap extension - we are currently using network permissions.