WCF Security in the Real World

Applies to: Windows Communication Foundation

Published: June 2011

Author: Robert Dizon

This topic contains the following sections.

• Web Services Security and Federated Security
• Real-World Scenarios
• WCF Security Best Practices and Standards

Summary: This article discusses Windows Communication Foundation (WCF) security. The challenges of real-world applications have encouraged the industry leaders to work together to develop security standards, such as WS-Security and federated security. As implementations of these standards evolve and mature, so does the industry's confidence in its ability to provide secure web services.

Windows Communication Foundation (WCF) was developed by Microsoft® to provide a framework for applications that require message-based interoperability. Among those applications are web services, which are widely used in many enterprises, both as a way to provide features internally, within the company, and externally, to partners and customers. The widespread adoption of web services as a way for entities to communicate means that good security is essential in order to establish trusted relationships.

The article Authentication Boundaries with Unsecured Services explains that web services interact with three domains. They are the service consumer, the service broker, and the service provider. Each domain must satisfy the following security requirements.

• The web service must be able to recognize the identity of the service consumer, and then protect the credentials that make up that identity.

• The web service must be able to authenticate and authorize with the user or the service.

• The web service must protect and preserve the integrity of the message.

WCF satisfies the following security requirements.

• Authorization - the service must be able to verify that an entity can perform a requested action.

• Authentication - the service must be able to verify that an entity is who it claims to be.

• Integrity - the service must be able to ensure that the contents of a message have not been tampered with.

• Confidentiality - the service must be able to hide the contents of a message from everyone except the intended recipient(s).

• Non-repudiation - the service must be able to undeniably associate a message with a specific person or entity.

• Administration and management - the service must be able to centralize and manage security services for users and applications.

Businesses have begun to adopt the following models.

• Business-to-business (B2B) – This model represents commerce transactions that involve goods or services, and that occur with the business's partners. Typically, the transaction occurs as an automated process. Generally, there is a high volume of such transactions.

• Business-to-consumer (B2C) –This model represents a WCF client that provides end consumers with products and/or services.

• Business-to-employee (B2E) – This model represents the use of an intra-business network to provide products and/or services to a company's employees.

All three models must allow external and internal users seamless access to a business's resources. This requirement led to industry initiatives that extended Single Sign-on (SSO) to include a capability called federation.

Federation enables users of a WCF client to access another business’ resources without having to store their credentials on that client. The client asserts its users’ identities as being valid, and the other business "trusts" the client and its assertions. The process also works in reverse, where an external business can access the client’s resources.

For more information about WCF security, see "WCF Security Overview" on MSDN at https://msdn.microsoft.com/en-us/library/ms735093.aspx

Web Services Security and Federated Security

A Web service is an application that uses a collection of standard Internet technologies to make some functionality available over a network. The benefits of web services are:

• They extend the life of existing and legacy systems.

• They allow you to use standardized methods to connect to new technologies.

• They use widely available tools and capabilities.

• They allow you to integrate processes efficiently by relying on available standards.

• They use registration and discovery mechanisms to create location transparency, where location transparency means that an application is not dependent on a particular server to run.

Adoption of web services was initially slow because of concerns about security. Its current popularity is due to the Web Services Security and Federated Security models.

Web Services Security

The Web Services Security (WS-Security) model describes how to use HTTP to exchange messages between two endpoints. The model specifies how to authenticate users, sign messages, and encrypt messages. Reasons to secure a web service include:

• Financial - Businesses need trusted services in order to make their goods and services available to potential customers, no matter where those customers are located.

• Compliance - Businesses must comply with government regulations that protect consumer privacy.

• Privacy - As businesses share more and more data with each other, they must provide ways to protect personal information.

• Security - The wide adoption of Internet-based commerce increases the possibility of security holes.

There are several challenges to meet when you secure web services.

• End to end privacy of communications – Mechanisms must be in place at the transport and/or message layer to ensure that messages are not maliciously or inadvertently exposed to parties other than the intended recipients.

• Verification of processing entity – Mechanisms must be in place to validate the identity of the entity that will process the security verification.

• Verification of requesting entity – Authentication processes must be in place that can verify a requestor’s identity, and to ensure that the requestor cannot deny that it was involved in the transaction.

• Management of security privileges – Administrative controls must be in place to manage the privilege levels that dictate what entities are allowed to do.

For additional related information, see:

• "Understanding WS-Security," at https://msdn.microsoft.com/en-us/library/ms977327.aspx

• "Web Services Security Patterns," at https://msdn.microsoft.com/en-us/library/ff648183.aspx

• "WS-Security: New Technologies Help Your Web Services More Secure," at https://msdn.microsoft.com/en-us/magazine/cc164158.aspx

Federated Security

