Web Services Security

Web Services Security

dr. Joris Claessens

European Microsoft Innovation Center

<[email protected]>

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.

RequesterWeb

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

XML

MessagingSOAP, WS-Addressing, MTOM (Attachments), WS-Eventing

Secure ReliableWS-ReliableMessaging

TransactedWS-Coordination

WS-AtomicTransactionWS-BusinessActivity

MetadataWSDLUDDI

WS-PolicyWS-PolicyAssertionsWS-PolicyAttachment

WS-Discovery

Business ProcessingBPEL4WS

Transportse.g., http

Web Services Stack

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 Security Roadmap (April 2002)

SOAP Foundation

WS-Security

WS-Policy WS-Trust

WS-SecureConversation WS-Federation WS-Authorization

WS-Privacy

13Security in a Web Services World

Proposed Architecture and Roadmap

WS-Policydescribes 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-SecureConversationdescribes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys

RequesterWeb

Service

Security Token

Service

Policy

Security Token

Claims

Policy

Policy

Security Token

Claims

Security Token

Claims

WS-Securityhow to attach signature and encryption headers to SOAP messageshow to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages

WS-Trustdescribes a framework for trust models that enables Web services to securely interoperate

14

WS-Policydescribes 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-Federationdescribes how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities

WS-SecureConversationdescribes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys

RequesterWeb

Service

Security Token

Service

Policy

Security Token

Claims

Policy

Policy

Security Token

Claims

Security Token

Claims

WS-Securityhow to attach signature and encryption headers to SOAP messageshow to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages

WS-Trustdescribes a framework for trust models that enables Web services to securely interoperate

Security Token

Service

PolicySecurity Token

ClaimsWS-Authorizationwill describe how to manage authorization data and authorization policies

WS-Privacywill describe a model for how Web services and requesters state privacy preferences and organizational privacy practice statements

Security in a Web Services WorldProposed Architecture and Roadmap

15

SOAP Foundation

WS-Security

WS-Policy WS-Trust

WS-SecureConversation WS-Federation WS-Authorization

WS-Privacy

W3C SOAP 1.2 (06/2003)

Current WSS landscape in detail

OASIS WSS SOAP Message Security (03/2004)

WS-Policy (05/2003) WS-Trust(12/2002)

WS-SecureConversation (12/2002)

WS-Federation (07/2003)

[WS-Authorization]

[WS-Privacy]

W3C XML Signature (02/2002)

W3C XML Encryption (12/2002)

WS-PolicyAttachment

WS-SecurityPolicy

WS-ActiveProfile

WS-PassiveProfile

OASIS WSS UsernameOASIS WSS X.509

WS Kerberos (12/2003)OASIS SAMLOASIS XrML

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

<S:Envelope>

<S:Header>

<S:Body>

<xenc:EncryptedData>

<wsse:Security>

<wsu:Timestamp>

<xenc:ReferenceList><xenc:EncryptedKey>

<wsse:UsernameToken>

<wsse:BinarySecurityToken>

<wsse:SecurityTokenReference>

<ds:Signature>

XML-based token <wsse-Reference> <wsse-KeyIdentifier> <wsse-Embedded>

or

SOAP message security

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 2004 OASIS, 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

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

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);

[System.Web.Services.WebServiceBindingAttribute(Name="AddUpSoap", Namespace="http://joris.claessens.ws/2003/12/")]public class AddUp : Microsoft.Web.Services.WebServicesClientProtocol

[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){

Server:

Client:

Client reference:

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

requesterservicerequest

securedservice request

authorisation &policy enforcement

security token:identifier, claim

organisationalsecurity policy


data and/orresources




Trust/policy domain A Trust/policy domain B

data

servicerequest

service

WS-Security

WS-SecureConversation

WS-Trust

WS-Federation

WS-(Security)Policy

current Web Services Security specifications

addressed by WSSout 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






specific VOsecurity policy

contract

context: time, locality, …

businessprocess








data

servicerequest

service

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







contract

context: time, locality, …

businessprocess








data

servicerequest

service

trust & reputation trust & reputation

trust & reputationbrokerage

UDDI

WS-Trust

WS-Federation attributes

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 !

Questions ?

[email protected]

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/

Web Services Security

Documents

Transcript of Web Services Security