CIS*6650.01 Service-Oriented Computing

1. CIS*6650.01Service-Oriented Computing Qusay H. Mahmoud, Ph.D. qmahmoud@uoguelph.ca CIS*6650.01

2. Securing Web Services • Security and Protection • Cryptography • Encryption/Decryption • Digital signatures • Certificates • Message digests • SSL and Web services • Standards for securing Web services CIS*6650.01

3. Introduction to Security • Security: safety from damage and unauthorized use • Protection: mechanisms for achieving security • Threats: • Eavesdropping: obtaining copies of messages without authority • Masquerading: impersonating someone • Tampering: unauthorized alteration of information • Replaying: Storing intercepted messages and sending them at a later date • Denial of service: flooding a channel or other resources with messages in order to deny access to others CIS*6650.01

4. Designing Secure Services • Assume the worst • Construct a list of threats (methods by which security policies might be violated) • Show that each threat is prevented by the mechanisms employed in your system • The list may not be exhaustive; use auditing methods (secure log of transactions: timestamps of actions, identities, operation(s) performed) • Balance cost against threats: • A cost in computational effort and in network usage • Inappropriately specified security measures exclude users from performing necessary actions CIS*6650.01

5. Worst-case Assumptions • Design guidelines: • Interfaces are exposed • Networks are insecure • Limit the lifetime and scope of each secret (e.g. change passwords every month) • Attackers may have access to large resources • Minimize the trusted base • Security is implemented by program that must be trusted CIS*6650.01

6. Protection Techniques • Encryption and decryption • Secrecy and integrity • Authentication • Digital signatures • Certificates • Access control lists • Firewalls CIS*6650.01

7. Cryptography • Encryption • The process of encoding a message to hide its content • Scramble plain text into cipher (encrypted) text • Based on the use of secrets called “keys” • A cryptographic key is a parameter used in an encryption algorithm in such a way that the encrypted message cannot be reversed without knowledge of the key • Two classes: • Shared secret key cryptosystems (private encryption) • Public key cryptosystems CIS*6650.01

8. Cryptography • Plays three roles • Secrecy and integrity • Only the intended receiver should be able to read the message • Authentication • Sender and receiver able to identify each other • Digital signatures • Emulate the role of conventional signatures: verify to a third party that a message is an unaltered copy of one produced by the signer CIS*6650.01

9. Secrecy and Integrity • A message that is encrypted with a particular encryption key can only be decrypted by a recipient who knows the corresponding decryption key • The secrecy of the message is maintained as long as the key is not compromised • Example • Alice uses a secret key and an encryption function to encrypt and send messages to Bob • Bob reads the encrypted messages using the secret key and the corresponding function • Problem: How can Alice send a shared secret key to Bob securely? CIS*6650.01

10. Authentication • Using public-key cryptography to distribute shared keys • Alice access a distribution service to obtain Bob’s public key • Alice creates a new shared key and encrypts its using Bob’s public key and sends it to Bob • Bob uses his private key to decrypt the message and retrieve the shared secret key CIS*6650.01

11. Certificates • A digital certificate is a document containing a statement signed by a principal • Example: BK is a bank • When his customers establish contact with BK, they need to be sure they are talking to BK the bank • BK needs to authenticate its customers before it gives them access to their accounts • Certificate type: Account Number • Name: Alice, Account: 626662626 • Certification Authority: BKCA • Signature: Encrypt Digest(f1+f2) using BK’s private key • Merchant can use BK’s public key to extract f1+f2 CIS*6650.01

12. Certificates • To make certificates useful, a couple of things are needed • A standard format and representation for them so that certificate issuers and certificate users can successfully construct and interpret them • An agreement on the manner in which chains of certificates are constructed, and in particular the notion of a trusted authority • What if a certificate is revoked? • Expensive and impossible to track down revoked certificates and delete them • Notify all possible recipients of revoked certificates • Solution: include an expiry date in the certificate CIS*6650.01

13. Certificates • X.509 is the most widely used standard format for certificates; a standard for the construction of global directories of names and attributes • Format: • Subject • Issuer • Period of validity • Administrative information • Extended information • You can see a list of Certification Authorities in Microsoft IE: • Tools->InternetOptions->Content->Certificates CIS*6650.01

14. Access Control Lists and Firewalls • Protection domains • An execution environment shared by a collection of processes. It contains a set of <resource, rights> pairs listing the resources that can be accessed and the operations permitted on each resource • Firewalls • Perform filtering actions on incoming and outgoing communications • Disadvantages • Offer no protection against attacks from the inside • Not effective against denial of service attacks CIS*6650.01

