SAML from OASIS has been around for more than two years and now has maturity-level status, but they keep saying...
that there are no security standards for Web services. Is it not enough? The SAML 1.0 specification is nearing adoption. It has reached the OASIS "committee specification" maturity level and now needs only OASIS membership approval to become a fully approved OASIS standard. The voting period for this process began September 30, 2002, and will end October 31, 2002. SAML defines a protocol for exchanging security information (what SAML calls security assertions). This is a key element in making security work in a distributed environment because it affords the opportunity for security systems to be federated. However, a standard way to exchange security assertions is a necessary but not sufficient capability for a full security system. For example, OASIS is also working on the Web Services Security specification. This specification defines a framework for embedding security information in SOAP messages. Using the framework, a specific ?binding? is then developed for defining how SAML security assertions are represented in a Web services security-compliant SOAP header. Note that other bindings are required for X.509 certificates, Kerberos tickets, etc. Even with these mechanisms in place there are still standardization issues around obtaining a security assertion or X.509 certificate in the first place. The Liberty alliance and others are defining how standards such as SAML should be used to implement security. The problems of identifying and authenticating (I & A) the ?requestor? is only one aspect of security. Other issues (such as authorization, data and message privacy and integrity, etc.) are prevalent in the Web services world. An example of work in these other areas is the OASIS XACML standardization effort. It is a standard representation for authorization rules so that a single set of rules can be portable across security systems.
That stated, it is possible to build and deploy secure Web services today. However, because all the necessary standards are not in place, your secure Web services might not be interoperable with other secure Web services. Authentication can be handled in a number of ways, using authentication mechanisms built into Web services "containers" such as HTTP Basic, or client certificates. You can use one of the existing single-sign-on products (which usually rely on the HTTP transport, by the way) or simply supply credentials (identity and proof) in the messages sent. One very simple form of I & A that can be used today is to include a username and password within the request message. Alternatively, you can digitally sign your XML requests using the WS-Security model in conjunction with the XML Digital Signature specification (W3C & IETF). Data privacy can be handled by using a transport that handles SSL connections, such as HTTPS. Use of the XML Encryption specification is yet another option for this. While the standardization effort, now underway in the W3C, is not yet finalized, there are toolkits already available that enable you to encrypt and decrypt XML documents, such as SOAP messages.
Dig Deeper on Securing services
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.