Web Service Security

Web Service Security  

The three primary aspects of Services Portal (SP) web services security are outlined below:

• Secure Communication - All web service messaging takes place over secure, anonymous SSL connections (HTTPS). This transport-level security provides a secure point-to-point connection between the web service client and the Services Portal. Message-level encryption is not be used in the SOAP exchanges.
• Authentication - All SP web service clients are required to incorporate a standard WS-Security-compliant header in each web service request. The header contains client credential information which is extracted by the web application server and authenticated against the SP user registry.
• Authorization - Authorization takes place in the stored procedures using credential information which is tunneled through each stored procedure's company ID and user ID input parameters.
  Since the method being used to secure and authorize web service communications and requests is identical to the approach currently used in the SP web application, a detailed description will not be included. However, the methods used to convey client credentials to the server differ substantially between web service and browser-based web applications.
   

  Exchanging Authentication Credentials

As previously described, authentication credentials must be conveyed in each web service request in the form of a WS-Security-compliant header inserted into the SOAP envelope. The following example illustrates the SOAP format of a prototypical SP web service request containing the required header.

This is only a sample SOAP Envelope and Header

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soap:Header>
        <wsse:Security soap:mustUnderstand="1" >
            <wsse:UsernameToken>
                <wsse:Username>USER@CUSTOMER</wsse:Username>
                <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">PASSWORD</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
    </soap:Header>
 
    ... SOAP body goes here ...
 
</soap:Envelope>

The <soapenv:Header> area illustrates the WS-Security header which contains a Username Token element. The username token element contains username and password elements. The username data consists of a string concatenated from the client's company ID, user ID (e.g. UserId@CompanyId). The security header is followed by the SOAP request body which contains the actual web service invocation information.

It's important to note that the SOAP security header is not part of the web service interface and is therefore not defined in its associated WSDL file. Clients will be required to insert properly formatted security headers in each SOAP request. The SP will be configured to enforce this requirement and authenticate the credentials in properly formed security headers. Control will be passed to the actual web service only after an authenticated security context can be established.