Federated identity is a combination of technologies, standards, and use cases that enable users to provide the same identity to different members of trusted partnerships. Users can securely access data or systems in the external domain as if those resources were within their own domain. In addition, the external domain does not need to replicate any identity management tasks for those users. Federation is enabled through the use of open industry standards and/or openly published specifications, such that multiple parties can achieve interoperability for common scenarios. Typical use-cases involve situations such as interoperability among business partners, web-based single sign-on, cross-domain user account provisioning, cross-domain entitlement management, and cross-domain user attribute exchange.

The benefits of implementing a federated identity strategy fall into four main categories:

1. Improved alliances through interoperability, with autonomy:

   • Allows resources and applications to be shared among partners in a way that preserves privacy and confidentiality.

   • Provides the ability to quickly enter into collaborative arrangements that take advantage of immediate needs, or dynamic provisioning. Deprovisioning also occurs quickly, and can be performed as soon as is necessary.

2. Cost avoidance, cost reduction and increased operational efficiencies:

   • Increased productivity by granting faster and easier access to applications.

   • Reduces help desk costs for users and business partners.

   • Reduces administration costs through secure delegation, self-service of identity information, and fewer password resets.

   • Provides businesses with development standards. Development efforts are more focused on specific goals. Released implementations require less long-term maintenance, and fewer upgrades. These benefits result in lower costs.

   • Provides a framework for compliance with regulatory requirements, including the ability to implement services that support policies and requirements about information privacy.

3. Stronger security and risk management:

   • Provides context-sensitive, graduated levels of authentication and risk management.

   • Offers integrated and tighter security controls through the ubiquitous enforcement of security policies.

   • Reduces security risks through the support of non-repudiation. This ensures that a party to a contract or a communication cannot deny the authenticity of its signature on a document or that it sent a particular message.

   • Makes it easier for an organization to grant fine-grained access to users, and to promptly terminate "orphan" accounts of ex-contractors and partners.

4. Interoperability and decreased deployment time:

   • Speeds and eases deployment because the components of the solution are based on commonly accepted standards and interfaces. This eliminates the need to develop integration points.

   • Provides for secure, seamless interoperability between applications and systems, through standards-based identity federation.

   • Enables the integration of legacy systems without the need to re-engineer their authentication and authorization modules.

   • Allows service providers to deploy new systems that interoperate and communicate with existing systems. This minimizes system downtime and increases customer satisfaction.

For additional related information, visit the following links:

• Federated Identity Management Interoperability on MSDN at https://msdn.microsoft.com/en-us/library/ms996532.aspx

• Federated Identity: Scenarios, Architectures, and Implementation on MSDN at https://msdn.microsoft.com/en-us/library/aa479079.aspx

Real-World Scenarios

The following figure illustrates how security is incorporated into a typical web services application architecture.

1. The transport layer security that is between the business partners and the partner sites uses a secure socket layer (SSL).

2. The message exchange security between partner sites and the IIS web server is protected by implementing the WS-Security standard.

3. The lightweight public key infrastructure (PKI), as well as key distribution, protects the mobile user by implementing the XML key management specification (XKMS).

4. Internal policy enforcement, and access control between the web service client application and the IIS application server, is performed with the Security Assertion Markup Language (SAML), and the eXtensible Access Control Markup Language (XACML).

5. The enterprise database technology protects the enterprise data.

6. The IIS application servers use XML signatures for the web service client application.

7. The certificate management server provides secure certificate administration.

WCF Services Security

Scenario 1: Electronic Data Interchange (EDI) Solution

• Description: An auto manufacturer wants to increase its pool of suppliers so that it can lower the cost of parts through more competitive bidding. However, for many small suppliers, it is too expensive to implement elaborate procurement systems that can integrate with traditional EDI solutions.

• Security Concerns: The auto manufacturer is concerned about conducting business over the public Internet. Bids, purchase orders, invoices, and so on must remain confidential.

• Proposed Solution: The proposed solution is to use SSL for point-to-point encryption of data over the Internet, XKMS to register and manage cryptographic keys that are used for digital signatures and encryption, XML signatures to validate traffic origin and integrity, and XML encryption for message confidentiality.

• Benefits: The solution prevents third parties from intercepting transactions. Also, malicious parties cannot tamper with confidential information. All communications are secure from one end to the other.

Scenario 2: Travel Agency

• Description: Contoso Travel Agency wants to provide a wider selection of travel options to its customers. However, it wants to avoid the overhead of establishing and maintaining agreements with a multitude of travel-related companies, such as airlines, hotels, car rentals, and cruise ships, or with credit card companies.

• Security Concerns: Contoso is concerned about executing transactions with new service providers, where a prior relationship does not exist. How will Contoso be protected against fraud, either through false billing, or a failure to deliver services?

• Proposed Solutions: The proposed solution is to use SSL to encrypt data as it travels over the Internet. The solution also relies on XML encryption, and signatures to prevent fraud, and to serve as the basis for proof of purchase.

