1 / 27

Web Service Security

Web Service Security. CS409 Application Services. Even Semester 2007. Compulsory Security Requirements. Confidentiality Guarantees that exchanged information is protected against eavesdroppers ( proof-of-possession ). Integrity Assurance that the message is NOT modified while in transit.

muhammad-jasmi
Download Presentation

Web Service 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 Service Security CS409 Application Services Even Semester 2007

  2. Compulsory Security Requirements • Confidentiality • Guarantees that exchanged information is protected against eavesdroppers (proof-of-possession). • Integrity • Assurance that the message is NOT modified while in transit. • Authentication • Guarantees that access is restricted to those who can provide proof-of-identity. • Nonrepudiation • Guarantees that the sender CANNOT deny having sent the message.

  3. Policy Security Token Service Claims Security Token Policy Requester Claims Security Token Policy Web Service Claims Security Token Web Service Security Model Fig 1. Security Model for Web Services

  4. Web Service Security Model (2) • Client wants to invoke web service and has claims (statement) such as its identity and privileges. • Web service has policy that requires message encryption and requestor authentication. • Client must send message that meets the security policy.

  5. Web Service Security Model (3) • Claims are included in security token that is attached to the request message, • e.g. assert sender’s identity or authorized role. • Some security tokens must be issued by a third party (security token service or STS). • STS is a web service as well and has its own policies, claims, and security tokens.

  6. Web Service Security Specification WS- SecureConversation WS- Federation WS- Authorization WS- Policy WS- Trust WS- Privacy WS- Security SOAP Foundation Fig 2. Roadmap of Web Services Security Specifications

  7. Web Service Security Specification (2) • WS-Security  • Defines how to include security tokens in SOAP message. • How to protect message with digital signature and encryption. • WS-Policy • Provides a framework for describing web services meta-data information. • WS-Trust • Interaction protocol to access Security Token Services.

  8. WS Security Specification (3) • WS-SecureConversation • Defines security context among parties that can share secret key and encrypts message portion. • WS-Federation • Provides framework for federating multiple security domains. • WS-Privacy • Describing the privacy policy of web services. • WS-Authorization • Defines how to exchange authorization information (as security token) among parties.

  9. WS-Security • Security issues addressed by WS-Security: • Identity • Authentication. • Authorization. • Integrity. • Confidentiality.

  10. WS-Security Basic Syntax <Envelope> xmlns=“http://schemas.xmlsoap.org/soap/envelope/” <Header> <wsse:Security xmlns:wsse=“http://schemas.xmlsoap.org/ws/2003/06/secext”> <Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”> . . . </Signature> <EncryptedKey xmlns=“http://www.w3.org/2001/04/enc-enc-enc#”> . . . </EncryptedKey> <wsse:UsernameToken xmlns=“http://schemas.xmlsoap.org/ws/2003/06/secext”> . . . </wsse:UsernameToken> </wsse:Security> </Header> <Body> . . . </Body> </Envelope>

  11. Digital Signature <Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”> <SignedInfo> <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#” /> <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1” /> <Reference URI=“#body_id”> <Transforms> <Transform Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”> </Transforms> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1” /> <DigestValue>U2BIJSK . . .</DigestValue> </Reference> </SignedInfo> <SignatureValue> Ojjw8nk . . . <!-- Binary codes goes here --> </SignatureValue> <KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI=“#bst_id” /> </wsse:SecurityTokenReference> </KeyInfo> </Signature>

  12. Digital Signature (2) • Determine whether a message was altered in transit. • Verify that message was sent by possessor of particular security token. • CanonicalizationMethod is a way to guarantee that two equivalent bits of XML are represented the same so that they can be signed.

  13. Processing Digital Signature • Define target to be signed (header or body). • Translate the target using CanonicalizationMethod (XML-C14N or EXC-C14N) to check if the XMLs are semantically equivalent. • Calculate digest value using algorithm specified in DigestMethod. • Signed the SignedInfo element using algorithm specified in SignatureMethod. • The calculated signature is then inserted into SignatureValue element.

  14. Verifying Digital Signature • Check the value in DigestValue element according to DigestMethod and Transform algorithms. • Calculate the digest value for the SignedInfo subtree. • Compare the digest value with the value in SignatureValue.

  15. Encryption <SOAP-ENV:Header> <EncryptedKey xmlns=“http://www.w3.org/2001/04/xmlenc#”> <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#rsa-1_5” /> <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”> <!-- Specifies the receiver’s public key --> <wsse:SecurityTokenReference> <wsse:KeyIdentifier> u3AA1M+ . . . OKBck= </wsse:KeyIdentifier> </wsse:SecurityTokenReference> </KeyInfo> <CipherData> <!-- This is where the encrypted key is stored --> <CipherValue>cdkffgkf . . . </CipherValue> </CipherData> <ReferenceList> <DataReference URI=“#ws-security_encryption_id_51277932543663” /> </ReferenceList> </EncryptedKey> </SOAP-ENV:Header>

  16. Encryption (2) <SOAP-ENV:Body> <po xmlns=“http://www.doddystore.com/ns/po-with-creditcardnumber” id=“43871” submitted=“2006-03-14” customerID=“73852”> <EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#” Id =“#ws-security_encryption_id_51277932543663” Type=“http://www.w3.org/2001/04/xmlenc#Content” > <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/tripledes-cbc” /> <CipherData> <!-- This is where the credit card number encrypted data is stored --> <CipherValue>cdkffgkf . . . </CipherValue> </CipherData> </EncryptedData> <shipTo> . . . </shipTo> <order> <item> . . . </item> <item> . . . </item> </order> </po> </SOAP-ENV:Body>

  17. Encryption (3) • The XML Encryption specification defines a means to do selective-encryption on XML document. • The descriptor of the encrypted portion is not necessarily the receiver of message. • Encrypt elements with key. • Encrypt key with recipient’s key. • Embed in header.

  18. Security Token • The simplest security token: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope“ xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"> <SOAP-ENV:Header> ... <wsse:Security> <wsse:UsernameToken> <wsse:Username>dlukito</wsse:Username> <wsse:Password>passwordForUserDlukito</wsse:Password> </wsse:UsernameToken> </wsse:Security> ... </SOAP-ENV:Header> </SOAP-ENV:Envelope>

  19. Security Token (2) • Binary security token: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope“ xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"> <SOAP-ENV:Header> ... <wsse:Security> <wsse:BinarySecurityToken xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext“ Id="myToken“ ValueType="wsse:Kerberosv5ST“ EncodingType="wsse:Base64Binary"> MIIEZzCCA9CgAwIBAgIQEmtJZc0... </wsse:BinarySecurityToken> </wsse:Security> ... </SOAP-ENV:Header> </SOAP-ENV:Envelope>

  20. Security Token (3) • BinarySecurityToken is defined to contain binary data such as X.509 certificates and Kerberos tickets. • ValueType indicates the kind of token, e.g. X509v3, Kerberos5ST, etc. • EncodingType specifies the encoding format for the binary data, e.g. base 64.

  21. Other Security Specificationsin The Roadmap • Please read: Building Web Services with Java : Making Sense of XML, SOAP, WSDL, and UDDI, (2nd Edition)by Steve Graham, et al. • Chapter 9, page 474 to 495.

  22. Newer Security Specifications • Such as: • XACML = Extensible Access Control Markup Language. • XrML = Extensible Rights Markup Language. • XKMS = XML Key Management Specification. • SAML = Security Assertion Markup Language. • etc ...

  23. XACML • XACML is an OASIS standard that describes both a policy language and an access control decision request/response language (both encoded in XML). • The policy language is used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc.

  24. XrML • XrML is the Digital Rights Language of choice that provides a universal method for securely specifying and managing rights and conditions associated with all kinds of resources including digital content as well as services.

  25. XKMS • Specification that defines a protocol for distributing and registering public keys. • Using this technology, developers will be able to take advantage of XKMS to integrate authentication, digital signature, and encryption services, such as certificate processing and revocation status-checking.

  26. SAML • Is a derivative of XML which is designed for the exchange of authentication and authorization data. • The purpose is to enable Single Sign-On for web applications. • SAML utilizes TLS (Transport Layer Security) to ensure the confidentiality of authentication and authorization data during transit.

  27. Thank You Doddy Lukito dlukito@infinitechnology.com dlukito@alumni.carnegiemellon.edu

More Related