|
|
|
|
|
Overview
|
|
Since its inception in March 1995, when it was used in Netscape 1.1, SSL has become the de facto way to encrypt data sent between HTTP requesters (Web browsers) and HTTP servers (Web servers). Because of this, SSL is an obvious security choice for first-generation Web services. SSL works at the session layer of the OSI stack to provide point-to-point confidentiality and one-way or two-way authentication. Used alone, however, SSL does not provide complete protection for Web services.
|
|
Organizations usually secure company resources available on the network and online services by defining business roles, access rights, and system policies. That's where firewalls, among other mechanisms, have a role to play.
|
|
A network level firewall sits at the doorstep of a private network as a guard and typically provides the following security services:
|
- monitors all incoming traffic;
- checks the identity of information requesters trying to access specific company resources;
- authenticates users based on their identities, which can be the network addresses of service requesters or security tokens;
- checks security and business policies to filter access requests and verify whether the service requester has the right to access the intended resource;
- and provides for encrypted messages so that confidential business information can be sent across the untrusted Internet privately.
|
|
Web Services Security Specifications
|
|
Message level security technologies augment the security offered by SSL.Emerging XML security technologies can address the Web services security requirements that are not provided by SSL. XML security technologies work at the application or message layer of the OSI stack and use XML to simplify the delivery of security. A number of technologies exist that address the security issues.
|
XML Schema
http://www.w3.org/XML/Schema
|
|
To ensure that no malicious data is sent to a Web Service that would cause that service to fail, the content of a message can be verified against an XML Schema. This ensures that the structure of the message is correct and may also involve checking that the values of parameters meet those outlined in the XML Schema.
|
XML Signature
http://www.w3.org/Signature
|
|
The XML Signature specification is a joint effort of W3C and IETF. It aims to provide data integrity and authentication (both message and signer authentication) features, wrapped inside XML format.
|
|
To ensure that data sent to the Web service has not been modified in transit the message can be signed on the client and the service provider can verify the XML Signature on receipt of the message. An XML Signature includes an X.509 certificate, which links the requester with the request and can be used to hold the requester accountable for their usage of the Web service. Verifying the signature provides proof of possession of the private key so the X.509 certificate contained within the signature can be used to authenticate the requester. This involves validating the status of the certificate, which can be achieved using XKMS.
|
XML Encryption
http://www.w3.org/Encryption
|
|
W3C's XML Encryption specification addresses the issue of data confidentiality using encryption techniques. Encrypted data is wrapped inside XML tags defined by the XML Encryption specification.
|
Soap Message Security or WS-Security (WSS)
http://www.oasis-open.org/committees/wss
|
|
WS-Security from OASIS defines the mechanism for including integrity, confidentiality, and single message authentication features within a SOAP message. WS-Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message.
|
|
WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies.
|
|
WS-Security also provides a general-purpose mechanism for associating security tokens with messages. No specific type of security token is required by WS-Security. It is designed to be extensible (e.g. support multiple security token formats). For example, a client might provide proof of identity and proof that they have a particular business certification.
|
|
Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message.
|
|
Composable Architecture: By using the SOAP extensibility model, SOAP-based specifications are designed to be composed with each other to provide a rich messaging environment. By itself, WS-Security does not ensure security nor does it provide a complete security solution. WS-Security is a building block that is used in conjunction with other Web service and application-specific protocols to accommodate a wide variety of security models and encryption technologies. Implementing WS-Security does not mean that an application cannot be attacked or that the security cannot be compromised.
|
XKMS
http://www.w3.org/2001/XKMS
|
|
XKMS (XML Key Management Specification) provides an XML interface to PKI services, including distribution, validation and revocation of keys. An XKMS service is a Web Service that allow users to register and revoke their keys using an easily programmable XML transaction. When the user sends a message, as part of the authentication process, the service provider can send a SOAP request to the XKMS service asking the XKMS service to verify the status of the user's X.509 certificate. Organizations deploying Web services could request that users should register with a particular XKMS service before consuming the Web service.
|
XACML
http://www.oasis-open.org/committees/xacml
|
|
eXtensible Access Control Markup Language (XACML) presented by OASIS lets you express your authorization and access policies in XML. XACML defines a vocabulary to specify subjects, rights, objects, and conditions -- the essential bits of all authorization policies in today's e-commerce applications.
|
XrML
http://www.oasis-open.org/committees/rights
|
|
eXtensible Rights Markup Language (XrML) provides a universal method for securely specifying and managing rights and conditions associated with all kinds of resources, including digital content and services.
|
Digital Signature Standard (DSS)
http://www.oasis-open.org/committees/dss
|
|
The goal of this specification is to support processing of digital signatures as Web Services, define a protocol for a standardized digital signature verification Web service that can verify signatures in relation to a given policy set, and define protocol to produce cryptographic time stamps that can be used for determining whether a signature was created within the associated key's validity period or before revocation.
|
Electronic Business XML (ebXML)
http://www.oasis-open.org/committees/regrep
|
|
An initiative between OASIS and united Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT). ebXML provides a technical framework that will enable XML to be utilized in a consistent manner for the exchange of all electronic business data.
|
Security Assertion Markup Language (SAML)
http://www.oasis-open.org/committees/security
|
|
Security Assertion Markup Language from OASIS provides a means for partner applications to share user authentication and authorization information. This is essentially the single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. In the absence of any standard protocol on sharing authentication information, vendors normally use cookies in HTTP communication to implement SSO. With the advent of SAML, this same data can be wrapped inside XML in a standard way, so that cookies are not needed and interoperable SSO can be achieved.
|
|
To achieve authorization in a distributed environment it is necessary to remove the dependence on localized user management. The SAML standard has been developed with this in mind. SAML enables authentication and authorization information to be shared by multiple parties across security domains. Authentication and authorization information is passed as XML assertions. A request may contain an assertion signed by a trusted SAML Authority that can be used by the service provider to authorize usage of the Web service. Alternatively the service provider may have to contact a trusted SAML Authority on receipt of a request to discover if the requester has permission to use the service requested. In this way SAML allows Web services providers to authorize (and authenticate) users without having to set up user accounts and specify permissions locally. Many access management products are adding support for SAML to ensure that they can share authorization information.
|
|
Used in conjunction with SSL these technologies can protect first generation Web services against unauthorized access and malicious damage. Logging and monitoring of activity in this environment is also critical for intrusion detection. XML Signature can again be used to sign transaction logs, ensuring that information cannot be modified to conceal actions taken.
|
|
Mapping Requirements, Technology and Standards
|
| Requirement |
Technology |
Standard |
| Authentication |
Username/Password, key based digital signing and signature verification, challenge/response, biometrics, smart cards, and more
|
XML Signature, XKMS, SAML, Java Card, J2SE, Kerberos, Generic Security Service (GSS), DSS, Federated Network Identity (Liberty)
|
| Authorization |
Application of policy, access control, digital rights management
|
Java Authentication and Authorization Services (JAAS), XACML, XrML, DSS
|
| Integrity |
Message Digest itself authenticated with digital signature
|
J2SE (Secure Hash Algorithm (SHA), MD5 and more), XML Signature, XKMS, XML Encryption
|
| Non-Repudiation |
Key-based signing and signature verification, message reliability
|
J2SE, Cert Path, XML Signature, XKMS, DSS
|
| Confidentiality |
Key-based digital encryption and decryption
|
J2SE (GSS, Java Cryptography Extension (JCE)), XML Encryption, XKMS
|
| Audit |
Various forms of logging, themselves secured to avoid tampering
|
XML Signature, XKMS, J2SE Logging
|
| Trust |
Key-based signing and signature verification
|
J2SE (Cert Path, GSS), XML Signature, XKMS, DSS
|
|
