“A Web Service is a system designed to support interoperable communication from machine to machine over a network. It includes an interface described in a machine-processable format (WSDL), and is typically conveyed using HTTP with XML serialization.”
Webservices exist in a wide range of architecture, technologies and software design. They provide an interaction mechanism between Business to Business applications. Webservices rely on SOAP Protocol for the interaction between the B2B applications. SOAP is and XML Based protocol that uses HTTP as its base transport protocol. Following is an example of a SOAP Request and SOAP Response
For a secure environment data exchange cannot happen in clear text as sensitive information might be exchanged. Also securing the communication channel for all communication is an overhead and might not be acceptable in all scenarios. Hence many specifications exist which allows to secure the data exchanged. One such framework is WS-Policy which defines how secure messages can be exchanged. To demonstrate this I have secured the above Webservice using standard policies and captured the SOAP Request and SOAP Response
Following is the lists of supported tokens that can be used for authentication and authorization purposes
Lists of tokens (Table 1)
User Name Token-Plain
Carries basic information (username and a clear text password or shared secret) for purposes of authenticating the user identity to the WSP. Communication is done in plain text so SSL over HTTPS transport must be used to protect the credentials.
Carries basic information (username and, optionally, a password or shared secret), in a Kerberos token, for purposes of authenticating the user identity to the WSP.
Contains an X.509 formatted certificate for authentication using credentials created with a public key infrastructure (PKI). In this case, the WSC and WSP must trust each other’s public keys or share a common, trusted certificate authority.
Uses the SAML holder-of-key confirmation method whereby the WSC supplies a SAML assertion with public key information as the means for authenticating the requester to the web service provider. A second signature binds the assertion to the SOAP payload. Can use either SAML v1.x or SAML v2.
SAML-Sender Vouches Token
Uses the SAML sender-vouches confirmation method whereby the WSC adds a SAML assertion and a digital signature to a SOAP header. A sender certificate or public key is also provided with the signature. Can use either SAML v1.x or SAML v2.
Key Exchange using WS-Trust
In the model above it’s the responsibility of the server to validate the tokens, signatures and perform authentication and authorization. This again can be an overhead, especially if the numbers of clients are very high. Also if the client is not known to the Service, it becomes difficult to establish a trust with the client. To address this situation WS-Trust standard has been adopted. In this model, the responsibility of establishing the trust has been assigned to a third party. Clients request for a Security Token from a Secure Token Server (STS). Once they get the token, they present the token to the Service. The exchange mechanism and standard format of the token has been provided in WS-Trust specification. In my test, I used opensso (an open source STS Server) and captured the request-response interaction as depicted in Figure below.
1)Client requests for a Security token to a Secure Token Server