Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Specifying Security Requirements for a Client

Securing communication between a client and a Web service using the Web Services Enhancements for .NET (WSE) can be done by declaratively stating the security requirements for incoming and outgoing SOAP messages in an XML file. These requirements, collectively known as a policy, are defined either by (a) using the WSE Settings 3.0 Tool tool and its Policy tab from within Visual Studio 2005 or (b) manually adding a <policy> Element (Policy) to the XML file. Whether the tool is used or not, each <policy> element has a name attribute that names the policy. Once the policy is declared in the XML file, which is known as a policy file, the policy is applied to SOAP messages sent to and received by a Web service by calling the SetPolicy method of the proxy class with the policy name.

Alternatively, the policy for a client can be specified in code when the deployment environment is known ahead of time and is not likely to change. Typically, it is more flexible to allow an administrator to define the policy for an application when it is deployed using a policy file, but WSE does allow you to specify the policy in code. So, in summary, a policy file is generally the better solution, because the security settings on an application are part of its deployment and not part of its business logic. Keeping your security setting in a separate policy configuration file ensures that this separation in maintained.

To specify the policy in code, create a new instance of the Policy class, create new instances of policy assertions that detail the policy, and then add these policy assertions to the Assertions collection on the Policy class. That policy is then applied to a SOAP message exchange by passing it to the SetPolicy method and the proxy class. For more details, see How to: Secure a Client Without Using a Policy File.

An application may need to specify the policy in a policy file without specifying the security token details. By not specifying the security token details in the policy file, the application can query the user for the security credentials at runtime, as opposed to declaring them in a policy file, where they may be subject to different kinds of attacks. This is referred to as mixed policy and code.

In This Section

How to: Secure a Client Using a Policy File

Describes how to secure a client using turnkey security assertions that are specified using a policy file that is generated using the WSE Settings 3.0 Tool tool.
How to: Secure a Client Without Using a Policy File

Describes how to secure a client using turnkey security assertions without using a policy file.
How to: Secure a Client Using Mixed Policy and Code

Describes how to secure a client using turnkey security assertions using a mixed policy file and code.

Related Sections

Policy Files

Describes what a policy file is and its basic XML structure.
Policy Assertions

Describes how a policy assertion is used to describe the security requirements for a SOAP message exchange.
Policy Extensions

Describes what a policy extension is and its relationship to policy assertions.
Turnkey Security Assertions

Details the turnkey security assertions that ship with WSE.
Custom Policy Assertions

Describes what a custom policy assertion is. A custom policy assertion is used when turnkey security assertions do not meet an application's security requirements.
© 2015 Microsoft