1 / 31

WS-PolicyNegotiate

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

wade-durham
Télécharger la présentation

WS-PolicyNegotiate

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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. Overview of the Problem

  3. 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? Example Scenario

  4. 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. Benefits from Policy Negotiation

  5. 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. What is a Web Service?

  6. Exchanges messages over HTTP/S using XML. <?xml version=”1.0”?><soap:Envelope xmlns:soap=”http://www.w3.org/2001/12/soap-envelope” soap:encodingStyle=”http://www.w3.org/2001/12/soap-encoding”><soap:Header></soap:Header><soap:Body><soap:Fault></soap:Fault></soap:Body> </soap:Envelope> SOAP

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

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

  9. 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.): Components

  10. <mappings> <endpoint uri=”someuri”> <defaultOperation> <request Policy=”somepolicy”/> <response Policy=”somepolicy”/> <fault Policy=”somepolicy”/> </defaultOperation> </endpoint></mappings> <Policies> <Policy/> </Policies> WS-Policy (cont.): Basic Structure

  11. <policies xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"> <!-- This policy ensures that the message is signed with a UsernameToken --> <wsp:Policy wsu:Id="SignedUsername"> <wssp:Integrity wsp:Usage="wsp:Required"> <wssp:TokenInfo> <wssp:SecurityToken> <wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken</wssp:TokenType> </wssp:SecurityToken> </wssp:TokenInfo> <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts> </wssp:Integrity> </wsp:Policy> <!-- This policy ensures that the message is signed with a X509 certificate --> <wsp:Policy wsu:Id="SignedX509"> <wssp:Integrity wsp:Usage="wsp:Required"> <wssp:TokenInfo> <wssp:SecurityToken> <wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType> </wssp:SecurityToken> </wssp:TokenInfo> <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts> </wssp:Integrity> </wsp:Policy> </policies>

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

  13. 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. Satisfying The Requirements

  14. Stages Prior to Web Service Execution

  15. Security Policy Negotiation Entities

  16. Security Policy Negotiation Steps

  17. wspn refers to the WS-PolicyNegotiation namespace wsp refers to the WS-Policy namespace (http://schemas.xmlsoap.org/ws/2002/12/policy)‏ Others would be referred to in the WS-* specification within the applicable WS-Policy named policy. WS-PolicyNegotiate: Namespaces

  18. <wspn:PolicyNegotiate id=”xsd:String”> <wspn:Name>xs:NCname</wspn:Name> <wspn:Initiator>xsd:AnyType</wspn:Initiator> <wspn:Responder>xsd:AnyType</wspn:Responder> <wspn:Negotiation id=”xsd:String”> <wspn:Context id=”xsd:String”> </wspn:Context> </wspn:Negotiation> </wspn:PolicyNegotiation> WS-PolicyNegotiate: Overview

  19. 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: Basic Elements

  20. 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: The Responder and Initiator

  21. <wspn:Context id=”xsd:String”> <wspn:ContextName>xsd:String</wspn:ContextName> <wsp:Policy wsu:id=”xsd:String”> </wsp:Policy> </wspn:Context> WS-PolicyNegotiate: Context Complex Type

  22. 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. WS-PolicyNegotiate: Context Elements

  23. 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 Work?

  24. 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 How Does This End?

  25. 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 1)‏

  26. 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 2)‏

  27. 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 3)‏

  28. 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. An Illustrative Example (Part 4)‏

  29. <wspn:PolicyNegotiate Id=”MyPolicyNegotiation”> <wspn:Initiator>toys.r.us@fun.com</wspn:Initiator> <wspn:Responder>http://www.yeehaw.com/</wspn:Responder> <wspn:Negotiation Id=”PleaseAccept”> <wspn:Context Id=”WhatIPropose”> <wsp:Policy wsu:Id = “AuthenticationPolicy” </wspn:Context> </wspn:Negotiation> </wspn:PolicyNegotiation> Note: Not Shown is AuthenticationPolicy. It would follow the format shown in the slide on WS-Policy. WS-PolicyNegotiate SOAP Message (Simplified)‏

  30. 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? Problems with this Approach (More Work to be Done)‏

  31. 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 http://www.w3c.org References

More Related