• Benefits: The solution guarantees that secure transactions can occur in real-time, without Contoso first having to negotiate a series of agreements.

Scenario 3: Employee Self-Service Intranet Application

• Description: Contoso, Ltd. maintains employee data across a number of systems, such as payroll, and benefits. In an effort to reduce the workload of the human resources (HR) department, Contoso, Ltd. wants employees to be able to update their own information. For this to happen, the owners of each system must expose the appropriate logic as a web service. All of the services can then be incorporated into a single application. The employees will have a centralized way to make updates, and there is no need to consolidate disparate HR systems.

• Security Concerns: Contoso, Ltd. is concerned about how to ensure confidentiality when information is spread across a variety of systems that are not necessarily compatible with each other. How can employees' access be restricted so that they can only read and update their own information?

• Proposed Solutions: The proposed solution is to use SAML and XACML mechanisms to pass identification attributes for access control between the front-end and back-end systems. WS-Security specifications establish a security model that integrates formerly incompatible security technologies such as PKI, Kerberos, XML Digital Signature, and XML Encryption.

• Benefits: The benefit is lower-cost HR services that do not compromise employee confidentiality.

Federated Security

Scenario 1: Inbound Federation

Inbound federation is a distributed authentication approach. An external site contacts the client's identity provider for authentication. The service provider and identity provider can exist in the same trust domain, or they may be in different trust domains. When a user in a client organization accesses the external service provider's site (such as a 401K site or an insurance portal), the user's HTTP request is redirected by the external site to the client's Identity Provider (IdP) for validation and authentication. After the user's credentials are authenticated by the IdP, the user's request is redirected back to the external service provider's site and given access. Inbound federation is particularly useful in scenarios where a user is remotely accessing a service provider (SP) that is in multiple circles of trust. The following table shows the steps that are involved in inbound federation.

Table 2. Inbound Federation

Step	Step Name	Actor	Data Inputs	Step Descriptions	Data Outputs	Business Rules
1	Access a protected site	User	The URL to the protected site	User goes to home page of the protected site, and clicks on a link.	None	None
2	User agent redirect	System	None	User agent validates federation, and redirects to the identity provider on the client side.	None	None
3	Federation authenticate	System	None	The identity provider on the client side validates and authenticates the user.	Single Sign-on Token Session	None
4	Grant access	System	None	The user is redirected to the protected site with full access.	None	None

Scenario 2: Outbound Federation

Outbound federation occurs when an independent identity provider authenticates a federated user who is attempting to access a service provider's protected resource. The identity provider is a third party. It does not reside on the client side or on the service provider side. The service provider and the identity provider can exist in the same trust domain, or they may be in different trust domains. The following table shows the steps that are involved in outbound federation.

Table 3. Outbound Federation

Step	Step Name	Actor	Data Inputs	Step Descriptions	Data Outputs	Business Rules
1	Authentication attempt	Federated User	None	The user attempts to access a protected resource.	None	None
2	Check session and redirect	System	None	Check for valid session token from the authentication service, then redirect to the client's IdP.	None	None
3	Create assertion or redirect	System	Assertion	Client (IdP) checks for the original asserter then redirects to another identity provider.	None	None
4	Create assertion	System	None	The originating identity provider asserts the user.	Assertion	None

Scenario 3: Federation Logout

The federation logout logs out the user from every service provider within the circle of trust. Federation logout occurs when the user logs out manually from the identity provider, which in turn sends the logout request to all service providers.

Table 4. Federation Logout

Step	Step Name	Actor	Data Inputs	Step Descriptions	Data Outputs	Business Rules
1	Logout request	Federated User	Logout link	The user logs out of the identity provider.	None	None
2	Federation IdP logout request	System	None	The service provider’s federated service interface sends a log out request to the identity provider.	Logout Request	None
3	Federation SP logout request	System	None	The identity provider propagates the logout request to all service providers in the federation.	Logout Request	None
4	Logout	System	None	Federated user is logged out of the system.	None	None

Scenario 4: De-federation

De-federation ends a user's inclusion in the circle of trust. After de-federation occurs, the service provider (and its resources), and identity providers will not accept or provide authentication to that user. Users initiate the de-federation requests that end their membership in the circle of trust. The request is sent to either the service provider or the identity provider, which then sends the request to all other identity providers in the circle of trust.

Table 5. De-Federation

Step	Step Name	Actor	Data Inputs	Step Descriptions	Data Outputs	Business Rules
1	De-federation request	Federated User	De-federation link	The user requests to de-federate	None	None
2	Process de-federation request	System	None	An identity provider or a service provider processes the de-federation request	De-federation Request	None
3	Propagate request	System	None	Providers send an asynchronous message to all identity and service providers to de-federate the user.	None	None