15. Cryptographic Tools • Encryption algorithms • Secret-key systems (symmetric). Example: DES • Public-key systems (asymmetric). Example: RSA • One-way functions • Given the value f(x), it is extremely difficult to guess x • Can be applied to message digests • MD5: Message Digest-5 (128-bit digest) • SHA: Secure Hash Algorithm (160-bit digest) CIS*6650.01

16. Encryption • Notations • K is the encryption key • K’ is the decryption key • Kp is the public key • Ks is the private key • In secret-key encryption: K = K’ • In public-key encryption • K = Kp • K = Ks and K’ = Kp (digital signature) • Should be easy to generate pairs of keys (Kp, Ks) • Difficult to determine Ks from Kp CIS*6650.01

17. Digital Signatures • Using public encryption for signatures • Alice encrypts a message using her private key • Bob decrypts the message using Alice’s public key • Bob concludes that the message is signed by Alice since it was encrypted using Alice’s private key – Alice is the only one who knows that key • To prevent someone from replaying an old message signed by Alice, use a timestamp CIS*6650.01

18. Message Digests • Function: h = H(M) • A secure digest function should have the following properties • Given M, it is easy to compute h • Given h, it is hard to compute M • Given M, it is hard to find another message M’ such that H(M) = H(M’) CIS*6650.01

19. Message Digests • Example: Alice wants to sign a document • Alice computes a digest of the document Digest(M) • Alice encrypts digest with her private key and appends it to M • Bob obtains the signed document, extracts M and computes Digest(M) • Bob decrypts Digest(M) using Alice’s public key and compares the results with his calculated digest. If they match, the signature is valid CIS*6650.01

20. Certificates... • From the previous slide: how does Bob know that the public key he has or acquired belong to Alice? • Use a certificate, which represents the public key identity of a person • A certificate is a signed document that says “I certify that the public key in this document belongs to the entity named in this document. Signed certificate authority” CIS*6650.01

