Web services security adds another level of protection to XML-based web applications by embedding security-related data within SOAP messages. For web services that Application Security Manager protects, you can use web services security to do the following:
If you want to use features such as encryption, you can add web services security to an existing security policy that has an associated XML profile. You can enforce web services security only for URLs.
Client and server certificates are XML digital signatures that ensure the integrity of the message data, and can authenticate the identity of the document signer. By importing client and server certificates, the system can perform encryption and decryption of SOAP messages.
The system uses client and server certificates differently:
To use web services security for encryption, decryption, and digital signature signing and verification, you must upload client and server certificates onto the Application Security Manager. The system uses these certificates to process Web Services Security markup in SOAP messages within requests and responses to and from web services.
You must import both client and server certificates to perform encryption and decryption on the Application Security Manager.
|Do not check role/actor||Process all security headers regardless of the role. This is the default setting.|
|Custom role/actor||Process security headers that contain the role you type in the adjacent box.|
|next||Process security headers that contain the role next or http://www.w3.org/2003/05/soap-envelope/role/next.|
|none||Process security headers that contain the role none or http://www.w3.org/2003/05/soap-envelope/role/none.|
|ultimateReceiver||Process security headers that contain the role ultimateReceiver or http://www.w3.org/2003/05 /soap-envelope/role/ultimateReceiver.|
|Do not assign role/actor||If the document contains a security header without a role, the system inserts the cryptographic information into the security header. This is the default setting.|
|Assign custom role/actor||If the document contains a security header with a custom role, the system inserts the cryptographic information into the existing security header. In the field, type the custom role/actor attribute.|
|next||If the document contains a security header with the next role, the system inserts the cryptographic information into that security header.|
|none||If the document contains a security header with the none role, the system inserts the cryptographic information into that security header.|
|ultimateReceiver||If the document contains a security header with the ultimateReceiver role, the system inserts the cryptographic information into that security header.|
You can write up to three XPath queries to define the content that you are looking for in XML documents. When writing XPath queries, you use a subset of the XPath syntax described in the XML Path Language (XPath) standard at http://www.w3.org/TR/xpath.
These are the rules for writing XPath queries for XML content-based routing.
This table shows the syntax to use for XPath expressions.
|Nodename||Selects all child nodes of the named node.|
|@Attname||Selects all attribute nodes of the named node.|
|/||Indicates XPath step.|
|//||Selects nodes that match the selection no matter where they are in the document.|
This table shows examples of XPath queries.
|/a||Selects the root element a.|
|//b||Selects all b elements wherever they appear in the document.|
|/a/b:*||Selects any element in a namespace bound to prefix b, which is a child of the root element a.|
|//a/b:c||Selects elements in the namespace of element c, which is bound to prefix b, and is a child of element a.|