Several of my recent projects have involved building web services architecture using webMethods Integration Server. A couple of these have required some level of support for WS-Security.
WS-Security support is not included in webMethods Integration 6.x although it is included in the soon-to-be-released ServiceNet 6.5. So, what do you do when you need to expose IS services as web services and protect those services using WS-Security?
From the abstract of the WS-Security Soap Message Security specification, WS-Security “describes enhancements to SOAP messaging to provide message integrity and confidentiality” and “provides a general-purpose mechanism for associating security tokens with message content”.
Message integrity and confidentiality are accomplished by digitally signing or encrypting portions of the soap message. These goals are accomplished through the use of XML Digital Signature and XML Encryption respectively.
The goal of supporting security tokens is addressed in the Username Token Profile, X509 Certificate Profiles and SAML Token Profile respectively.
These profiles describe the correct syntax for including one of these tokens in the soap header as well as the rules for how the tokens are to be processed. Because the WS-Security framework is extensible, you can also define and specify other types of security tokens to suit your specific requirements.
The initial phase of my current project requires support of UsernameTokens. This type of token provides a method of including username and password information in the soap header such that the password is never sent in clear text. Use of Username Tokens also provides countermeasures against replay attacks.
Because webMethods IS does not provide support for headers in SoapRPC messages, you are limited to using the Document/Literal style to create IS web services which support WS-Security. I have written about ways to simplify creation of IS document/literal web services before. Basically, adding WS-Security support involves creating a custom soap processor that understands how to extract the wsse:Security element from a soap header, extract the security token from that element and execute the appropriate service to authenticate the token.
Because SAML tokens can also contain assertions about resources the user is entitled to access or invoke, it can also be used to determine whether the (now authenticated) user is authorized to invoke the service specified in the body of the soap message.
Since IS 6.5 has shipped without WS-Security support and the next major release is still months away, more and more companies will need to find an approach for adding WS-Security support to IS 4.6 and 6.x. This approach requires a bit of careful design and some up front architecture development, but, once implemented, provides the enhanced web services security with almost no impact to developers of IS web services.