StaticGround

Using the WS-Security you can make your web service communications more secure by using encryption, signing in addition to authentication and authorization. SOAP Header items can be encrypted using Username (user, passoword), Keberos or X.509 certificates. Electronic signatures are created using X.509 or Username tokens.

First, a few definitions:

• Use encryption to encode messages sent between the web service client and the web service server. In the case of a SOAP message, the SOAP body is usually encrypted using a public key (a subset of the private key located on the server) that is located on the client computer. The message body is encrypted using this key, and it is sent to the server. The server uses a private key to decode the message. Messages can use Username tokens or X.509 certificates for encryption. In the case of the Username token encryption, the Username token is used to encrypt the Soap body of the message on the client, and the Username token is also sent to the server in the Soap header. Once the server receives the message, the server uses the Username token sent in the header to decrypt the body of the message. With X.509 certificates, the server uses a private key assigned to it to extract a corresponding public key. The public key is then used by clients of the web service to encrypt messages sent to the server. Once the server receives the message, it uses the private key to decrypt the Soap body of the message. Since X.509 certficiates are used for encryption and not authorization, a Username token (Kerberos token) are still required for authentication and authorization. In addition to encrypting the body of the message, the Soap header can be encrypted as well. The entire header can be encrypted (including the username token) using an X.509 certificate.
  


• Use digital signing to mark the message with a unique identifier. The identifier is usually generated using an X.509 certificate, but a simple Username token can be used to generate a signature. The signature can be used by the web service to determine the identity of the message sender. Sending a signature instead of a username & password combination is preferred since no passwords are sent between the client and the web service. The authentication is based solely on the signature, since the signature was generated using partial information from a certificate on the web service server. The public key that a client uses to generate the signature is a portion of the private key present on the web server. If a message is received by a web service that requires signed messages, the web service might decide that the message has been tampered with and will not process the message.


• Username, and Keberos tokens can be used for authentication. The credentials are set by the client and read by the web service. When using Username tokens, passwords can be sent in either plain text or as hashes (digest). It is up to the web service to determine what type of tokens it will use, and the client must send compatible tokens to the server. The server can create policies which dictate what type of tokens are valid for authentication.
  


• Username tokens can also be used for authorization. If a client sends a username token to a web service, the web service will unencrypt the token and pass the token to the OS for authentication. If the authentication fails, an error is returned to the client. If the authentication succeeds, the WSE framework will check to see if the authenticated username token is authorized to access the requested resource (the web method the client is attempting to execute). If the token is not authorized access, an error is returned to the client. If the token is authorized access to the resource, the requested web method is executed and the results are returned to the client.
  
  Authorization can be implemented in two ways:
  
  
  
  1. Use WS-Policy to setup policies that are required by the web service. Each web service (.asmx) can be associated with one or more policies. A policy can be setup to allow only users in the Domain\Group access to the web methods exposed by the web service. To authorize access to the web methods in the web service, the WSE framework will first try to authenticate via the username token, and then it will determine if the role defined in the policy (in policyConfig.Cache) is in the list of roles associated with the username token.
  
  
  2. Programmatically send Username tokens to the web service. The client would create a UsernameToken object from the user credentials and add the token to the RequestSoapContext.Security.Tokens collection. The web server would then read the UsernameToken and authenticate the token. Once the token was authenticated, the web service could determine if the roles in the token include the required role defined in the web service and if so, authorize access to the requested resource. You could also intercept the authentication process by deriving a class from UsernameTokenManager and overriding the AuthenticateToken() method to look up the roles (in a DB) associated with the user in the token and add those roles to the principal associated with the token. The web service would then retrieve the token from the SoapContext.Security.Tokens collection and compare the required role to execute the web service with the role list from the token.
     
  
  
  
  

Usage	Username	X.509	Kerberos
Signing	Y	Y	N
Encryption	Y	Y	N
Authentication	Y	N	Y
Authorization	Y	N	Y