eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Two specifications propose to fill the security gaps in SOAP: SAML, from OASIS, and WS-Security, from IBM, Microsoft Corp. and VeriSign Inc.
Neither of these standards has been widely adopted, but they are leading contenders for modeling how Web services security will eventually happen, and Web services adopters should be investigating them now. Security Assertion Markup Language and Web Services-Security have different strengths, so the two could be combined. In fact, this would be good for the industry.
SAML is the more mature and established standard. It was created last August and has since gone through a number of revisions. The specification was declared final by its developing committee April 19, and it is expected to become a ratified Organization for the Advancement of Structured Information Standards specification this summer. Baltimore Technologies plc., Hitachi Computer Products (America) Inc., Netegrity Inc., Systinet Corp. and VeriSign all offer products based on the technology.
The WS-Security 1.0 specification was published April 5, and IBM is the only company that has released prototype software based on it.
WS-Security is less ambitious than SAML in that it doesnt try to establish a universal framework to express user rights, nor does it provide a way to pass security credentials among security domains to build single-sign-on systems. However, WS-Security has the important advantage of supporting data encryption. SAML, in contrast, currently requires use of encrypted transport mechanisms such as HTTPS (Secure HTTP) to attain message security. WS-Security also has the backing of two of the largest developers of Web services software, IBM and Microsoft.
The current best practice for securing Web services is to use a Web servers document access security mechanisms—namely, HTTPS for encryption and HTTP for basic user authentication.
There are a number of problems with this approach. First, it ties Web services to HTTP and shuts out organizations that want to use other transport mechanisms, such as e-mail, message queuing, FTP or any other way XML data can be exchanged.
Second, it requires that Web services security be administered at the Web server layer. Its much more natural to administer Web services at the application server layer, where they are actually running, particularly if the same object has multiple access methods (Component Object Model, Enterprise JavaBeans and Web services, for example). Splitting up security administration so the same object needs to have its security administered in several places raises administration costs and security risks.
Third, placing security checks at the outside Web server means that if that Web service request is passed to an internal server or a third party for further processing (or if a Web service needs to access several resources to assemble a response), security information is lost when the request is passed on.
SAML, which requires the use of SOAP (Simple Object Access Protocol) as its Web services format, concerns itself only with authentication and authorization, as its main goal is to provide an XML-based way to allow single sign-on across organizational boundaries using Web services.
A typical SAML exchange is started by a client that sends a Web service request containing a SAML authentication request and the resource the client wants to access. The client (or subject) making the request can be a person, a server or a service.
SAML allows for 10 subject authentication mechanisms: user name/ password, Kerberos ticket, Secure Remote Password protocol (RFC 2945), hardware token, Secure Sockets Layer client-side certificate, X.509 public key, Pretty Good Privacy public key, Simple Public Key Infrastructure public key, XML Key Management Specification public key and XML Digital Signature.
If the SAML server can successfully authenticate the subject, it will return a security token to the client. The token is valid only for a certain amount of time and can restrict the user to particular levels of access, such as read, write or delete.
Importantly, the SAML server digitally signs its response using the XML Signature standard. The client can then use this token to make further requests, and its authenticity doesnt need to be checked again. It can even use the token with Web services hosted by other companies and, as long as these companies trust the issuer of the token, the user is trusted.
This single-sign-on capability allows Web services to be chained together or called many times by the same client without having to constantly check user credentials.
WS-Security has the same basic goal as SAML—to provide an interoperable, XML-based mechanism for providing access to a particular Web service.
However, WS-Security doesnt allow the transfer of security authorization among systems (necessary for single sign-on) because it doesnt separate the action of authentication from the Web service request itself. The request as a whole will either succeed or fail when it is processed, and since every request must include an authentication step, WS-Security will be more computationally intensive for multiple Web service requests from the same client than SAML is.
Like SAML, WS-Security requires SOAP as its underlying framework and is implemented using new XML tags embedded in SOAP messages.
WS-Security supports fewer authentication mechanisms than SAML: user name/password (the password can be sent in plain text or hashed), Kerberos ticket or X.509 certificate. However, WS-Security goes further than SAML in providing ways for the entire SOAP message (including parameters, returned data or attachments) to be sealed against tampering, signed to ensure sender identity and encrypted to provide confidentiality. SAML provides these guarantees only for the SAML security tags themselves, not for the rest of the Web service request.
Message signing and encryption in WS-Security is accomplished by using XML digital signature and encryption standards. Because WS-Security does not rely on the underlying transport protocol to provide these protections, it can be safely used on simpler, nonencrypted protocols (such as plain HTTP) without losing any security features.
Unlike SAML, WS-Security doesnt require HTTP at all, so organizations that want to use other data transmission techniques will find WS-Security a better fit.
Related Stories:
- Web Services Secure?
- Web Services Security: A Political Battlefield
- IBM and Systinet Write Next-Gen Tools