WCF Security Best Practices and Standards

Security Guidance and Best Practices

The following table provides web services security guidance for each of the security standards.

Table 6. Web Services Security Guidance

Standard	Description	Expected Use
SSL / TLS	SSL is an existing TCP/IP security protocol that secures web communications at the transport layer.	SSL and TLS can be used to protect point-to-point web service communications.
XML-Encryption	XML-Encryption is the standard for encrypting the payload of XML SOAP messages.	All or parts of an XML document can be encrypted.
XML-Signature	XML-Signature is the standard for generating a hash, and for signing XML messages.	All or parts of an XML document can be digitally signed.
SAML	Security Assertions Markup Language is a standard that defines, enhances, and maintains a standard XML-based framework for creating and exchanging authentication and authorization.	SAML defines protocols and assertions for communicating security information.
XACML	eXtensible Access Control Markup Language is the standard for defining authorization policies for SOAP web services requests.	XACML provides a common XML format to define and share authorization policies.
SPML	Service Provisioning Markup Language is an XML-based standard for exchanging and administering user access rights and resource information across heterogeneous environments.	Allows organizations to automate, centralize, and manage the process of provisioning user access to corporate systems and data.
XKMS	The XML Key Management Specification enables Web services to register and manage cryptographic keys that are used for digital signatures and encryption.	Enables secure end-to- end communications through PKI-like key management.
WS-Security	WS-Security is a standard developed by major industries that defines how to use encryption and signature standards within web services SOAP messages.	WS-Security provides a framework for how security information should be contained in a SOAP message.
WS-Security Extensions	WS-Security extensions are being developed that add improved security functionality to WS-Security. These extensions include: WS-Trust, WS-Privacy, WS-Policy, WS-Authorization, and WS-Secure Conversation	Along with WS-Security, these extensions constitute a complete framework for enterprises to generate web services connections automatically.
Liberty Alliance/ WS-Federation	WS-Federation is a part of WS Security Extensions and is supported by Microsoft and IBM. Liberty Alliance is supported by Sun and Oracle. These specifications provide a framework for federated identity.	Allows enterprises to share identity and authentication information.

The following list provides practical steps for securing web services:

• Secure existing web services with current technologies - Use SSL to secure the communications of your existing web services. SSL provides transport-level, point-to-point authentication and data integrity security.

• Identify additional security requirements and needs – Identify additional security features that will be needed as you add new web service functionality. If you are planning on using IBM or Microsoft technologies, Open OASIS WS-Security can provide the message-level authentication and integrity security features. Additionally, evaluate the WS-Security extensions to address other security requirements.

• Follow the development of security standards – Open OASIS and WS-I are the two major organizations that determine standards for web services security technologies. Follow the progress of these groups to better understand how security standards are maturing and changing.

• Evaluate the security SDKs that are available – major vendors have already released SDKs for new web services security standards such as WS-Security, SAML, XML-Signature, and XML-Encryption.

• Work with your business partners to identify security integration points – learn how your business partners are planning on securing their web services.

For more information on WCF Security Guidance, see

• The WCF Security Guidance on Microsoft Patterns & Practices at http://wcfsecurity.codeplex.com/

Security Standards

The following table lists industry standards groups according to organizational categories for XML-based messaging:

Table 7. Industry Standards

Organization	Description	Standards
W3C	The establishment of the World Wide Web Consortium was instrumental in developing common protocols. For additional information visit their link at: http://www.ercim.eu/publication/Ercim_News/enw52/w3c.html	XML-Encryption, XML-Signature
Open OASIS	The Organization for the Advancement of Structured Information Standards produces standards for security, web services, XML conformance, business transactions, electronic publishing, topic maps, and interoperability within and between marketplaces.	XKMS, SAML, XACML, SPML, WS-Security
Open OASIS IBM/Microsoft Roadmap**	IBM and Microsoft collaborated on this standard. For more information, visit the link on MSDN at https://msdn.microsoft.com/en-us/library/ms951273.aspx.	WS-Security, WS-Authorization***, WS-Trust***, WS-SecureConversation***, WS-Federation***, WS-Privacy***, WS-Policy***
WS-I	The Web Services Interoperability Organization promotes Web Services interoperability. For more information visit the link at: http://www.w3.org/2004/02/ws-desc-charter.	WS-I Basic Profile, WS-I Basic Security Profile***
Liberty Alliance**	The Liberty Alliance is an industry consortium that focuses primarily on identity federation for web services.	Liberty Alliance 1.0, Liberty Alliance 2.0***

For additional information, visit the following links:

• Web Services Security Specification Index page on MSDN at https://msdn.microsoft.com/en-us/library/ms951273.aspx

• The Open OASIS WS-Security specification is located at: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

Previous article: Simplifying Enterprise Library Configuration

Continue on to the next article: Performance Tuning WCF Services