21. Secure Socket Layer (SSL) • Originally developed by Netscape • An extended version has been adopted as an Internet standard under the name Transport Layer Security (TLS) • TLS is described in RFC2246 • SSL is supported by most browsers and web servers and widely used for secure online shopping (https://) CIS*6650.01

22. SSL • Handshake protocol • For details, see the URL below: http://java.sun.com/developer/technicalArticles/Security/secureinternet/ CIS*6650.01

23. Securing Web Services • Six general security services required by a security facility • Authentication: Ensures that the sender and receiver are who they claim to be. Mechanisms such as username/password, smart cards, and Public Key Infrastructure (PKI) can be used to assure authentication. • Authorization or Access Control: Ensures that an authenticated entity can access only those services they are allowed to access. Access control lists are used to implement this. • Availability: Requires that uninterrupted services are provided to authenticated and authorized users. • Confidentiality: This assures that information in storage and in-transit are accessible only for reading by authorized parties. Encryption is used to assure message confidentiality. • Integrity: Ensures that information, either in storage or in-transit cannot be modified intentionally or unintentionally. Digital signatures are used to assure message integrity. • Nonrepudiation: Requires that neither the sender nor the receiver of a message be able to legitimately claim they didn't send/receive the message. CIS*6650.01

24. SSL and Web Service • SSL addresses the following security considerations • Authentication: The server presents the browser with a set of credentials in the form of a server certificate, which is used to verify that the site is what it claims to be • Confidentiality: SSL responses are encrypted so that the data cannot be deciphered by third parties as it passes between the client and server on a network • Integrity: Guarantee that data is not being modified as it is being passed between the client and server on a network CIS*6650.01

25. SSL and Web Services • SSL is not adequate; it encrypts the data stream but doesn’t provide end-to-end confidentiality CIS*6650.01

26. SSL and Web Services • Limitations of SSL for Web Services • SSL provides point-to-point security or operates between end-points (and not applications), but for web services we need end-to-end security in which multiple intermediate nodes could exist between the two end-points. In a web services environment, there could be multiple XML-based business documents going through multiple intermediary nodes and it will be difficult for such nodes to participate in security operations in an integrated fashion. • SSL operates at the transport level and not at the message level. In other words, messages are protected only while in transit. That is, you cannot save the message for later to prove that it hasn't been modified. • SSL doesn't support nonrepudiation. Using SSL, a communicating partner cannot prove that the other party has performed a particular transaction. That is, SSL doesn't support an end-to-end audit trail from service request to service response. • SSL doesn't support element-wise signing and encryption. Given a large XML order document, you may want to only sign or encrypt the credit card info...and that is difficult in SSL. This is because SSL is a transport-level security scheme as opposed to a message-level scheme. CIS*6650.01

27. Firewalls and Web Services • To be effective, a content filtering firewall should determine: • If the incoming SOAP message is destined to a live Web service • If the SOAP message and its request are valid • If the SOAP message contains valid data CIS*6650.01

28. Message-Level Security • Security at the transport layer is not always sufficient for web services • Message-level (or message-layer) security: security is contained within the SOAP message and/or SOAP attachment (security info travels with the message) • A “portion” of a message may be signed by a sender and encrypted for a particular receiver. It will pass through intermediary nodes, but can be decrypted only by the intended receiver. Hence “end-to-end security”. CIS*6650.01

29. Message-Level Security • Advantages • Security stays with the message over all hops and after the message arrives at destination • Fine-grained: can be selectively applied to different portions of a message • Can be used in conjunction with intermediaries over multiple hops • Independent of the application environments or transport protocol • Disadvantage: • Complex and adds some overhead to processing • Mechanisms: • Encryption, Decryption, Authentication CIS*6650.01

30. XML-based Security Standards • W3C Specifications (www.w3.org): • XML Encryption: A standard specification developed by the W3C proposes to encrypt portions of XML documents. This specification can be used to assure confidentiality in case of a security context ranging over several SOAP intermediaries. To do that, portions of the SOAP message are kept confidential from SOAP intermediaries while the message is in transit. • XML Digital Signature: A standard specification developed jointly by the W3C and IETF (Internet Engineering Task Force). An XML signature is equivalent to a digital signature; it can be used to digitally sign portions of an XML document. It is used with SOAP messages. • XML Key Management Specification (XKMS): Developed by the W3C to allow clients to obtain cryptographic key information (such as keys and certificates). It also describes protocols for key management such as registration and revocation, suitable to be used together with XML Signature and XML Encryption. CIS*6650.01

31. Web Services Security • Original Security Roadmap (IBM & Microsoft, 2002) • See “Resources” for link to full paper CIS*6650.01

32. WS-Security Specifications • IBM & Microsoft Roadmap • WS-Security: describes how to attach signature and encryption headers to SOAP messages, and how to attach security tokens (usernames, certificates) • WS-Policy: Capabilities and constraints of the security policies on intermediaries and endpoints • WS-Trust: A framework for trust models to enable Web services to securely interoperate • WS-Privacy: A model for requesters and organizations to specify preferences • WS-SecureConversation: How to manage and authenticate message exchanges • WS-Federation: How to manage trust relationships in a heterogeneous environment • WS-Authorization: How to manage authorization data policies CIS*6650.01

33. Web Services Security Standards • OASIS Specifications (www.oasis-open.org): • WS-Security (SOAP Message Security): describes enhancements to SOAP messaging to provide message integrity and confidentiality. Also defines a mechanism for associating security tokens with message content • Security Assertion Markup Language (SAML): defines a framework for exchanging authentication and authorization information • eXtensible Access Control Markup Language (XACML): a language for expressing security policy CIS*6650.01

34. WS-Security (OASIS standard) • WS-Security • Defines enhancements to SOAP messaging to provide message integrity and confidentiality • End-to-end security: from initial sender, 0-n intermediaries, ultimate receiver • Support for pluggable algorithms: encryption, digest, signature • Provides a general-purpose mechanism for associating security tokens with message content • A security token (unsigned such as username or signed such as certificate) is a collection of one or more claims; a claim is declaration made by an entity • Proposes a standard set of SOAP (SOAP11, SOAP 12) extensions to be used when building secure Web services CIS*6650.01

35. Integrity Example (Sender) • Send a SOAP message and ensure that the body is not modified • Generate a digest of the SOAP body • Generate a signature over the digest using my private key • Include sender’s certificate (which includes sender’s public key) in a security token CIS*6650.01

36. Integrity Example (Receiver) • Check that the body of the message wasn’t modified • Generate a digest of the SOAP body • Verify the signature using sender’s public key (received in the certificate) • Compare the two values and ensure they match • Conclude that the message was from the sender you believe s/he sent it CIS*6650.01

37. Security Standards • Specifications for any XML-based interactions • WS-* security standards based on “IBM & Microsoft Roadmap” Source: Securing Service-based Interactions (see resources for link to paper) CIS*6650.01

38. Will the standards work together? • Sample 1: • A user requests services from a number of providers • User must be authenticated for every service to determine level of access • Authentication for each request is not practical (use single sign-on). Initial service provider authenticates, and subsequent requests from same user to other providers are automatically authenticated. Two ways to do this: • Have the authentication info for each service included in the initial SOAP message (SAML and XACML) • Use a user’s authentication list in a central database (Microsoft Passport) CIS*6650.01

39. Will the standards work together? • Sample 2: • Alice uses XML signature and XML encryption to sign and encrypt a document representing a purchase order (PO) • Alice sends the signed document to the supplier using SOAP, header defined using WS-Security • Receiver may use XKMS to discover and validate Alice’s public key • If valid, receiver can validate and decrypt PO • Receiver checks a policy server that maintains access control policy information in XACML for authorization using SAML requests/responses CIS*6650.01

40. SOAP Headers • They are the extensibility point for SOAP messages. • This is where the security metadata go • Security tokens, message digests, signing algorithms, etc. • SOAP security builds on XML-Encryption and XML-Digital Signatures • Example to follow… CIS*6650.01

41. Example • Security Header CIS*6650.01

42. User Name Token • UserName Token <S11:Envelope> <S11:Header> <wsse:Security> <wsse:UsernameToken> <wsse:Username> qmahmoud </wsse:Username> </wsse:UsernameToken> </wsse:Security> </S11:Header> … </S11:Envelope> CIS*6650.01

43. Full example • Showing: signature, digest value, binary security token to decrypt signature. Enough info to verify msg content <?xml version="1.0" encoding="utf-8"?> <S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="...“ xmlns:ds="..."> <S11:Header> <wsse:Security> <wsse:BinarySecurityToken ValueType="...#X509v3" EncodingType="...#Base64Binary“ wsu:Id="X509Token"> MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i... </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm=“…"/> <ds:SignatureMethod Algorithm=“…"/> <ds:Reference URI="#myBody"> <ds:Transforms><ds:Transform Algorithm= “…"/></ds:Transforms> <ds:DigestMethod Algorithm= “…"/> <ds:DigestValue>EULddytSo1...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>BL8jdfToEb1l/vXcMZNNjPOV... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference><wsse:Reference URI="#X509Token"/></wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S11:Header> <S11:Body wsu:Id="myBody"> … </S11:Body> </S11:Envelope> CIS*6650.01

44. SAML • An XML-based framework for exchanging security information • Enables disparate security services to interoperate • A set of specifications that define components • Assertions and request/response protocols • An assertion is a declaration of fact about a subject • Assertions can be digitally signed CIS*6650.01

45. SAML: How It Works SAML: How It Works Requestor Requestor 1 1 1 1 LDAP LDAP LDAP LDAP Directory Directory Directory Directory 2 2 2 2 3 3 3 3 4 4 4 4 Authentication Authentication Web Services Web Services Server Server Server Server SAML • Single Sign-On Source: Presentation by Abbie Barbir, Nortel Networks • 1. User accesses authentication server • Authentication server asks for user ID and password • 2. End user enters ID and password • Authentication server checks with LDAP directory and authenticates user • 3. End user requests a resource from destination/Web services server • Authentication server opens a session with destination server • 4. Authentication server sends uniform resource identifier (URI) to end user • End user browser is redirected to URI, that connects him to Web service CIS*6650.01

46. SOAP Message <SOAP-ENV: Envelope> </SOAP-ENV: Envelope> <SOAP-ENV: Header> <WS-Security> <SAML Token> </SAML Token> <WS-Security> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> WS-Security: Signature, Encryption SAML Token: Authentication, Authorization XML Signature: Integrity X.509 Certificate: Encryption, Signature verification Web Services Security • WS-Security • Securing SOAP • Work in progress • OASIS based • Supported by major players • Ensures Interoperability XML Schema Validation XML Encryption Multiple Parties Document parts Confidentiality Source: Presentation by Abbie Barbir, Nortel Networks CIS*6650.01

47. WS-I Specifications • Basic Security Profile • An extension of the Basic Profile • Provides guidelines and usage scenarios for WS-Security, REL (Rights Expression Language), SAML, UserName, and X.509 security token formats • Attempts to increase interoperability by addressing common problems that implementation experience has revealed (Rnnn) • Makes a number of security recommendations to improve security (Cnnn) CIS*6650.01

48. WS-I Basic Security Profile • Sample constraints • Web Services Security: SOAP Message Security defines a timestamp element for use in SOAP message. The profile places the following constraint on its use: R3227 A SECURITY_HEADER MUST NOT contain more than one TIMESTAMP R3203 A TIMESTAMP MUST contain exactly one CREATED CIS*6650.01

49. WS-I Specifications • Security Challenges, Threats, and Countermeasure (download from WS-I.org) Source: J2EE 5 Tutorial CIS*6650.01