다음을 통해 공유

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

  • 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.
  • 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.