1 / 48

Web Services Security

Web Services Security. dr. Joris Claessens European Microsoft Innovation Center <jorisc@microsoft.com>. Outline. Introduction: Web Services ? Secure, reliable, and transacted web services for business processing Web Services Security specifications Web Services Enhancements (WSE)

belva
Download Presentation

Web Services Security

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. Web Services Security dr. Joris Claessens European Microsoft Innovation Center <jorisc@microsoft.com>

  2. Outline • Introduction: Web Services ? • Secure, reliable, and transacted web services for business processing • Web Services Security specifications • Web Services Enhancements (WSE) • Relationship to trust management in VOs

  3. Web Service: high-level definition • Web Services bring the paradigm of service-oriented architecture in practice. • They offer an interoperable framework for stateless, message-based and loosely-coupled interaction between software components. • These components can be spread across different companies and organizations, can be implemented on different platforms, and can reside in different computing infrastructures.

  4. Web Service: technical definition • A Web Service exposes useful functionality on the Internet via XML messages exchanged through a standard protocol, SOAP. • The interfaces of a Web Service are described in detail in an XML document using WSDL. • A Web Service is registered at a UDDI server, and is as such discoverable. Requester Web Service

  5. XML fundamentals • eXtensible Markup Language • XML 1.1, W3C Recommendation, February 2004 • meta-language; subset of SGML • elements and attributes • XML Namespaces • collections of names, identified by URI references, which are used in XML documents as element types and attribute names. • XML Schema • provide a means for defining the structure, content and semantics of XML documents • cfr. Document Type Definition (DTD) • eXtensible Stylesheet Language (XSL) • family of recommendations for defining XML document transformation and presentation (including XSLT and XPath)

  6. Web Services Description Language • A WSDL document defines web services as collections of concrete network endpoints, (re)using abstract definitions of operations and messages. • The following elements define a web service (WSDL 1.1): • <message>s are abstract, typed definitions of the data being communicated • <types> encloses data type definitions that are relevant for the exchanged messages (preferably using XSD) • <portType> is a named set of abstract <operation>s and the abstract <input>, <output>, and <fault> messages involved • different transmission primitives: one-way, request-response, solicit-response, and notification. • <binding> defines concrete message format and protocol details for operations and messages defined by a particular <portType> • e.g., use SOAP (<soap:header>, <soap:body>, <soap:operation>). • <service> groups a set of related <port>s together • <port> defines an individual endpoint by specifying a single address for a binding; e.g., a <soap:address>: a URL (SOAP over HTTP) or email address (SOAP over SMTP) • Latest: WSDL 2.0, November 2003, W3C Working Draft • <portType> <interface> • <port>  <endpoint>

  7. SOAP • Latest: SOAP 1.2, June 2003, W3C Recommendation • “Simple Object Access Protocol” (deprecated) • SOAP = extensible XML messaging framework • SOAP messages flow from initial SOAP sender to ultimate SOAP receiver; • message path, possibly through multiple SOAP intermediaries; • different message exchange patterns are supported; • a SOAP node can act in one or more SOAP roles • messages can be exchanged over a variety of underlying protocols • A SOAP message is an <Envelope> containing one or more <Header>s and a <Body> • Body and Headers can have specific attributes: • encodingStyle (body), • mustUnderstand (header). • role (indicates recipient of header if not final destination, but intermediary), • relay (header, if not processed) • Body can be any XML message, particularly a SOAP <Fault> • SOAP “binding” defines how to carry a SOAP message within or on top of another (underlying) protocol; e.g., within an HTTP body, or over a TCP stream

  8. Universal Description, Discovery and Integration • Latest: UDDI Version 3.0.1, OASIS TC Spec., Oct. 2003 • Describes the Web services, data structures and behaviours of all instances of a UDDI registry • A UDDI Registry is formed by one or more UDDI Nodes supporting one or more Node API Sets, and contains the following information: • businessEntity (descriptive info of business) • businessService (descriptive info of Web service) • bindingTemplate (tech. description of Web service) • tModel (‘technical fingerprint’ of the Web service) • Extensive SOAP-based Node API Sets: • Inquiry, Publication, Security, Custody Transfer, Subscription, Replication

  9. Web Services Stack Business Processing BPEL4WS Secure Reliable WS-ReliableMessaging Transacted WS-Coordination WS-AtomicTransaction WS-BusinessActivity Metadata WSDL UDDI WS-Policy WS-PolicyAssertions WS-PolicyAttachment WS-Discovery Messaging SOAP, WS-Addressing, MTOM (Attachments), WS-Eventing XML Transports e.g., http

  10. Web Services Security specifications

  11. Web Services Security ? • Why not use underlying security mechanisms at transport layer (SSL/TLS) and/or network layer (IPsec) ? • only security between intermediaries, no end-to-end • binding specific security (what if web service is exposed via email?) • channel security, but no message security • no digital signatures • not XML-aware: no XML-based security • no security framework (tokens, keys, preferences, policies, …) • no advanced security services (e.g., timestamps) Web Services Security = SOAP message security !

  12. WS-SecureConversation WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy WS-Security SOAP Foundation WS Security Roadmap (April 2002)

  13. Claims Security Token Claims Security Token Security Token Claims Security in a Web Services WorldProposed Architecture and Roadmap WS-Trust describes a framework for trust models that enables Web services to securely interoperate Policy Security Token Service WS-Policy describes the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms, privacy rules) Policy Policy Requester Web Service WS-Security how to attach signature and encryption headers to SOAP messages how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages WS-SecureConversation describes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys

  14. Claims Claims Security Token Security Token Claims Security Token Security Token Claims Security in a Web Services WorldProposed Architecture and Roadmap WS-Privacy will describe a model for how Web services and requesters state privacy preferences and organizational privacy practice statements WS-Authorization will describe how to manage authorization data and authorization policies Policy Policy Security Token Service Security Token Service WS-Policy describes the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms, privacy rules) WS-Federation describes how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities WS-Trust describes a framework for trust models that enables Web services to securely interoperate Policy Policy Requester Web Service WS-Security how to attach signature and encryption headers to SOAP messages how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages WS-SecureConversation describes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys

  15. WS-SecureConversation WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy WS-Security SOAP Foundation Current WSS landscape in detail WS-SecureConversation (12/2002) WS-Federation (07/2003) [WS-Authorization] WS-ActiveProfile WS-PassiveProfile WS-Policy (05/2003) WS-Trust(12/2002) [WS-Privacy] OASIS WSS Username OASIS WSS X.509 WS-SecurityPolicy WS Kerberos (12/2003) OASIS SAML WS-PolicyAttachment OASIS XrML OASIS WSS SOAP Message Security (03/2004) W3C XML Signature (02/2002) W3C XML Encryption (12/2002) W3C SOAP 1.2 (06/2003)

  16. Intermezzo: XML security • XML Signature • W3C Recommendation, February 2002 • provides data integrity and data origin authentication of (parts of) XML messages • supports both digital signatures and ‘MAC’s • XML Encryption • W3C Recommendation, December 2002 • provides data confidentiality of (parts of) XML messages • supports symmetric algorithms for data encryption, and asymmetric algorithms for (symmetric) key transport/establishment

  17. WS-Security[ OASIS, Web Services Security: SOAP Message Security 1.0, March 2004 ] • Enhancements to SOAP messaging to provide end-to-end, and single message integrity, message authentication and message confidentiality • Leverages XML Signature (multiple) + XML Encryption • Mechanism for associating security tokens with message content • Specifies how to encode binary security tokens, XML-based tokens, and how to include opaque encrypted keys • Can support any kind of security token

  18. SOAP message security <S:Envelope> <S:Header> <wsse:Security> <wsu:Timestamp> <xenc:ReferenceList> <xenc:EncryptedKey> <wsse:UsernameToken> <wsse:SecurityTokenReference> XML-based token <wsse-Reference> <wsse-KeyIdentifier> <wsse-Embedded> or <wsse:BinarySecurityToken> <ds:Signature> <S:Body> <xenc:EncryptedData>

  19. WS-Policy[ IBM/Microsoft, Web Services Policy Framework 1.1, May 2003 ] • Provides a general purpose model and corresponding syntax to describe and communicate the policies of a Web Service • Policy expressions: <wsp:Policy> • <wsp:ExactlyOne>, <wsp:All>, <wsp:OneOrMore> • WS-PolicyAssertions defines general messaging-related assertions for use with WS-Policy

  20. WS-PolicyAttachment[ IBM/Microsoft, Web Services Policy Attachment 1.1, May 2003 ] • Defines a general-purpose mechanism for associating policy expressions with subjects. • provides for two approaches to making the associations: • policy assertions may be defined as part of the definition of the subject • policy assertions may be defined independently and associated through an external binding to the subject. • Specifically: • How to reference policies from WSDL definitions • How to associate policies with specific instances of WSDL services • How to associate policies with UDDI entities

  21. WS-SecurityPolicy[ IBM/Microsoft, Web Services Security Policy Language 1.0, December 2002 ] Specificies security policy assertions for WS-Policy: • what kind of <SecurityToken> is required, from whom, and which claims should it provide • wsse:X509v3 • wsse:Kerberosv5TGT • wsse:Kerberosv5ST • wsse:UsernameToken • wsse:SAMLAssertion • wsse:XrMLLicense • <Integrity> protection: which message parts and how • <Confidentiality> protection: which message parts and how • required <Visibility> of message parts for intermediaries • specific behaviours of <SecurityHeader> • what is the maximum allowed <MessageAge>

  22. WS-Trust[ IBM/Microsoft, Web Services Trust Language 1.0, December 2002 ] • Security Token Issuance, Validation, and Exchange • <RequestSecurityToken> • wsse:ReqIssue, wsse:ReqValidate, wsse:ReqExchange • <RequestSecurityTokenResponse> • <RequestedSecurityToken> • <RequestedProofToken> • Requirements and Extensions • scope requirements: <wsp:AppliesTo>, <Claims> • key and encryption requirements • delegation, forwarding, and proxy requirements: • <OnBehalfOf>, <DelegateTo> • <Forwardable/>, <Delegatable/>, <Proxiable/> (e.g., Kerberos) • lifetime and renewal requirements • policies: <wsp:Policy>, <wsp:PolicyReference> • challenges: • <SignChallenge> and <SignChallengeResponse> • <BinaryNegotiation>

  23. WS-SecureConversation[ IBM/Microsoft, Web Services Secure Conversation Language 1.0, Dec. 2002 ] • Defines extensions to allow: • security context establishment and sharing • session key derivation • <wsse:SecurityContextToken> • <wsu:Identifier> • <wsu:Created> • <wsu:Expires> • <wsse:Keys> • <xenc:EncryptedKey> • <wsse:SecurityTokenReference> • <DerivedKeyToken> • Security context token is created • by a security token service • by one of communicating parties + propagated with a message • through negotiation

  24. WS-Federation[ IBM/Microsoft, Web Services Federation Language 1.0, July 2003 ] • Models and framework for federation of identity, attribute, authentication, and authorization information • Key driving requirements • enable appropriate sharing of identity, authentication, and authorization data • brokering of trust and security token exchange • local identities are not required at target services • optional hiding of identity information and other attributes • Builds on the foundations specified in WS-Security, WS-Policy, and WS-Trust • Extends the WS-Trust model to allow attributes and pseudonyms to be integrated into the token issuance mechanism to provide federated identity mapping mechanisms

  25. WS-Federation Models (1)Trust and Security Token Issuance

  26. WS-Federation: Delegation

  27. WS-Federation Models (2) and (3)Identity Providers + Attributes and Pseudonyms

  28. WS-Federation (cont’d) • Federation of meta-data • Web service may want to indicate where requestors can obtain security tokens in order to satisfy the services claims requirements • mechanisms defined in WS-PolicyAssertions are therefore extended with a <wsse:RelatedService> assertion • wsse:ServiceIP, wsse:ServiceSTS, wsse:ServiceAS, wsse:ServicePS • Sign-out: termination of SSO • <wsse:SignOut> in <S:Body> + federating sign-out messages • clean up any cached state and security tokens that may exist within the federation • implication of sign-out on currently active transactions is undefined and is resource-specific • Attribute Service • possibility to expose attribute stores as UDDI endpoints • Pseudonym Service • <wsse:GetPseudonym> and <wsse:GetPseudonymResponse> • <wsse:SetPseudonym> and <wsse:SetPseudonymResponse/> • <wsse:DeletePseudonym> and <wsse:DeletePseudonymResponse/> • RequestPseudonym in RequestSecurityToken

  29. WS-Federation (summary)

  30. WS-Federation: Requestor Profiles Detail how different requestors apply the model: • Active Requestor Profile • defines how the federation model is applied to active requestors such as SOAP applications • uses standard specifications • describes requirements on security tokens, etc • Passive Requestor Profile • defines how the WS-Federation model is applied to passive requestors such as Web browsers that support the HTTP protocol • specifies HTTP protocol syntax • describes requirements on cookies, etc

  31. WSS Token Profiles (1)[ OASIS, WSS UsernameToken Profile 1.0, March 2004OASIS, WSS X.509 Certificate Token Profile, March 2004 ] • Username/Password • <wsse:UsernameToken> • <wsse:Username> • <wsse:Password> (text or digest) • <wsse:Nonce> • <wsu:Created> • X.509 certificate • <wsse:X509v3> • <wsse:X509PKIPathv1> • <wsse:PKCS7>

  32. WSS Token Profiles (2)[ IBM/Microsoft, Web Services Security Kerberos Binding, December 2003 ] • WS Security Kerberos Binding • must use <wsse:BinarySecurityToken> • GSS-API for Kerberos interoperability • use challenge/response in WS-Trust • use <BinaryNegotiation> in WS-SecureConversation (wsk:SPNEGO) • <wsse:SecurityContextToken> may include <wsk:Correlation> • Alternative: general Kerberos interoperability • use Kerberosv5TGT and Kerberosv5ST

  33. Web Services Securityin practice

  34. Web Services Enhancements (WSE) • “Web Services Enhancements 2.0 for Microsoft .NET (WSE) Technology Preview” • implementation of WS-* specifications on .NET • can be downloaded freely from msdn.microsoft.com • WSE 2.0 supports: • securing XML Web services • routing SOAP messages • sending attachments with SOAP messages • WSE 2.0 supports: • WS-Security • WS-(Security)Policy • WS-Trust • UsernameToken, X.509 certificates, Kerberos tokens • WS-SecureConversation • WS-Addressing

  35. Example: an AddUp web service • AddUp web service adds up 2 integers… • …only if request is digitally signed, and certificate contains appropriate claims. • Uses WS-Security and WS-SecurityPolicy • AddUpWSDL.xml, AddUpRequest.xml, AddUpResponse.xml • AddUpSecurityPolicy.xml, AddUpRequestSigned.xml

  36. Some code snippets Server: [WebService( Namespace="http://joris.claessens.ws/2003/12/", Description="A simple AddUp web service.")] public class AddUp : System.Web.Services.WebService { [WebMethod(Description="This method adds up two integers.")] public int AddThemUp(int Num1, int Num2) { Client: using Microsoft.Web.Services.Security; … AddWSClient.AddUp.AddUpWse ws = new AddWSClient.AddUp.AddUpWse(); SoapContext requestContext = ws.RequestSoapContext; requestContext.Security.Tokens.Add(signatureToken); Signature sig = new Signature(signatureToken); requestContext.Security.Elements.Add(sig); … int Num3 = ws.AddThemUp(Num1,Num2); Client reference: [System.Web.Services.WebServiceBindingAttribute(Name="AddUpSoap", Namespace="http://joris.claessens.ws/2003/12/")] public class AddUp : Microsoft.Web.Services.WebServicesClientProtocol

  37. Relationship to trust management in VOs [ disclaimer: preliminary thinking ]

  38. Web Services Security and TrustCoM • How trust is established or determined, is out of scope of the current WSS specifications. • Question: how can the WSS specifications support and complement, tools for • trust management • contract management • (autonomic) security policy management

  39. Trust/policy domain A Trust/policy domain B WS-SecureConversation data WS-Security requester service request secured service request secured service request service request service data and/or resources security token: identifier, claim security token: identifier, claim WS-Federation WS-Trust authorisation & policy enforcement authorisation & policy enforcement WS-(Security)Policy organisational security policy organisational security policy current Web Services Security specifications addressed by WSS out of WSS scope

  40. Notes on WSS specifications • Trust and contract management happen entirely out-of-band. • Secure exchange of root public keys must happen out-of-band (except if partners have single common trusted CA). • Security policy exchange is often out-of-band too. • Even if a service’s security policy is discoverable, security policy management remains fairly static.

  41. Trust/policy domain A Trust/policy domain B data requester service request secured service request secured service request service request service data and/or resources security token: identifier, claim security token: identifier, claim context: time, locality, … authorisation & policy enforcement authorisation & policy enforcement business process organisational security policy specific VO security policy specific VO security policy organisational security policy contract

  42. Contract management • A specific web service is part of a particular business process in a particular context. • For this, a contract is negotiated (establishing the Virtual Organisation). • The security policies of the respective organisations give input (mutually agreed security policies based on contract). • WSS specifications may support secure contract negotiation, if there is a generic contract negotiation web service.

  43. Security policy management and enforcement • Dynamic policy updates reflecting the contract. • Should there be mechanisms to be able to push new policies instead of others polling these?Or do policy updates only originate from contract negotiations? • Policy enforcement should take into account the business process and the context related to a specific web service request. • Enforcement must be done in consistent way across different layers (business process, web service, network). • WSS specs only deal with security on the level of web services, and assume that SOAP nodes are accessible on the network layer; this assumption cannot be made in dynamic context.

  44. Trust/policy domain A Trust/policy domain B data requester service request secured service request secured service request service request service data and/or resources security token: identifier, claim security token: identifier, claim WS-Trust context: time, locality, … authorisation & policy enforcement authorisation & policy enforcement business process organisational security policy specific VO security policy specific VO security policy organisational security policy contract trust & reputation trust & reputation trust & reputation brokerage WS-Federation attributes UDDI

  45. Trust management • Trust is about the expectation in the behaviour, and/or belief in statements, of another party. • WSS example: trust in correct mapping by CA between identity and public key • Statements need to be securely communicated  also need to establish trust in cryptographic keys with which authenticity of tokens and assertions can be verified. • WSS example: root public key of CA must be obtained out-of-band • WSS allows to securely communicate trust statements (assuming verification keys are trusted!): • use UDDI to publish trust and reputation statements • use WS-Trust to request, issue, and validate trust and reputation statements/assertions • trust/reputation as attribute service (WS-Federation)

  46. Trust management (cont’d) • Trust is a black or white issue in WSS: either you trust or you don’t trust. • What if trust is quantified? • has definitely an impact during contract negotiation • has indirectly an impact on VO specific security policies (more restrictive policy with partners who are less trusted) • should however not become a parameter within security policies (policy should remain fixed after contract has been negotiated, and within the scope of the policy, partners are “fully trusted”) • should certainly not become a parameter in authorisation and policy enforcement (e.g., quantified authorisation statements, or partially trusted keys do not seem to make sense) • Note that (autonomic) security decisions should not become unpredictable !

  47. Questions ? jorisc@microsoft.com

  48. References • IBM/Microsoft, “Security in a Web Services World: A Proposed Architecture and Roadmap”, April 2002. • http://msdn.microsoft.com/webservices/?pull=/library/en-us/dnwssecur/html/securitywhitepaper.asp • IBM/Microsoft, “Secure, Reliable, Transacted Web Services: Architecture and Composition”, Sept. 2003. • http://msdn.microsoft.com/webservices/?pull=/library/en-us/dnwebsrv/html/wsoverview.asp • IBM/Microsoft, “Federation of Identities in a Web Services World”, July 2003. • http://msdn.microsoft.com/webservices/?pull=/library/en-us/dnglobspec/html/ws-federation-strategy.asp • Web Services specifications. • http://msdn.microsoft.com/webservices/understanding/specs/

More Related