The security Web Service3 provides operations to enforce the security require-
ments of BPEL activities.
7.3.1
The interface
The operations of the security Web Service are grouped in two port types: one for secure messaging (according to WS-Security) and one for secure conversa- tions (according to WS-SecureConversation).
String addToken(String msg, String tokenid , String tokentype, boolean encrypted , String actor , int timetolive ) boolean checkToken(String msg, string tokentype)
String signMessage(String msg, String algorithm , String name, boolean useSingleCert , int keyIdType, String actor , int timetolive ) boolean checkSignature( String msg, String algorithm)
String encryptMessage(String msg, String key, String symEncAlgorithm, String keyEnc, String transportKeyId , int keyIdType, String actor , int timetolive )
String decryptMessage(String msg, String symEncAlgorithm)
Listing 7.6: The secure messaging port type
Secure messaging port type
Listing 7.6 shows the operations of the secure messaging port type. This port type provides operations for adding a user name or a binary token to a message, checking an authentication token, adding a signature to a message, checking
3Parts of this section were published in the Paper Using Aspects for Security Engineering of Web Service Compositions, ICWS 05 [36].
a signed message, encrypting a message, and decrypting a message. All these operations take the SOAP message as the first parameter. Some of them return a String representation of the SOAP message after processing it according to WS-Security. The operations checkSignature and checkToken return a boolean indicating whether the authentication token or the signature is valid.
The operation addToken takes several parameters in addition to the SOAP message. The parameter tokenid can be either a user name (in the case of user name tokens) or an identifier of an X.509 certificate (in the case of binary tokens). The parameter tokentype is a URI that uniquely identifies the type of the authentication token. The parameter encrypted specifies whether the password should be encrypted in case of a user name token. It is ignored in the case of an X.509 certificate.
The passwords for username tokens and for accessing a certificate from the keystore are not passed to the operation addToken as parameter. Instead, they are retrieved from the password store component of the security Web Service. In this way, the deployer does not have to specify sensitive information such as passwords in the deployment descriptor.
The parameters actor and timetolive appear in the signature of several op- erations of the security Web Service. The parameter actor defines which role is allowed to process the security header. The parameter timetolive defines a validity period for the security header.
The operation checkToken verifies whether the authentication token that is contained in the security header of a SOAP message is valid. The parameter tokentype allows the security Web Service to find out which handler should be used to validate the token (e.g., the X.509 handler). Without this parameter, the security Web Service would have to parse the entire SOAP message to find the corresponding handler.
The parameters of the operation signMessage have the following meaning: The parameter algorithm specifies the algorithm that should be used to sign the message. The parameter name identifies the key or certificate that should be used to generate the signature. The parameter useSingleCert specifies whether one certificate or a certificate chain should be used to generate the signature. The parameter keyIndentifierType determines how the key or certificate that is used to sign the message is referenced in the secured SOAP message.
In addition to the SOAP message, the operation checkSignature takes a parameter called algorithm, which allows the security Web Service to find the appropriate handler for verifying the signature without parsing the entire SOAP message.
Secure conversation port type
Listing 7.7 shows the operations of the secure conversation port type. This port type provides operations for establishing and canceling security contexts using the Security Token Service (STS) of a partner Web Service. Moreover, it includes operations for using a security context to encrypt messages, decrypt messages, sign messages, and check signed messages.
In these operations, the parameter partner is an identifier for a security context that is established between the client (e.g., the BPEL process) and the Web Service (e.g., the partner). The parameter partnerSTSURI is the URI
of the Security Token Service (STS) of that Web Service. The security Web Service interacts with the STS to create and to cancel a security context.
boolean createContext( String partner , String partnerSTSURI, String keyType, String keySize , String signWith, Sring encryptWith,
String responseSignatureAlgo , String responseEncryptionAlgo, String requestSignatureAlgo , String username)
boolean cancelContext( String partner , URI partnerSTSURI) String signWithContext(String partner , String message,
boolean useDK, int generation ) boolean checkSignatureWithContext(String message)
String encryptWithContext(String partner , String message, boolean useDK, int generation ) String decryptWithContext (String message)
Listing 7.7: The secure conversation port type
The operation createContext takes several parameters that allow an ad- vanced and flexible configuration of the security context that will be created. The parameters keyType and keySize respectively define the type and the length of keys in the security context that will be established. The parameters sign- With and encryptWith specify the signature and the encryption algorithms that should be used for this context. The parameters responseSignatureAlgo and re- sponseEncryptionAlgo specify whether the response of the Security Token Ser- vice should be signed or encrypted and what algorithms to use for that. If the request message to the Security Token Service has to be signed, the parameter requestSignatureAlgo should be set to the name of the algorithm for signing and the parameter username should specify the certificate that will be used for signing.
The operations signWithContext and encryptWithContext take a parameter useDK, which specifies whether derived keys should be used. These derived keys are generated from the keys that were exchanged during context creation. They make the interactions between the client and the Web Service more secure. The generation of derived keys can be done in several steps and the parameter generation specifies the step that should be used.
7.3.2
Usage by the process container
To secure a messaging activity, the process container intercepts the point where the SOAP message corresponding to that activity is received or is about to be sent out. In the AO4BPEL-based implementation of the container, this interception is done by the cross-layer pointcut designators soapmessageout and soapmessagin, which are used together with messaging activities. Then, the container calls the appropriate operation on the security Web Service (the secure messaging port type), which modifies or verifies the SOAP message according to WS-Security. In the AO4BPEL-based implementation of the container, this invocation is done by the advice activity.
In Figure 6.1, the container intercepts the execution of the invoke activ- ity that calls the operation credit (arrow 2). Then, it calls the operation en- cryptMessage on the security Web Service to encrypt the corresponding SOAP message (arrow 3). The security Web Service returns the encrypted message to
the BPEL engine (arrow 4), which resumes the suspended invoke activity. The latter sends the encrypted message instead of the original one (arrow 5).
Figure 7.4 illustrates how the container interacts with the security Web Service to execute a structured activity and its nested messaging activities using a secure conversation. In that figure, the process contains a sequence activity, which has two nested invoke activities that interact with the same partner.
SWS createContext encryptWithContext Process Container <process> ... <sequence> <invoke operation=“A“/> <invoke operation=“B“/> </sequence> ... </process> <invoke operation=“A“/> <invoke operation=“A“/> <invoke operation=“A“/> <invoke operation=“B“/> <invoke operation=“A“/> invoke operation=“B“/> <invoke operation=“A“/> <invoke operation=“B“/> CreateContext Aspect EncryptWith- Context Aspect <sequence> <sequence> <sequence> <sequence> <sequence> <sequence> <sequence> e1, uri1 e1, SOAP, false, 0
e1, uri1 Partner Aspects Other Aspect Types Middleware Services DestroyContext Aspect cancelContext e1, SOAP, false, 0
</sequence> </sequence> </sequence> encrypted SOAP Security Token Service
Figure 7.4: Interaction of the container and the security service
Figure 7.4 shows that three aspect types are involved in the execution of a structured activity using a secure conversation: the aspect type for creating a security context, the aspect type for destroying a context, and the aspect type for encrypting a message with a context (cf. Table 7.1).
When the sequence activity starts, a container aspect calls the operation createContext on the security Web Service. The parameter e1 identifies the security context that should be established and the parameter uri1 is the URI of the Security Token Service of the partner Web Service. Then, for each nested invoke activity, another container aspect calls the operation encryptWithContext on the security Web Service. This operation takes the context identifier e1 as a parameter in addition to the SOAP message, a boolean indicating whether a derived key should be used, and the generation step. When the sequence completes, the process container calls the operation cancelContext to remove the context e1.
7.3.3
The implementation
The security Web Service consists of three main components:
• The security manager is the central component of the security Web Ser- vice. It manages the different handlers and stores that are available.
• The stores contain sensitive security information of a given type. There is a store for passwords, a store for keys and certificates, and a store for security contexts.
• The handlers provide the core functionality of the security Web Service. For example, there is a handler for message encryption, a handler for
message signature, a handler for username tokens, etc. Through a config- uration file, new handlers can be added easily to the security Web Service.
The implementation of the security Web Service is based on Apache WSS4J [8], which is an Open Source implementation of WS-Security. WSS4J contains the necessary interfaces for WS-Trust and WS-Conversation but it does not provide any implementation of these interfaces.
To secure SOAP messages according to WS-Security, the handlers of the security Web Service use methods of WSS4J, e.g., to encrypt or to sign mes- sages. The implementation of the secure messaging port type with WSS4J was straightforward.
To support secure conversations, it was necessary to implement a conver- sation handler to tackle tasks such as context creation, context cancellation, encryption with context, etc. That is the interfaces that WSS4J provides for trust and secure conversation had to be implemented. In addition, it was nec- essary to implement an Axis handler, which should be deployed at the partner side. This handler processes the messages that were secured by the container aspects using the secure conversation port type. The secure conversation port type is implemented as follows.
When the operation createContext is called, the security Web Service stores the parameters of that operation in a secureContextStore that is indexed by the context identifier. Then, the security Web Service uses the secure conversation handler to send a request to the Security Token Service (STS) of the partner Web Service. If the STS can create a security context, it returns a positive response that contains information about the created context and a unique context identifier. The security Web Service stores this context information for later use in the secureContextStore.
When the operation signWithContext or encryptWithContext is called, the security Web Service retrieves the context information from the secureCon- textStore using the parameter partner, which identifies the secure conversation context. Then, it uses the algorithms and keys of that context together with the encryption and signature methods of WSS4J to perform the necessary func- tionality.
When the operation cancelContext is called, the secure conversation han- dler sends a request message to the Security Token Service of the partner to destroy the security context. Once the partner confirms that the context was deleted, the security Web Service removes the corresponding entry from the secureContextStore.