WS-PolicyNegotiate A Web Service Standard for Policy Negotiation by Nicholis Bufmack

Overview of the Problem Web services need to be protected from malicious attacks. This has led web service providers to create security policies that they then implement to protect the service. However, in some instances, details of the security policy may need to be negotiated between the web service provider and the web service requester. In this instance, a protocol for web service negotiation is needed.

Example Scenario A defense contractor wishes to access a web service that normally provides only a password level of access control. The defense contractor, however, wishes for a higher level of security (for instance, biometric authentication). How does one go about negotiating the higher levels of security required by the service consumer?

Benefits from Policy Negotiation Service providers can reach a larger market by creating services for customers with diverse security needs. Customers can tailor their service consumption to account for their own security needs. By providing only what is required for a transaction, greater efficiency can be achieved.

What is a Web Service? Web services are a standardized way of integrating web based applications using XML, SOAP, WSDL, and UDDI over an Internet protocol back-bone (typically, HTTP/S). UDDI is used to describe what services are available, WSDL is used to describe the service, and SOAP is used to transfer data. Services are provided through a programmatic interface across the network.

SOAP Exchanges messages over HTTP/S using XML. envelope

WS-* WS (Web Service) standards for web services. Proposed by members of the W3C (World Wide Web Consortium). Deal with the numerous aspects relating to providing and consuming web services. Examples are WS-Addressing, WS-Security, WS- Reliability, and WS-Policy. Each details a namespace within a SOAP XML document. Currently no proposed protocol for policy negotiation.

WS-Policy Specification used by web service providers to advertise their policies and for web service consumers to specify their policy requirements. Example policies specified are security and quality of service. Represents a set of specifications describing the capabilities and constraints of policies on intermediaries and end points and how to associate policies with services and endpoints. Forms the basis of WS-PolicyNegotiate.

WS-Policy (cont.): Components Policy Assertions form the basis of WS-Policy. Builds upon the other WS-* proposals (via namespace inclusions). They are requirements put upon the web service. Two major operators are defined: wsp:ExactlyOne – one node (policy) must be satisfied wsp:All – every node must be satisfied (the default)‏

WS-Policy (cont.): Basic Structure

<policies xmlns:wsu=" 1.0.xsd" xmlns:wssp=" xmlns:wsp=" profile-1.0#UsernameToken wsp:Body() 1.0#X509v3 wsp:Body()

Policy Negotiation Requirements The security policies to be negotiated must be clear and identifiable. The consumer may negotiate any subset of the policies within the policy. The consumer will initiate policy negotiation. Negotiation may be terminated be either party at which point the associated web service may not proceed.

Satisfying The Requirements All policies to be negotiated must refer to a policy described within a WS-Policy policy document. All policies within WS-Policy nodes may be negotiated. A failure of any sub-node will result in a failed assertion. Likewise, a successful negotiation of all sub-nodes will lead to a positive assertion for that policy. The consumer will submit a request for negotiation and the provider will respond with a response message. This will continue until the negotiation is successful or fails. The advertisement of policies will follow WS-Attachment and reside within the WSDL.

Stages Prior to Web Service Execution

Security Policy Negotiation Entities

Security Policy Negotiation Steps

WS-PolicyNegotiate: Namespaces wspn refers to the WS-PolicyNegotiation namespace wsp refers to the WS-Policy namespace ( Others would be referred to in the WS-* specification within the applicable WS-Policy named policy.

WS-PolicyNegotiate: Overview xs:NCname xsd:AnyType

WS-PolicyNegotiate: Basic Elements wspn:PolicyNegotiate id – a unique string identifying this policy negotiation wspn:Name – an optional string containing a human-readable reference to this negotiation wspn:Initiator – any type referring to the initiator of the this part of the policy negotiation wspn:Responder – any type referring to the responder to the initiator of the policy negotiation wspn:Context – a complex type containing the policy negotiation; id is a unique identifier

WS-PolicyNegotiate: The Responder and Initiator The initiator always starts as the consumer. The responder always starts as the service provider. Roles change as the messages are exchanged. This allows the consumer and recipient to keep track of the flow and stages of negotiation. The last message will always be from the provider (as initiator) and the consumer (as the responder). After this last stage, the actual service execution can begin.

WS-PolicyNegotiate: Context Complex Type xsd:String

WS-PolicyNegotiate: Context Elements wspn:ContextName – an optional human-readable identifier ws:Policy wsu:id – a policy document that represents the initiators or responders policy statement. The id refers to either an included policy or to an external one via a fully qualified name. The policies may be nested or sequenced and may refer to any type or number of policies.

How Does This Work? The initiator creates a WS-Policy document describing their proposed policy level. A pre- existing WS-Policy document may also be used. The WS-PolicyNegotiate document is created and sent to the the web service provider. The responder reviews the WS-Policy and responds with either their own WS-Policy or a subset of the initiator's WS-Policy document. This continues with each side changing roles until negotiation has completed.

How Does This End? This continues until a responder returns a minimal set acceptable to the both sides. What we're looking for is the intersection of the initiator's and responder's policy requests. This is signaled when one side receives a policy in wspn:Context that is the same as that which they just sent. Services can publish their minimal set of policy requirements subject to negotiation in the service WSDL as WS-PolicyAttachment

An Illustrative Example (Part 1)‏ The consumer (as initiator) looks up the provider's WSDL and notes a WS-PolicyAttachement declaring that WS-Security Policies can be negotiated. The consumer then sends a WS- PolicyNegotiate with a WS-Policy requesting to use basic authentication or an X.509 certificate.

An Illustrative Example (Part 2)‏ The provider (who is now the initiator) responds with a WS-PolicyNegotiate document containing a WS-Policy document stating that X.509 authentication is available and preferred. Included in the policy is an element stating that this is the only authentication available.

An Illustrative Example (Part 3)‏ After receiving this WS-PolicyNegotiate, the consumer (again in the role of initiator), having found this to be acceptable, returns the same WS- Policy within a WS-PolicyNegotiate as an acceptance token.

An Illustrative Example (Part 4)‏ The final step has the provider as the initiator sending the consumer's WS-Policy within a WS- PolicyAttachement to the consumer. The consumer, having received its message back as a final indicator of acceptance, begins the processes of connecting to the web service under the terms laid out within the accepted WS-Policy.

WS-PolicyNegotiate SOAP Message (Simplified)‏ <wsp:Policy wsu:Id = “AuthenticationPolicy” Note: Not Shown is AuthenticationPolicy. It would follow the format shown in the slide on WS-Policy.

Problems with this Approach (More Work to be Done)‏ Would it be better to use a sequence number for flow control? Would it be better to use an ack/nack to indicate policy acceptance? Could elements from WS-Agreement be used to solve this same problem or incorporated within this solution?

References Lee, George, “Negotiated Security and Privacy Policies for Web Services”, NCRC 04 Lee, George and Larry Korba, “Negotiated Policies for E-Services and Web Services”, ICWS 05 Specifications for all WS-* can be found at