Version: 1.0.0
Copyright © 2012 Stratumsoft Technologies Pvt. Ltd.
Build Date: 20120527-1330
Table of Contents
List of Figures
List of Tables
Welcome to the Examine product documentation. Examine is a web-based functional web services testing tool. It can be used for testing SOAP and REST web services and has good support for ws-security functionality testing. This guide describes the functions and features available in the Examine product.
Table of Contents
Extract the zip file in a location of your choice. Examine is bundled as a web
application within Jetty 7. To start Jetty, execute either the
start_examine.sh (on Linux / Mac) or start_examine.bat
(on Windows) file.
By default, Jetty will be started on port 8080, but this can be
changed if there is any conflict. To do so either:
pass the target port number as the first argument of the shell script, or
open either the start_examine.[bat/sh] file (depending on
the platform in use) and edit the value of the JETTY_PORT
variable (to make the change permanent)
Also, the stop port is set by the environment variable JETTY_STOPPORT
and defaults to 8079. To change this either update the value of the
variable in the shell script or pass the new port as the second argument for the
script when running it. The scripts stop_examine.[bat/sh] can be used
to stop a remote running server instance if access to the console where it was
started is not available
By default, there is no HTTPS port configured, but if you would like to enable SSL,
a new connector must be added and configured in the etc/jetty-ssl.xml
file as follows:
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
<Arg>
<New class="org.eclipse.jetty.http.ssl.SslContextFactory">
<Set name="port">8443</Set>
<Set name="keyStore"><SystemProperty name="jetty.home" default="." />/etc/keystore</Set>
<Set name="keyStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
<Set name="keyManagerPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
<Set name="trustStore"><SystemProperty name="jetty.home" default="." />/etc/keystore</Set>
<Set name="trustStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
</New>
</Arg
<Set name="maxIdleTime">30000</Set>
</New>
</Arg>
</Call>
Please refer to the Jetty SSL configuration documentation for more information: http://wiki.eclipse.org/Jetty/Howto/Configure_SSL
Table of Contents
Examine allows multiple user access to the application. The number of concurrent users that can be logged on at the same time is determined by the license in use. There are two types of users that can acccess the application -
Regular users like Developers and QA personnel who would like to log in and use the application to test web services
Administrators are users who would like manage the Examine application itself to configure the various options like license, authorized users and view/delete user sessions, email and jabber server configuration etc.
By default, Examine has one pre-defined user account defined with Administrator access. This account has the username of 'admin' and the default pasword is set to 'admin'.
It is highly recommended that this account be either disabled or the password reset after Examine is installed and started correctly. To do this, login as user ‘admin’ and navigate to -> and click on user ‘admin’. Then update the password and click on ‘Save’ to save the updated values.
The ‘Administration’ tab will be available only for users in admin role.
The figure below shows the user management interface with the admin user configured with Administrator access
To add a new click on ‘Create User’ and specify the user details using the New User dialog shown below:
Checking the “Is Administrator” checkbox will create the user in
Administrator role
To delete an existing user, select a user from the two-select table and click on ‘Delete User’. You can also disable the user account by unchecking the “Account Enabled” checkbox.
Examine can be configured with a global email server that can be used to:
Send notifications on Test Suite completions
Send password change notifications
The following fields are required fields:
The hostname of the email server
The email server port to use
the from email address that Examine should use to send emails
The username and password fields are required to login to the mail server to send emails
The connection timeout specifies the socket connection timeout value in milliseconds. Default is infinite timeout
The read timeout specifies the socket I/O timeout value in milliseconds. Default is infinite timeout
If the email server is configured to use SSL/TLS, then enable the ‘Use SSL/TLS’ By default, ‘Trust server certificate’ option is enabled, which means that Examine will accept any server provided certificate for SSL connection. This option is useful when using a test email server that uses a self-signed certificate. It is recommended to NOT use this option for production systems and instead explicitly specify the server certificate to use by clicking on the link. (See section on how to configure Keystores)
The Check Server Identity option allows Examine to verify the certificate provided by the server contains the correct host name during SSL negotiation. By default it is unchecked to not perform this validity check.
If you have a Gmail accout, it is easy to setup it up as the main Email server to send email notifications.
Enter the Host value as
smtp.gmail.com
Enter the Port number as
465
Enter the From value with your email address
such as user@gmail.com
Enter the Username and
Password values. Note that the username
must be entered as user@gmail.com
Select the checkbox and also select the checkbox.
Leave the checkbox unchecked.
Examine can be configured to send Test Suite completion notifications using the XMPP/Jabber protocol. To enable this functionality, the administrator must configure a Jabber server using the ->
The option instructs Examine to establish an XMPP connection on server startup. If a connection cannot be established on startup, an error will be logged on the console and notifications may not be delivered to the recipients correctly. So it is recommended that this option be enabled after verifying that a test instant message can be sent.
The Host, Port values correspond to the Jabber server host and port.
The username and password to log into the Jabber server must be specified as well if required.
If TLS/SSL option is enabled, all XMPP communication with the Jabber server will
be secure. By default, Examine is configured to use to the default
cacerts truststore that comes bundled with the Sun JRE. This
truststore contains the certificate of well-known certificate authorities (CAs).
However, the administrator can override this option and select another truststore to
use. This option is useful when working with self-signed certificates that are not
issued by any CA.
The option enables SSL client-authentication with the IM server. By default this option is disabled as this requires that the client also possess a valid certificate. If the server running Examine contains a valid X.509 private / public key pair, then the keystore containing this key must be selected.
Ensure that the server where Examine is configured/installed can communicate
with Google Talk on talk.google.com and ports
5222 and 5223. Examine will
automatically use the SASL PLAIN authentication mechanism,
which is also the only Google Talk supported authentication mechanism.
TLS is required by default.
Enter the host name as gmail.com Leave the port number
empty - Examine will automatically use the correct port.
Enter your username as name@gmail.com and your gmail
password.
Ensure the checkbox is checked and leave the checked.
Test the configuration by clicking on Test and entering another gmail account
user as the recipient of the test message (as
name@gmail.com). Click Save to save the
configuration
If the IM server and the Jabber configuration is setup correctly, then
clicking on the button should make Examine to send
a test IM with the message: Success! This is a test message to confirm
that your Jabber configuration is correct!. A successful test
message as received in the iChat IM client is shown below:

By default, the product does not contain any license and is restricted to a 30-minute run, after which it will shutdown automatically. This also happens if the installed license is either invalid, missing or has expired.
To update or specify a new application license, start Examine and log in as an administrator and go to -> screen and click on and paste the new PGP license key contents and click to save it.
The license file contents are in PGP public-key format. A sample license file contents are shown below:
-----BEGIN PGP MESSAGE----- Version: BCPG v1.46 owJ4nJvAy8zAxGg9dZr30rA4QcbTB5ySxHMyk1PzilPdMnNS/RJzU3U90/Pyi1JT /CofWSnr6ipApRXSgPJcyuGpKQrBqQUKRoYKBpZWhgZWhuYKri4hCkYGhoZcYalF xZn5ebaGegZ6BlyuKZklIJ5rWWJOaSKIyeVYUAA0LhEiXJGYm5mXyhWWmJOZouuS WJJqCzJE18BS19Ccy7O4uDQVQ9Q1NzEzxzbRIUkvmcs5Py+5tKgoNa9EN7QYaLFt aV5OZm5mSWoKF8gbtiGpxSUKIBku/6L0xLzMKoi1YGFkEa5ORlUWBkYmBn5WJpCf OWRKgEqyUysZuDgFYCHF0sz+k/GY4fI9XiIslfsmKOWpPftRVqD94S1v36VuSe3k hntR24yfVU0xmfWspdnseMFih4w7SsmBQltU9Z/5XJDSvPaY0/RAYDdftYPlpU2/ Aj/tsnC9cWvhb9k0D/eYPWHquwV25uaobJF60pUvr5p31HOWQsT0RY8nr+24IqKc vdPv3+L4rSuzvtS9uMW24JLLfufOFC3xjZfqd7BwvIw+bHSoMX9F25fi4nlqW7Nr Tf8J2e9/v+2Nn1DxW+Md8TE8xt/+MjquihJRjHKakhHUvDR4LnMBb3nZ3l9PbLxd JXacfPtgzfnvsdU1IVqmKysP+R7d9mjpPcaMg0qnQ3z6jrR8Yd+2f6dJaVbilPCv ABrE45U= =V7d4 -----END PGP MESSAGE-----
The license file contents shown above are for an expired license and cannot not be used for running the application
If the number of currently logged in users equals the concurrent users count allowed by the license, then the next user who tries to login to the application cannot do so until an already logged in user logs out
It is possible to view the list of logged in users or active sessions through the administration option as shown below:
Clicking on the
icon deletes the related session and causes the logged in user
to be logged out immediately.
Table of Contents
The Profile tab displays the currently logged in user's details and is also the place where users can change their login password. The profile configuration screen is as shown below:
The Account Enabled checkbox is readonly and indicates whether the currently logged in user's account is enabled. Note that only an Administrator can enable/disable a user account as outlined in the User Management section
The Email Address and Jabber ID fields are required if you would like to receive Email and Instant Message (IM) notifications for scheduled Test Suite executions.
The Change Password section allows for resetting your login password.
Examine makes use of the Apache CXF-based HTTP client functionality and thus supports the same set of connection parameters. Every user logged into Examine can control the HTTP connection parameters by customizing the values under -> tab. The following are the set of parameters that can be set for the HTTP client.
Specifies the amount of time, in milliseconds, that the client will attempt to establish a connection before it times out. The default is 2000 (2 seconds). 0 specifies that the client will continue to attempt to open a connection indefinitely.
Specifies the amount of time, in milliseconds, that the client will wait for a response before it times out. The default is 60000. 0 specifies that the client will wait indefinitely.
Specifies if the client will automatically follow a server issued redirection. The default is false.
Specifies the maximum number of times a client will retransmit a request to satisfy a redirect. The default is -1 which specifies that unlimited retransmissions are allowed.
Specifies whether the client will send requests using chunking. The default is true which specifies that the client will use chunking when sending requests. Chunking cannot be used used if either of the following are true:
Client is configured to provide HTTP authentication credentials preemptively
AutoRedirect is set to true
In both cases the value of AllowChunking is ignored and chunking is disallowed.
Specifies the threshold at which CXF will switch from non-chunking to chunking. By default, messages less than 4K are buffered and sent non-chunked. Once this threshold is reached, the message is chunked.
Specifies what media types the client is prepared to handle. The value is used as the value of the HTTP Accept property. The value of the attribute is specified using as multipurpose internet mail extensions (MIME) types. See note about chunking below.
Specifies what language (for example, American English) the client prefers for the purposes of receiving a response. The value is used as the value of the HTTP AcceptLanguage property. Language tags are regulated by the International Organization for Standards (ISO) and are typically formed by combining a language code, determined by the ISO-639 standard, and country code, determined by the ISO-3166 standard, separated by a hyphen. For example, en-US represents American English.
Specifies what content encodings the client is prepared to handle. Content encoding labels are regulated by the Internet Assigned Numbers Authority (IANA). The value is used as the value of the HTTP AcceptEncoding property.
Specifies the media type of the data being sent in the body of a message. Media types are specified using multipurpose internet mail extensions (MIME) types. The value is used as the value of the HTTP ContentType property. The default is text/xml.
For web services, this should be set to text/xml. If the client is sending HTML form data to a CGI script, this should be set to application/x-www-form-urlencoded. If the HTTP POST request is bound to a fixed payload format (as opposed to SOAP), the content type is typically set to application/octet-stream.
Specifies the Internet host and port number of the resource on which the request is being invoked. The value is used as the value of the HTTP Host property.
This attribute is typically not required. It is only required by certain DNS scenarios or application designs. For example, it indicates what host the client prefers for clusters (that is, for virtual servers mapping to the same Internet protocol (IP) address).
Specifies whether a particular connection is to be kept open or closed after each request/response dialog. There are two valid values:
Keep-Alive(default) specifies that the client wants to keep its connection open after the initial request/response sequence. If the server honors it, the connection is kept open until the consumer closes it.
close specifies that the connection to the server is closed after each request/response sequence.
Specifies directives about the behavior that must be adhered to by caches involved in the chain comprising a request from a client to a server.
Specifies a static cookie to be sent with all requests.
Specifies information about the browser from which the request originates. In the HTTP specification from the World Wide Web consortium (W3C) this is also known as the user-agent. Some servers optimize based upon the client that is sending the request.
Specifies the URL of the resource that directed the consumer to make requests on a particular service. The value is used as the value of the HTTP Referer property.
This HTTP property is used when a request is the result of a browser user clicking on a hyperlink rather than typing a URL. This can allow the server to optimize processing based upon previous task flow, and to generate lists of back-links to resources for the purposes of logging, optimized caching, tracing of obsolete or mistyped links, and so on. However, it is typically not used in web services applications.
If the AutoRedirect attribute is set to true and the request is redirected, any value specified in the Refererattribute is overridden. The value of the HTTP Referer property will be set to the URL of the service who redirected the consumer's original request.
The HTTP Client parameters apply to all connections initiated by Examine to HTTP endpoints. The values customized by one user are only applicable to requests sent on behalf of that user and don't apply system-wide. Thus two different users may opt to use different set of values for the HTTP client connection without affecting other requests.
Examine allows for specifying the following proxy server parameters if outbound requests require a proxy configuration.
Specifies the URL of the proxy server through which requests are routed.
Specifies the port number of the proxy server through which requests are routed.
Specifies the type of proxy server used to route requests. Valid values are:
HTTP(default)
SOCKS
Table of Contents
The -> tab can be used to add, remove and update keystores that can be used for various security-based operations like WS-Security configuration for SOAP requests, SSL connection setup etc. Keystores are files that are used to store a set of keys and certificates. It usually contains two types of entries - Key entry, and , Certificate entry
The Key entry can in turn either be a Key Pair entry (i.e. a private and public asymmetric key pair, and optionally a chain of related certificates) or a secret key entry (symmetric key)
The following keystore file formats are supported -
JKS / JCEKS keystore format (.jks files)
PKCS#12 keystore format (.p12 files)
To manage keystores using Examine, you have to first upload it using the button in the Keystore Management tab. This will bring up the Import Keystore dialog as shown below. Note that since most keystores will be protected by a password, you should enter the keystore password to be able to create the keystore successfully.
Once the keystore as been uploaded successfully, the keystore contents will be displayed in a tree format as shown below:
The private key entries (such as 'client' and 'client2') are shown with the
key icon, while the public key entries that correspond to certificates are shown
with the certificate icon.
Clicking on the keystore name, displays the keystore details on the right side as shown below:
The following keystore operations are available from the details view:
Delete the currently selected keystore from the system.
For the delete operation to succeed, you have to
ensure that this keystore is not used or referenced by
any project. For e.g. if a keystore private key is used
as the signing alias in a WS-Security configuration of a
SOAP scenario, then trying to delete this keystore will
result in an error like this: Keystore
is used by other resources. Try removing any
associations to this keystore before deleting
it.
Rename the currently selected keystore. This option can be useful if for e.g. you are trying to upload another keystore that has the same name but different set of key entries
This option can be used to change the keystore password. Note that you are not prompted for the old password
This option can be used to import a new X.509 certificate into the selected keystore. This is useful if you would like to add a new certificate to an already existing keystore after it has been created. Note that you specify a certificate entry alias for the new certificate that does not conflict with any existing key aliases. Click on the Browse button in the Upload X.509 Certificate dialog to upload a new valid certificate into this keystore under the given alias name.
This option can be used to download the keystore file back to your system at a later point if needed.
Clicking on the private key tree item displays the key entry details as shown below.
The following operations are available for the selected private key:
Delete the current private key from this keystore.
Note that unlike deleting a referenced keystore, there is currently no check done when deleting a key and hence no error is thrown if the key is used elsewhere in some project.
This option can be used to export the selected private key and its related public key from the keystore either in PKCS#12 file format or in PEM (base64-encoded) format as shown in the Export Key Pair dialog
This option can be used to export the private key entry's associated public key as an X.509 certificate in either DER (Binary) format or PEM (base64-encoded) format.
The Certificate Entry Details view is displayed when a public-key entry is clicked on the Keystore tree view.
The following operations are available for Certificate entries:
Delete the currently selected public key entry from the keystore
This option is used to export the currently selected public key as an X.509 certificate in either DER (binary) or PEM (base64-encoded) format
The -> accordion tab view provides WS-Policy file management capability. Clicking on the Import button shows the Import WS-Policy as shown below which can be used to upload and manage WS-Policy files
This feature can be used to upload WS-SecurityPolicy files which can be used to create Policy-based Security Configurations that can be used to enforce WS-Security for SOAP requests and responses.
The WS Policies tab displays all the previously uploaded policies in a table and clicking on the policy name opens the detail view on the right as shown below:
The detail view provides a Tree and XML editor to view the contents of the WS-Policy file. The Tree view does not allow for manipulating the contents, but the XML editor can be used to update the policy. Clicking on saves the update policy contents to disk.
It is not possible to delete a policy file that is referenced by a Policy-based security configuration. Trying to delete a referenced policy will result in an error as shown below:
Examine allows for creating two types of global security configurations that can be used to apply WS-Security to SOAP requests -
| Non-policy security configuration |
| Policy-based security configuration |
This feature allows for applying existing configurations to SOAP scenarios instead of re-creating them for individual SOAP scenarios.
To create a new global security configuration click on ->-> to open the New Security Configuration dialog as shown below and specify a unique configuration name and click :
The list of all available security configurations in displayed in a tree view grouped under the respective configuration type node as shown below:
The Non-Policy security configuration requires a manual approach to configuring the outbound and inbound SOAP message security. There is no WS-SecurityPolicy involved in this configuration. The advantage of this approach is that it is possible to create request-only, response-only or request-response security configurations that can be applied to a SOAP scenario.
To enable WS-Security for the SOAP request sent to the WS endpoint, click on the checkbox in the selected non-policy configuration. The following types of security actions can be added for the outbound request:
The timestamp assertion can be used to add a <wsu:Timestamp/> element to the SOAP request header. Select the ‘Use Milli Seconds Precision’ checkbox to use milli-second level precision for the ‘Created’ and ‘Expires’ element value.
This assertion is used to add a WS-Security Username Token as specified in Username Token Profile 1.1
Specifies the value of the username element
Specifies the value of the password element
Specifies the value of the attribute ‘Type’ for the
password element. The value can be ‘Text’, ‘Digest’ or
‘None’. If ‘Text’ or ‘Digest’ is chosen, the Type
attribute value will be generated as either
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
or
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest
If ‘None’ is chosen, then no password element will be
sent in the UsernameToken element even if a password
value is specified.
If the and checkboxes are enabled, then the
<wsse:Nonce/> and <wsse:Created/>
elements will also be added to the UsernameToken element.
This assertion can be used to sign elements of a SOAP request and add a signature to the WS-Security SOAP header.
To be able to sign parts of the SOAP message, a valid keystore,
which contains a private key must have been already configured. Without
selecting a private key alias, it is not possible to sign the outbound
message. So the first step is to click on the
button to bring up the keystore alias
dialog.
This dialog will list all keystores currently uploaded by the
current user.
You have to click on the private key alias to enable the button which will remain disabled until done so.
After a private key alias is selected, it is displayed next to the button
The and checkboxes are convenient options to quickly enable signing either the SOAP Body element, Timestamp element (if the Timestamp assertion was also configured) or both.
If however, you would like to sign another part of the SOAP message, like a particular XML element within the SOAP Body, then click on the button. This will add a new row in the parts table as shown below. Here you can specify the XML element ID or the element name and its namespace. You can also specify whether the element itself or its content should be signed using the Mode combo box.
Unlike adding a part for the Signature / Encryption action when creating a SOAP scenario specific security configuration, there is no dialog shown to select the XML element. This is because when creating a global security configuration, there is no SOAP scenario / request XML available. So you have to specify the element details manually.
To delete a previously added part, select the checkbox on the appropriate row and click on Delete
Sometimes the default signature options used may not be appropriate for the service being invoked. In this case, the advanced configuration link can be clicked to reveal fields that can be used to specify the Key Identifier or Signature Algorithm or Digest Algorithm to use during the process of signing the request contents.
For e.g. the default signature algorithm is
http://www.w3.org/2000/09/xmldsig#dsa-sha1 which may
not be appropriate if you are using a private key that is RSA-based.
Check to make sure that the service provider specified signature
requirements are followed to ensure that signature verification succeeds
at the provider side.
This assertion can be used to encrypt parts of the SOAP message before it is sent to the service provider. The encrypted references are added in the generated WS-Security header.
In Public-Key cryptography, to encrypt something, you would need the public key of the recipient, since only the holder of the corresponding private key can decrypt the encrypted message. This means that a truststore that contains the recipient’s public key must have been configured prior to configuring this assertion. The figure below shows the available configuration options for this assertion:
The first step is to select the certificate that holds the
public key used to encrypt the desired parts of the SOAP request
message. Click on to open a dialog to
select the certificate alias from the list of available keystores as
shown below:
The and checkboxes provide convenient options to
specify that the <wsu:Timestamp/> element (if the
Timestamp assertion is configured as well) and the contents of the SOAP
Body element must be encrypted.
To specify any other SOAP Envelope content, you have to click on the button to add a new row in the parts table as shown below:
Either the Element ID or a combination of the Element Name and Namespace must be specified to correctly select the element to be encrypted.
The Mode element specifies whether the selected element itself or the contents of the element must be encrypted.
Do not add the SOAP Body element as a part to be encrypted with the Mode value set to Element. This can cause the Body element itself to be encrypted resulting in an invalid SOAP message!
The advanced configuration section allows for configuring the Key Identifier, Encryption Algorithm or the Key Transport Algorithm to use when encrypting the selected SOAP request elements.
These advanced configuration values will need to be selected depending on what the service provider expects
This assertion allows for adding a previously obtained / created SAML assertion in the outbound request SOAP WS-Security header.
The Edit button can be used to open the Add Assertion dialog which contains a text field to capture the SAML Assertion element to be added to the request.
The value specified in the dialog must be a syntactically valid XML SAML 1.x or 2.0 Assertion element. The specified Assertion will be added as is to the WS-Security header in the outbound WS request.
This action assumes that you have a way to obtain or create a valid SAML Assertion. Please see the Tools section to see how to generate a valid SAML 2 Assertion manually. It is also possible to use the built-in STS to obtain a valid SAML token and add the Assertion element present in the token (refer to the STS Usage section)
The Clear button can be used to remove any previously added assertion contents.
The Binary Security Token (BST) action allows for adding a X.509
Token to the WS-Security header of the outbound request as a
<wsse:BinarySecurityToken/> element.
Sometimes it is required to send a X.509 certificate as a BST to the service provider to identify the client. Note that by itself this assertion really does not provide any security as the BST contains the public key of the client in Base64 encoding which is usually publicly known.
To specify the X.509 certificate to be used, click on the link button to open the Keystore Alias selection dialog. Note that this dialog will allow you to select a private key alias only. The public key corresponding to the selected private key will be used to retrieve the certificate to be sent to the service.
The Use Single Certificate option decides whether just a single certificate or the entire certificate chain of the selected certificate will be sent to the service.
A current limitation when using this assertion is that it cannot be used by itself. If this assertion is added, another security assertion must be used along with it (like Timestamp Assertion). Below is a sample request that uses both the Timestamp and Binary Security tokens.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<wsse:Security
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"
SOAP-ENV:mustUnderstand="1">
<wsse:BinarySecurityToken
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="X509-B74EEF2C264E73ABB813137954338364"
>MIICNjCCAZ8CBEo1POgwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCSU4xCzAJBgNVBAgTAk1QMQ8wDQYDVQQHEwZJTkRPUkUxDz
ANBgNVBAoTBkFwYWNoZTEMMAoGA1UECxMDRGV2MRYwFAYDVQQDEw1NYXlhbmsgTWlzaHJhMB4XDTA5MDYxNDE4MDk0NFoXDTE5MDYxMjE4MDk0NFowYjEL
MAkGA1UEBhMCSU4xCzAJBgNVBAgTAk1QMQ8wDQYDVQQHEwZJTkRPUkUxDzANBgNVBAoTBkFwYWNoZTEMMAoGA1UECxMDRGV2MRYwFAYDVQQDEw1NYXlhb
msgTWlzaHJhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCdPhcimx7/CFX4H8isKEKCbRK6Kr+qeCMCby9I/Q/NY1bNqy6nsD+Y5BxSc2yCUnyLsR
dmAHIxUwRQ9X5s8FP9+T1nwuoPzBvjcoZqWgDhe9RvydkijuzsFan/PY4oemd5EIoQu80ZpcFqb00xyDY3DkPgymXNsZ2uAM1ccsx90QIDAQABMA0GCSq
GSIb3DQEBBAUAA4GBAGXIE7pFNInlyjHnq89zgvHJfZNE44El6Cd5V55JvL+LZUnynU2Y8WaUwD2Qvc1QTr9R7u6nhZ8abyB7TSx3idiN6KUSNtBHOeWU
TmfGbAJqO/J6R2A9J20KCvss28D05rRI3z52VQHnMBzgirL6M5ClWBZfl2Q3bNKnOImjoNhK</wsse:BinarySecurityToken>
<wsu:Timestamp wsu:Id="TS-2">
<wsu:Created>…</wsu:Created>
<wsu:Expires>…</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<x1:sayHi xmlns:x1="http://cxf.apache.org/hello_world_soap_http/types"/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
To enable WS-Security processing for the SOAP response select the checkbox as shown below:
The following response processing actions are available when response security is enabled:
If this option is enabled, then the
<wsu:Timestamp/> element if present in
the WS-Security header of the SOAP response is verified for
correctness (i.e. not expired)
When this option is enabled, Examine verifies the response signature. Note that a valid truststore that contains the public key of the web service must be configured to be able to verify the signature.
When this option is enabled, Examine decrypts the elements which were encrypted by the service in the response it sends back. Note that for the decryption to succeed, a keystore that contains the private key corresponding to the public key used by the service to encrypt must be configured.
It is also possible to create a global WS-SecurityPolicy based Security Configuration that can be reused across multiple SOAP scenarios. This type of security configuration is a combination of a WS-SecurityPolicy and the required configuration data. The security policy must have been previously uploaded as detailed here. The figure below shows the configuration screen for a policy-based security configuration:
Specify a unique name for the security configuration and select the Policy file to use for this configuration. Click on to reload the available policies.
The policy file by itself usually does not contain the required configuration data (like keystore or truststore to use, or the username / password to send). To satisfy the policy requirements, the runtime policy parameters must be specified. Following are the list of available configuration parameters that can be specified:
Specify the value in seconds that will be used for the
<wsu:Timestamp/> element. It will
default to 300s or 5 minutes by default if
unspecified
Specify the username and password to be sent as part of
the <wsse:UsernameToken/> element. Note that
whether the password is sent in plain text or digest form is
usually specified in the policy
Click on to choose the private key alias that will be used to sign the request elements. Note that atleast one keystore must have been uploaded earlier to be able to choose a private key alias from it. Refer to the Security Configuration guide for information on how to manage keystores.
Click on to choose a public key alias that will be used to encrypt the request elements. Note that atleast one keystore that contains an X.509 certificate must have been uploaded earlier to be able to choose a public key alias from it. Refer to the Security Configuration guide for information on how to manage keystores.
By default, Examine does not verify if the response from the Web Service conforms to the selected WS-SecurityPolicy. To enable checking if the response is valid according to the policy, the checkbox should be enabled. Note that it is only possible to verify the timestamp semantics, the response signature and/or decrypt the response contents using this option.
Table of Contents
Examine allows users to create two types of projects – SOAP and REST. The tab provides the centralized location for managing all the projects created by the user.
The Projects tab displays all the user-created projects in a tabular form. To search for a specific project or list of projects, click on the Search tree item on the left of the projects list
This will bring up the search dialog as shown below:
The search term corresponds to the pattern to search. The Field to search drop-down component displays the available project-related fields against which the search can be done. You can also save this search by enabling the Save search checkbox and providing a search name. Saved searches appear as tree elements on the left. Clicking on Show All clears any search filters applied to the projects table and displays all the available user projects.
To create a new project, click on the New Project link to bring up the new project dialog
A SOAP project represents a WSDL-based project that contains a collection of SOAP scenarios. A SOAP scenario represents a single WSDL service operation for which a SOAP-based service invocation will be done. A SOAP project can be created from a local / remote WSDL file. This can be specified by selecting the appropriate value for the WSDL source radio box in the SOAP project creation dialog as shown below: Uploading a file automatically results in a project name getting suggested.
To use a local WSDL file you have to upload a WSDL document from your local file system. The SOAP project creation dialog after uploading a WSDL file is shown below:
The checkbox when enabled causes Examine to create a SOAP scenario for each WSDL operation in the SOAP binding present in the SOAP service. If this option is not enabled, then no scenarios are created for any operation and a new scenario can be created later by using the menu option when right clicking on the WSDL operation after the project is created
If the WSDL document references other WSDL
documents through wsdl:import or other schemas through the
xs:import or xs:include elements, then to create a
SOAP project from such a WSDL document, a zip file containing the parent WSDL file
and all the referenced documents can be uploaded as a single file to create a
project.
Consider an example WSDL file called SimpleStockQuoteService.wsdl
that references another WSDL file which in turn references three schema documents.

The above set of files can be uploaded as a single ZIP file as shown below:
When this zip file is uploaded, a dialog displaying the ZIP file contents is displayed in a dialog to allow you to select the root WSDL file from which the SOAP project must be created as shown below:
Note that only WSDL files are displayed by default to help select the WSDL
file.
To use a remote WSDL file choose the ‘URL’ option for WSDL source and enter the URL of the remote WSDL document.
The ‘Auth’ tab allows for specifying the HTTP Basic Authentication credentials when retrieving the WSDL file:
If the WSDL file is accessible over HTTPS, the SSL tab can be used to configure the required Server and Client SSL Authentication settings. The checkbox must be checked to enable SSL configuration. The KeyStore and TrustStorecombo boxes lists all the previously configured keystores. Both the fields are optional. The KeyStore value is only required if the server requires SSL client authentication.
The TrustStore value is required if you would like Examine to verify the server certificate when performing a SSL handshake with the server. If a truststore is not configured, Examine will accept any server provided certificate
You can leave the TrustStore value unconfigured for Web Services under development or when using self-signed certificates for the SSL endpoint
The checkbox when enabled causes Examine to verify the hostname value in the certificate provided by the server during SSL handshake
After a SOAP project is created, a SOAP scenario can be created for the operations listed for each binding. To do this, right click on the displayed service operations and select Create Scenario as shown below:
This will bring up the New SOAP scenario dialog that can be used to specify a scenario name and the transport protocol to use – either HTTP or JMS, defaulted to HTTP.
Each SOAP scenario groups the operation request, response, test case
and security configuration together.
Once the soap scenario is created, the request information can be updated through three different viewers (Tree, XML and Raw) in the Request tab. By default, the request XML is displayed in the XML viewer, which displays the request contents in, formatted, pretty-printed form
The XML viewer provides a text-editor field with syntax highlighting of the XML content. Note that the XML viewer can detect invalid XML such as unclosed tags and the incorrect elements will be highlighted accordingly.
The raw text viewer provides a text-editor field to edit the XML contents. This viewer is useful when you would like to send raw unformatted contents to the web service. This view does not display any highlighted or pretty-printed text.
The Tree viewer is the most feature-rich of the three XML viewers and it provides for the following operations on the displayed XML. The XML is displayed in a tree form and right clicking on the different tree nodes displays a context menu that allows for different operations on the node depending on the type of node that was the target. For e.g. the tree nodes are distinguished as DOM Element, Attribute, Comment and Text. Actions applicable on one node may not be applicable for another. For e.g. the ‘Add attribute’ action only works on a node that represents an XML element
The elements and attributes in the XML tree view provide context-sensitive actions to manipulate the XML content.
In the above picture, right-clicking on the ‘symbol’ element displays the menu with the following enabled actions:
Add a new DOM element with the given name and namespace as a child of the ‘symbol’ element
Add a new DOM attribute with the given name and value as an attribute of the ‘symbol’ element
Delete the selected element (symbol element in this case)
Add a text element to the selected 'symbol' element
This action retrieves the XPath expression corresponding to the selected DOM element in the tree
This is a special action that is useful when sending SOAP attachments with MTOM support. For more details see the ‘##############Sending Attachments…’ section.
All the three views synchronize with each other when switching from viewer to another. So if there is an invalid XML in the XML/Raw view, then the tree view cannot display the updated XML and will instead show an error message and display the old XML.
Each SOAP scenario contains a SOAP request that will be sent to one specific endpoint. The available endpoints are populated above the XML viewer tabs as a dropdown list. The list of endpoints is based on the WSDL 1.1 Service/Port/address element values.

You can add new request endpoints, edit existing endpoints or remove the
listed endpoints using the endpoint action buttons: 
Clicking on the Execute button (
) will send the request to the selected endpoint using
the currently selected scenario configuration values.
Each SOAP Scenario can be configured with Message-level (WS-Security) security settings that apply to the SOAP request that is part of the SOAP Scenario by clicking on the ‘Security’ tab. Examine allows specifying the WS-Security configuration using a WS-SecurityPolicy or through a non-policy configuration that involves specifying the different security assertions manually. There are three possible WS-Security Configuration types available for each SOAP scenario:
No Security
Non-Policy Security configuration
WS-SecurityPolicy-based Security Configuration
This is the default WS-Security configuration type for every SOAP scenario. When this option is selected, no WS-Security header will be sent in the outbound SOAP request and no WS-Security processing of the SOAP response will be done.
This option allows for configuring the WS-Security settings for the SOAP scenario using a manual approach. This is helpful when there is no WS-SecurityPolicy available to describe the security requirements for the WS endpoint under test. When using a non-policy security configuration, it is possible to either specify a custom in/out security configuration or re-use an existing global security configuration created earlier.
This is the default option for non-policy WS-Security configuration. It allows for manually setting the outbound (request) and inbound (response) security settings for the SOAP scenario request.
This action is the same as the global non-policy Timestamp configuration. Please refer to this section for more information.
This action is the same as the global non-policy UsernameToken configuration. Please refer to this section for more information.
This action is same as the global non-policy Signature configuration except how the SOAP part is selected. Please refer to this section for more information.
Unlike adding a part in the global Signature configuration section, clicking on the button brings up the Select Element Part selection dialog as shown below.
This dialog displays the current SOAP request contents in a tree form. You can either click on a specific element that should be signed or enter the value of the ID attribute (which should be unique within the document) in the Element ID text field. The Mode combo box value determines whether the ‘content’ of the selected element or the ‘element’ itself will be signed. After choosing the part to sign, click on the button to add the part in the parts table to be signed when the request is sent out.

To delete a previously added part, select the checkbox on the appropriate row and click on Delete
This action is the same as configuring the global non-policy Encryption action except how the SOAP part is selected. Please refer to this section for more information.
Unlike adding a part in the global non-policy Encryption action, clicking on the button opens the parts selection dialog similar to the Signature Assertion parts selection dialog box.
The screenshot below shows how a specific XML element within the SOAP Body can be selected to be encrypted. A unique element ID can also be entered as an alternative to selecting an element.
The qualified name (QName) of the selected element is displayed in the ‘Selected Element’ field. You can also specify the ‘Element ID’ of the element that should be encrypted. Note that the element ID is a unique value within the XML document.
The Mode element again specifies whether the selected element or the content of the element must be encrypted.
After the element to be encrypted is added, it is displayed in the parts table as shown below.

This action is the same as configuring the global non-policy SAML action. Please refer to this section for more information.
This action is the same as configuring the global non-policy Binary Security Token action. Please refer to this section for more information.
Configuring Inbound (SOAP response) security is similar to the global non-policy inbound security configuration. Please refer to this section for more information.
If you have already created a global non-policy security configuration as described here, then it can be re-used for enforcing WS-Security for the SOAP request and response in this SOAP scenario. To re-use an existing security configuration, select radio box and select from the list of security configurations shown in the drop-down box.
Click on button to reload the available list of security configurations
Examine also allows for using a WS-SecurityPolicy to apply security to the outbound SOAP request contents. This can be done by either specifying a shared global security policy configuration, a local policy-based configuration or by using the policy present in the WSDL document used to create the SOAP project and scenario.
This option allows for reusing previously created global policy-based security configurations as described here. The selected configuration is a combination of a security policy and the related configuration information. Click on button to reload the available set of configurations.
This option allows for using a WS-SecurityPolicy previously uploaded using the accordion tab as the source of the security requirement for the outbound client request. This option differs from the Global Policy-based configuration in that the configuration values must be specified manually and only the WS-SecurityPolicy is reused, while in the global configuration, both the policy and the values are reused.
The Policy drop-down component displays all the available WS-Security Policy files currently available for use. The button can be used to reload the available policy files. The button allows for saving this local security configuration as a shared global configuration that can be reused in other SOAP scenarios without having to re-select the policy and configuration values to use.
It is also possible to use the WS-SecurityPolicy already present in the WSDL document used to create the SOAP scenario. This option is useful when the WSDL obtained from a service provider already specifies the policy that the client should use when interacting with the service
The effective policy is computed at runtime before the request is sent to the service provider. The final request effective policy is a merge of the policies on the following policy subjects:
Service policy
Endpoint policy
Operation policy
Input Message policy
If there are no policies that are referenced (or specified) by the policy subjects, the effective policy cannot be computed. To view the computed effective policy click on the link. The screenshot below displays the final policy for a sample WSDL service port:
The security policy usually does not specify the required data such as the time stamp value, username or keystores to use for signing or encryption to satisfy the policy requirements. When using either a WSDL-based WS-SecurityPolicy or a local policy file, the required configuration values must be specified for Examine to create the correct security header.
The ‘Time-To-Live’, ‘Username Token’, ‘Signature’ and ‘Encryption’ options allow for specifying the required configuration values as required by the WS-SecurityPolicy chosen.
For the Signature value, a private key alias must be selected in the keystore dialog box shown when clicking on ‘Select’.
For the Encryption value, a public key alias must be selected in the keystore dialog shown when clicking on ‘Select’.
The ‘Remove’ button can be used to clear any previous selection.
Specifying the configuration values does not imply that, that particular action would be applied automatically. The actions taken at runtime depend on the policy assertions present in the chosen policy. For e.g. specifying Username Token values does not imply that the request would contain a UsernameToken header. The policy determines if a UsernameToken header would be added to the WS-Security header in the SOAP request.
By default, Examine does not verify if the response from the service under test conforms to the selected WS-SecurityPolicy. To enable checking if the response is valid according to the policy, the checkbox should be enabled
Every SOAP scenario also contains a TestCase as part of it. A TestCase can be added to a TestSuite to be grouped with TestCase’s from other SOAP Scenarios. TestSuite’s allow for execution of multiple TestCase’s from different SOAP scenarios together. To learn more about how to use TestSuite’s please refer to the chapter on TestSuite configuration
Click on the ‘’ button to open the ‘Available SOAP Test Suites’ dialog as shown below. Any previously created test suites are displayed in the drop-down box.
To add the test case to a new suite, click on the ‘Create New TestSuite’ and specify a unique test suite name. The test case of this soap scenario is added to the newly created test suite.
Each test case is a collection of test assertions. Examine provides the following built-in assertions that can be added to a test case for evaluation on the SOAP response.
This assertion verifies that the HTTP response code is a particular code such as 200 (OK) or 401 (Unauthorized)

This assertion can be used to check if a particular HTTP header is present, absent or is equal to a certain value.

This assertion can be used to verify if the HTTP response was either less than or greater than a certain threshold value specified in milliseconds.

This assertion can be used to check for the presence of a particular token in the HTTP response. If the ‘Regular Expression’ checkbox is checked, then the specified text is used a regex pattern against the SOAP response body. The regex pattern should follow the Java regular expression rules.

For more information on how to use Regular Expressions, please refer to this page: http://download.oracle.com/javase/tutorial/essential/regex/
This assertion can be used to check if an XPath expression evaluates properly against the SOAP response Envelope. Click on the ‘Configure’ button to open the XPath Expression dialog box where you can enter the XPath expression to use and declare the namespace URIs for any prefixes used in the expression.

Each namespace declaration should be entered on a new line and
is of the form:prefix = URI

The result of evaluating the XPath expression will be a Boolean true/false. If the xpath expression results in DOM Nodes, then the result is True and if no there are matching nodes, the result is false. If the expression contains a predicate clause, then the result is either true/ false as well.

This assertion can be used to evaluate an XQuery expression against the SOAP response envelope contents. Click on the ‘Configure’ button to bring up the XQuery Expression dialog where you can enter the XQuery contents that will be run against the SOAP envelope, and the expected result of the execution. The result of the xquery run will be compared against the specified expected result value after removing any whitespace characters that are present in both of them (for e.g the comparison is will be done after stripping out any new line, tabs and other whitespace characters)


This assertion can be used to perform XML Schema validation of the SOAP response body contents. Click on the button to open the XML Schema configuration dialog as shown below.

Click on the button to upload a single XML schema file. If the schema has other references (includes / imports) then a zip file containing the main schema file and the schema references as local relative paths can be uploaded as well.
When a zip file containing the schemas is uploaded, Examine will prompt you to choose the main schema file. The main schema file is the one that contains relative references to other schema files. For e.g. consider the following XSD and its references:
catalog.xsd - with two <xs:include/> references to pricing.xsd and sequence.xsd
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="pricing.xsd"/>
<xsd:include schemaLocation="sequence.xsd"/>
...
</xsd:schema>The above schemas can be uploaded as a single zip file (catalog.zip). This results in the following dialog that prompts you to select the root schema file (catalog.xsd):

The schemaLocation attribute value for all schema references (import / include elements) must be relative paths to the importing schema. This ensures that Examine is able to resolve all referneces to load the schema model correctly
Each SOAP scenario can either be based on either the HTTP or JMS transport protocol. For HTTP, the following can be configured for each SOAP request:
| HTTP Headers |
| Authentication |
| SSL configuration |
To configure the outbound HTTP headers, click on the HTTP link at the bottom of the request XML editor to bring up the ‘Request Configuration’ section and select the ‘Headers’ tab as shown below:
To add / remove header names and their values click on the ‘Add’ or ‘Delete’ button. (For delete, you need to select the headers to be deleted by selecting the appropriate checkbox next to each row)
To setup the outbound HTTP authentication information (Authorization HTTP header), select the ‘Authentication’ tab under the ‘HTTP’ tab.
Click on the ‘Enable HTTP Auth’ checkbox to enable the username, password and related fields.
The ‘Do Preemptive Authentication’ checkbox if enabled results in the Authorization header being sent to the service even before the service challenges for the credentials.
The Authentication Type field can be either Basic or Digest and it results in the use of either HTTP Basic Authentication or HTTP Digest Authentication as outlined in the RFC 2617 (http://www.ietf.org/rfc/rfc2617.txt)
If the service endpoint is accessible over HTTPS, then it is possible to specify the keystore and / or truststore to use for SSL key negotiation. To do this select the ‘SSL’ tab under the ‘HTTP’ tab as shown below.
Click on the ‘Enable SSL’ checkbox to enable specifying a keystore and/or truststore to use.
The KeyStore and TrustStore drop-down boxes display all the available keystores in the system for the currently logged in user.
If SSL Client Authentication must be performed, then select the keystore that contains the private key whose equivalent public key is known to the service provider. To disable SSL Client Authentication, leave the KeyStore field empty.
To specify a custom truststore that contains the service provider’s X.509 certificate, select a truststore from the available stores. This truststore must contain the server certificate imported as a public key in it.
The ‘Verify Hostname’ field determines if the hostname specified in the X.509 certificate obtained during SSL handshake will be compared against the hostname of the endpoint to which the request is sent.
The ‘Refresh keystores’ button reloads all the available keystores and truststores.
If the SOAP Scenario is based on the Java Message Service (JMS) protocol, then the connection information must be specified correctly inorder for the request to succeed.
To configure the JMS server and destination type (Queues / Topics) to use, click on the JMS link below the Request editor to bring up the JMS tab. This tab in turn contains the ‘Connection’, ‘QoS Parameters’ and ‘Properties’ tabs
The Connection tab as shown in the screenshot below is used to specify the JMS server connection information:
Examine comes bundled with the Apache ActiveMQ libraries by default. If
the JMS server being used is also ActiveMQ, then selecting the
checkbox automatically populates
the Connection Factory Name to
ConnectionFactory and the Initial Context Factory
Name to
org.apache.activemq.jndi.ActiveMQInitialContextFactory.
The initial context factory name is the fully-qualified class name of the
class implementing javax.naming.spi.InitialContextFactory. When
using ActiveMQ, the value is defaulted to
org.apache.activemq.jndi.ActiveMQInitialContextFactory.
If you would like to use a different JMS provider, then the client library for the provider must be copied under WEB-INF/lib folder of the Examine web application. You must also enter the correct values for the Connection Factory and Initial Context Factory names in the JMS configuration screen. Please refer to the provider documentation for these values
The Provider URL is of the form: tcp://server:port
where tcp is the protocol to use, server is the host name of the JMS server
and port is the port that the JMS server is listening on for incoming
connections.
The Destination name specifies the name of the Queue or Topic to which the message must be sent.
The Type value specifies the destination type – either Queue or Topic
The ReplyTo value specifies the destination name to which the server should send the response. If it is not specified, an anonymous destination name will be used.
If the JMS provider requires any authentication, then enter the username and password to use under the Credentials section.
The QoS Parameters tab is used to specify the Quality-of-Server parameters for the outbound JMS request
The Time-To-Live field captures the value in milli-seconds of the JMSExpiration header. This is the duration for which the message produced by the producer is valid after which it won’t be delivered to any consumer. Default value = 0 which means the message does not expire.
The ‘Send as bytes message’ field if selected will cause the message to sent as JMS BytesMessage in which the payload sent as an array of bytes which is not transparent to the client. If not selected, the SOAP request payload is sent as plain text string. Default value is false which means the message is send as plain text.
The Priority slider controls the value of the message priority and can take a value between 0 and 9. It is set as the value of the JMSPriority header. Default value = 0.
The Delivery mode controls the value of the JMSDeliveryMode header and can be either Persistent or Non-Persistent. Persistent means that the message will be delivered until it is received by the consumer but only once and Non-Persistent means the message won’t be redelivered if the initial delivery attempt fails. Default value = Persistent.
The Receive Timeout value is the time to wait to a response from the provider. Default value = 1000 ms or 1s.
JMS allows for adding custom application-specific properties as JMS Properties. The Properties tab can be used to add name-value pairs that will be sent as JMS Properties in the JMS message.
To enable WS-Addressing support for SOAP requests click on the ‘WS-Addressing’ link shown below the request XML view. This will bring up the WS-Addressing tab in the ‘Request Configuration’ view.
By default, the ‘Enable WS-Addressing’ checkbox is disabled to prevent WSA headers from being added to the outbound request. To send WSA headers, enable the checkbox.
The To field corresponds to the /wsa:To element which is an optional
element. If this value is not specified, it is defaulted to
http://www.w3.org/2005/08/addressing/anonymous
To Action field corresponds to the /wsa:Action element, which is a required element. Either a valid value must be specified or the checkbox must be selected to use the default SOAPAction value.
The Message ID field corresponds to the optional
/wsa:MessageID element. This must contain an unique value
for each request. Selecting the
checkbox results in a random message id for each request.
The From, ReplyTo and FaultTo EPR (Endpoint Reference) fields correspond
to the source, reply and fault endpoint properties of WSA, which are all of
/wsa:EndpointReferenceType type. Each EPR consists of a
single destination address and a collection of parameters or
metadata.
Each EPR takes the XML form:
<wsa:EndpointReference>
<wsa:Address>xs:anyURI</wsa:Address>
<wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?
<wsa:Metadata>xs:any*</wsa:Metadata>?
</wsa:EndpointReference>
A reference may contain a number of individual parameters that are associated with the endpoint to facilitate a particular interaction. Reference parameters are namespace-qualified element information items that are required to properly interact with the endpoint. Reference parameters are provided by the issuer of the endpoint reference and are assumed to be opaque to other users of an endpoint reference.
A reference may contain metadata that describes the behavior, policies and capabilities of the endpoint. Metadata may be included in an endpoint reference to facilitate easier processing by a user of an endpoint reference, or because the metadata was dynamically generated
Please refer to the Endpoint Reference Information Model description for more information (http://www.w3.org/TR/ws-addr-core/#eprinfomodel)
Since the Reference Parameters and Metadata content model is of type xs:any, it can contain any valid XML element. So specify a Reference Parameter or Metadata, click on the equivalent Reference Parameters or Metadata link next to the EPR to which it should be added and specify a valid XML content that should be added to the EPR element
The figure below shows a sample Metadata information added to the ‘From’ EPR WSA header:

For the three EPRs (from, replyTo or faultTo), if either the address,
reference parameters or metadata is specified, the equivalent WSA
EndpointReferenceType element (wsa:From / wsa:ReplyTo /
wsa:FaultTo ) will be added to the outbound SOAP request header.
For e.g. the sample request below shows the WSA headers added when the ‘from’ address is not specified, but a valid Reference Parameters and Metadata values are specified.
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/”>
<Action xmlns="http://www.w3.org/2005/08/addressing">http://apache.org/hello_world_soap_http/Greeter/greetMeRequest
</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:04feb301-7e50-4716-b745-57987cd63cfd</MessageID>
<To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
<From xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://xyz.com</Address>
<ReferenceParameters>
<MyRefParam xmlns="" xmlns:ns2="http://www.w3.org/2005/08/addressing">1234</MyRefParam>
</ReferenceParameters>
<Metadata>
<ns:name xmlns:ns="http://xyz">test</ns:name>
</Metadata>
</From>
</SOAP-ENV:Header>
Examine has support for sending attachments as part of the SOAP request to the WS endpoint. There are three ways to send binary content as part of a SOAP message:
This approach involves converting the binary content of the file to be sent in base64-encoded form and embedding the text as part of the SOAP message. This is the least efficient way of sending binary data as it involves base64-encoding the content that typically bloats the size of the input data by 33%.
This approach involves sending the binary attachments in their native format in a multipart MIME structure. This is similar to how email messages are sent with attachments. There is a separate MIME part added to the message that contains the binary content in its native content type format. This is more efficient than the previous approach in that there is no base64-encoding of the binary content involved.
E.g. consider a WS that receives a SOAP message and expects a binary attachment using the SwA approach. Below is the request XML as configured in Examine:

The request XML takes the target destination where the file will be saved
by the service (/ns:name) and the id of the attachment being
sent to the service (/ns:attachmentID)
Below is the attachment configured in the Attachments tab under Request Configuration:
Note that the checkbox is NOT enabled
as we are using SwA. The CONTENT ID column in the table
specifies the attachment id. This will be the value of the
Content-ID header in the MIME part corresponding to the
file attachment in the HTTP request.
The response XML for the above request sent with attachment is shown below:

Refer to the SwA specification for more information: http://www.w3.org/TR/SOAP-attachments
This approach is similar to the SwA approach in that the attachment is sent as a separate MIME part in the request message, but differs in the way the MIME part is referenced by the root part (SOAP message). SwA has a fundamental flaw in that the binary attachment is not part of the SOAP message and the receiving service must know how to reference the correct attachment in the request message. This usually involves specifying the attachment id as part of the message and the service must know in advance which element / attribute specifies the attachment id.
MTOM solves this problem by using the mechanism proposed by XML-binary
Optimized Packaging or XOP (http://www.w3.org/TR/xop10/). XOP allows for separating the
binary data from the XML message through the use of a special XML element
called <xop:Include/> that references the attachment via a
content identifier value. Thus the XML processor knows how access the
specified reference and replace the contents of the element (with the
<xop:Include/> with the attachment contents)
Refer to the SOAP-MTOM specification for more information: http://www.w3.org/TR/soap12-mtom/
Consider a WS that accepts a binary attachment with the following SOAP request content:
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header/>
<env:Body>
<tns:AttachmentRequest xmlns:tns="http://ws.apache.org/axis2/mtomsample/">
<tns:fileName>string value</tns:fileName>
<tns:binaryData xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmime:contentType="">dGVzdA==</tns:binaryData>
</tns:AttachmentRequest>
</env:Body>
</env:Envelope>
The service expects a destination file name (tns:fileName)
and the binary content to be transferred (tns:binaryData). The
tns:binaryData element expects a base64-encoded binary
content. But since we are using MTOM, the tns:binaryData
element can specify a <xop:Include/> element with a
reference to the attached MIME part.
Examine provides a convenient way to add the XOP Include element through
the XML Tree view. To do this, right click on the element that should
contain the <xop:Include/> element as shown below:
The XOP specification expects the <xop:Include/>
element to be the only child of the element of type
xs:base64Binary (http://www.w3.org/TR/xop10/#xop_include). So it is
recommended to use the Raw XML view to send the request instead of
the Tree / Formatted XML Views as they send the request with
whitespace characters present in the message
The button then prompts you to
specify the value of the href attribute of the
<xop:Include/> element as shown below:

The Content ID value must not include the "cid:" prefix, as this will be added automatically to the specified value
Below is the attachment configured in the Attachments tab under Request Configuration

The checkbox must be enabled to use MTOM
Examine provides a simple but very effective REST testing support that can be used to test REST-based Web Services. The starting point for REST-testing is the REST project. A REST project is a collection of Resources where each resource represents a single HTTP endpoint accessible that can be invoked over a HTTP method like GET, POST, DELETE, PUT, etc. Each Resource can in turn contain sub-resources and acts as the parent of the sub-resource. The sub-resource itself is a valid REST Resource and the same rules that apply to resources also apply to sub-resources.
Consider the example of a REST-based sample Stock Quote Service that is available
at the endpoint: http://localhost:9998/stockquote. We'll use this as
the example to describe and demonstrate how to use the REST functionality going
forward.
To begin, create a new REST project from the Projects screen. Click on the link button to bring up the Create New Project dialog and select the option. Clicking on button brings up the REST resource creation dialog as shown below:
Specify a unique project name (e.g. SimpleStockQuote) and click on
to create the project. If the Add new
REST resource... checkbox is selected, then you can also create a
REST resource immediately following the REST project creation. This brings up
the Create new REST Resource dialog as shown below:
In the displayed dialog, specify the values of the following fields:
The name of the REST resource - this can be any logical name that represents this resource endpoint. This is a required field.
This field represents the base URL of the resource. For e.g.
value can be http://localhost:9998 that specifies
the protocol (HTTP/HTTPS), the server name (localhost) and the
port number (9998). The base URL will be common to all
sub-resources that are created as child resources of this
resource. This is also a required field.
This field represents the actual context path of the resource.
For e.g. in the dialog below, it is set to
/stockquote and the final resource URL will be
http://localhost:9998/stockquote, which is a
combination of the Base URL and the specified Resource URI.
It is also correct to specify the base URL itself as
http://localhost:9998/stockquote and
leave the Resource URI as /. In this case
also the resource endpoint would be the same. However,
subresources of this resource would inherit the complete
Base URL with the 'stockquote' path segment
This field represents the available HTTP methods that can be used to invoke this resource URL. The available methods are GET, POST, PUT, DELETE, OPTIONS, HEAD. It defaults to GET.
Once the REST project is created, clicking on the project name, displays the
project details like Created and Modified date. REST resources which are created
as direct children of the REST project are called 'root' resources. These
resources are represented by the
icon.
Root resources represent the top-level resource endpoints that can in turn contain many sub-resources under them. Each root resource contains a Base URL that captures the protocol, host and port information of the REST endpoint. To create a new root resource as a child of the REST project, right click on the REST project name and select as shown below:

This brings up the same Root Resource dialog to specify the resource details as shown in this figure . Clicking on the root resource node in the tree view displays the resource details like this:
The details view contains Main, Request and Test tabs that can be used to configure the current root resource. The response tab displays the result of invoking the resource endpoint.
The Main tab contains the following resource configuration fields:
This field represents the base URL of the resource. For
e.g. value can be http://localhost:9998 that
specifies the protocol (HTTP/HTTPS), the server name
(localhost) and the port number (9998). The base URL will be
common to all sub-resources that are created as child
resources of this resource. This is also a required field.
The Base URL field is editable only for the Root Resource. Sub-resources will automatically inherit this value from their parent resource.
This is non-editable value that represents the path inherited by this resource from all its parent resource hierarchy. For root resources, this value will is empty (None).
This field represents the actual context path of the
resource. In this example, it is set to
/stockquote and the final resource URL will
be http://localhost:9998/stockquote, which is a
combination of the Base URL and the specified Resource URI.
The button can be used to specify the values for any resource parameters specified as part of the resource URI. Please refer to this section on the different types of resource parameters for more information.
This field represents the available HTTP methods that can be used to invoke this resource URL. The available methods are GET, POST, PUT, DELETE, OPTIONS, HEAD. It defaults to GET.
This field presents the available pre-defined content types that can be set when sending the request to the resource endpoint. The default set of values are as shown below.
If the content-type you would like to set is not
available, you can click on the
button to add a new content type to the
list and select it.
The Accept field can be used to specify the value of the Accept HTTP header. By default, this value is */*, which means that there is no preference for the client in terms of the content type that the server should send the response in.
Subresources are resources that are created as children of a root resource or as children of other subresources. The subresource represents a REST endpoint whose request URI contains as part of its path, the URI of its parent resource.
For e.g. if a root resource contains a full request URI such as
http://localhost:8080/employees, then a possible
subresource URI would be of the form
http://localhost:8080/employees/john.doe. Here the
subresource request URI is /john.doe and it inherits the
/employee path from its parent resource.
Subresources are identified by the icon:
in the REST project tree view. To create a new
subresource, right click on either an existing root or subresource and
select Sub Resource as shown below:
Clicking on the subresource icon on tree view displays its details as shown below:
The subresource details view is similar to the root resource details, except that the Base URL field is disabled and its value is populated with the value from the parent resource. If the parent resource is also another subresource, then the value is got its parent and so on until a root resource is encountered.
Also, the Inherited Path field value is populated with the URI computed from the resource hierarchy leading up to this subresource. This path would be used as the prefix of the Resource URI value specified for this subresource.
REST resources can have different types of parameters that make up the data portion of the request. This data can be sent as part of the request in multiple ways to the resource endpoint. Following are some of the different resource parameters that can be configured:
Query parameters are field-value pairs that are sent as part of the
request URI query string. A typical URL containing a query string is as
follows:
http://server/path/resource_name?query_string.
The query string is the last portion on a request URL and is specified
after the ? character.
To specify query paramters for a resource, enter them in the Resource URI field as shown below:
In the figure above, the Resource URI value is
specified as quotes?symbol={sym}. The
?symbol={sym} part is the query string for this
resource endpoint.
The {sym} value is a placeholder for the actual data
that will be sent to the endpoint. This data can be entered by clicking
on the button, which brings
up the dialog as shown below:
It is not required to enter the value of the field in the form
{name} and the value can be entered as part of
the resource URI itself. It is however easier to manage the
data that makes up the fields of the query if you use the form
field1={value1}&field2={value2} and then
specify the values in the Resource
Parameters dialog.
Please note that if you have entered a placeholder in the resource URI then a value must be specified for that field, or there will be a runtime error when sending the request
Template parameters are parameters which are part of the request URI
path segment itself. The parameter is entered as {name}
anywhere on the request URI. An example of this shown below:
Here the resource URI value is set to
quotes/{symbol} where the parameter is
{symbol}. The value for symbol can be
entered by clicking on the
button.
Form parameters are name-value pairs that are usually submitted from a HTML Form. It is possible to send this kind of parameters to a HTTP endpoint when using a "write" HTTP operation like PUT or POST. The figure below shows a sample configuration for a resource endpoint that accepts form parameters:
To send form parameters to the resource endpoint, the following must be done:
Set the HTTP method either PUT or POST
Set the Content-Type field value to be
either application/x-www-form-urlencoded or
multipart/form-data.
Add one or more form data through the Request->Form Data tab.
If the content-type value is multipart/form-data, then
the form values are sent as MIME multipart values in the request (as if
they were attachments).
If the content-type is application/x-www-form-urlencoded,
the entered form values are sent as name=value in the
request body.
The Form Data tab under the
Request tab will be disabled if the
Content-Type value is not either
application/x-www-form-urlencoded or
multipart/form-data
Header parameters are nothing but HTTP request headers that are sent to the resource endpoint. Please see the section on configuring the HTTP request for more information on how to send custom HTTP headers.
Matrix parameters are request URI parameters that take the form
;name=value. They are similar in purpose to query
parameters but unlike query parameters can appear anywhere in the path
and don't necessarily have to be at the end of the URI. Below figure
shows how to create a subresource with a matrix resource parameter in
the request URI:
Here the ;currency={currency} part of the request
URI corresponds to the matrix parameter and is part of the path segment
that also contains the template parameter {symbol}
You can enter the values for the two parameters using the button
Other aspects of the HTTP request sent to the resource endpoint such as the HTTP headers, Authentication information or the SSL configuration if the endpoint is using the HTTPS protocol can be configured by clicking on the Request tab.
To send custom HTTP headers, click on the button to add a new row in the headers table and specify a value for the Name and Value fields.
Only HTTP headers configured for the current resource will be sent in the request and any headers configured for the parent resource(s) are not sent
If the REST resource endpoint requires either HTTP Basic or Digest authentication, it can be configured through the Authentication tab as shown below:
Click on the checkbox to enable the username, password and related fields.
The checkbox if enabled results in the Authorization header being sent to the service even before the service challenges for the credentials.
The Authentication Type field can be either Basic or Digest and it results in the use of either HTTP Basic Authentication or HTTP Digest Authentication as outlined in the RFC 2617 (http://www.ietf.org/rfc/rfc2617.txt)
If the resource endpoint is accessible over HTTPS, then it is possible to specify the keystore and / or truststore to use for SSL key negotiation. To do this select the SSL tab under the Request tab as shown below:
Click on the checkbox to enable specifying a keystore and/or truststore to use.
The KeyStore and TrustStore drop-down boxes display all the available keystores in the system for the currently logged in user.
If SSL Client Authentication must be performed, then select the keystore that contains the private key whose equivalent public key is known to the service provider. To disable SSL Client Authentication, leave the KeyStore field empty.
To specify a custom truststore that contains the service provider’s X.509 certificate, select a truststore from the available stores. This truststore must contain the server certificate imported as a public key in it.
The field determines if the hostname specified in the X.509 certificate obtained during SSL handshake will be compared against the hostname of the endpoint to which the request is sent.
The ‘Refresh keystores’ button reloads all the available keystores and truststores.
To send attachments as part of the REST request to the resource endpoint,
the Content-Type value must be set to be either
mulitpart/mixed or multipart/form-data.
In the Request tab, select the Attachments tab to upload files that should be sent as attachments (MIME parts) in the request message.
The buttons in the
Attachments tab will be disabled if the
content-type is not one of mulitpart/mixed or
multipart/form-data .
Clicking on the button brings up the dialog to upload a file from your local system to the server running Examine as shown below:
Click on button to select a local file and then click on to transmit the file to the Examine server. The uploaded file is stored in a user-specific attachments folder that is unique for each individual Examine user.
Once the file is uploaded successfully, it is displayed in the attachments
table. The content type of the file is determined automatically. The Content
ID column is empty by default and setting a value (which should be unique
for each attachment) here will set the Content-ID MIME
header.
Every REST resource details view includes the Test tab that be used to configure the test case for that particular resource. This is useful when you want to assert some information in the response coming back from the resource endpoint. This functionality is similar to configuring a test case for SOAP scenarios.
The Test tab allows for adding assertions that execute on the REST response and verify the assertion requirements. The available assertions can be seen clicking on the button as shown below:
The link can be used to associate this REST test case with an existing Test Suite or a new REST-only Test Suite.
The default set of available Test Assertions for REST resources as follows:
This assertion verifies that the HTTP response code is a particular code such as 200 (OK) or 401 (Unauthorized)

This assertion can be used to check if a particular HTTP header is present, absent or is equal to a certain value.

This assertion can be used to verify if the HTTP response was either less than or greater than a certain threshold value specified in milliseconds.

This assertion can be used to check for the presence of a particular token in the HTTP response. If the ‘Regular Expression’ checkbox is checked, then the specified text is used a regex pattern against the REST response body. The regex pattern should follow the Java regular expression rules.

For more information on how to use Regular Expressions, please refer to this page: http://download.oracle.com/javase/tutorial/essential/regex/
This assertion can be used to check if an XPath expression evaluates properly against the REST response (if it is XML). Click on the ‘Configure’ button to open the XPath Expression dialog box where you can enter the XPath expression to use and declare the namespace URIs for any prefixes used in the expression.

Each namespace declaration should be entered on a new line and
is of the form:prefix = URI

The result of evaluating the XPath expression will be a Boolean true/false. If the xpath expression results in DOM Nodes, then the result is True and if no there are matching nodes, the result is false. If the expression contains a predicate clause, then the result is either true/ false as well.

This assertion can be used to perform XML Schema validation of the REST response body contents. This is only applicable if the response is in XML format. To add XML schemas against which the response should be validated, click on the button to open the XML Schema configuration dialog as shown below.

The button can be used to upload a single W3C schema (XSD) file or a zip file containing the root schema and its imports/includes as relative references within the same archive.
When the REST resource is executed, the assertions configured in the Test Case are verified against the response. The assertions that failed and succeeded are highlighted in red and green respectively as shown below:
Table of Contents
Test suites provide a logical way to group test cases together so that they can be executed as a single group. In Examine, there are two types of Test Suites that can be created:
SOAP test suite
REST test suite
SOAP and REST test suites allow for grouping SOAP scenario test cases and REST resource test cases respectively. It is not possible to add a REST test case to a SOAP test suite and vice versa.
Test Suites provide the following main benefits:
Group related test cases together to execute all of them as part of a single run
Schedule test suites to run periodically or at well-defined time intervals to get repetitive results
Pause and resume schedules to control the execution of test suites based on resource availability
Get notifications through email or instant messages (Jabber) when a test suite completes a run
To create a new Test Suite, open the TestSuite view by clicking on the top-level TestSuite tab and click on the button to open the Create New Test Suite dialog as shown below:
Specify a unique TestSuite name and choose the Test Suite type and click on
:
| SOAP (default selection) |
| REST |
The created TestSuite is displayed in a list view as shown below. SOAP test suites
are identified by the
icon and REST test suites are tagged with the
icon.

Clicking on the SOAP test suite opens the details view that displays the test suite configuration tabs. By default, a new test suite does not contain any test cases.
To add one or more test cases that are part of SOAP scenarios, click on the button to open the Add Scenarios to Test Suite dialog. This dialog displays all the available SOAP projects and the scenarios that make up the SOAP project. Since each scenario contains a SOAP test case, adding a SOAP scenario implicitly adds the test case associated with that to the test suite.
A sample screenshot displaying the SOAP scenarios that are part of the
rampart-basic-sample02 SOAP project is shown below:
You can select more than one SOAP scenario by Ctrl/Cmd-clicking the entries and clicking on
To create a new REST test suite, follow the instructions as listed in the section 'Creating a new Test Suite' and choose REST as the test suite type.
To add one or more REST Resource test cases to the test suite, click on the button to open the Add REST Resources to Test Suite dialog and select one or more REST resources as shown below:
Since each REST resource includes a separate test case adding a REST
resource adds its related test case to the test suite. Selecting a root resource,
will automatically add all the subresources under that resource. If this is not
desirable, then you can Ctrl/Cmd-click the individual resources and click on
to add them to the test suite.
One of the main benefits of creating a Test Suite is that it can be scheduled to run one or more times at pre-defined intervals. Examine makes use of the fantastic Quartz open-source scheduler to schedule jobs and run them at the user-set time intervals. There are two types of schedules that can be created for each Test Suite:
Simple schedule
Cron-based schedule
To create a new schedule switch to the Schedules tab and click on the Add New Schedule link. The Schedules tab displays all the schedules created for this Test Suite in a table as shown below:
When a test schedule is running, clicking on the button reloads the available result data for the schedule until that point and updates the execution state of the schedule.
The checkbox when checked automatically
refreshes the schedule state and the execution result data every 2
seconds.
A running schedule can be paused and resumed during the and buttons. A paused schedule will stop any more executions of the Test Suite until it is resumed again.
Test Suite schedules can be the following execution states at any given time:
)Initial state that all schedules start with. Schedules remain in this state until they have started based on their start date/time
)The state that the schedule is in when it is currently running the test cases that are part of the test suite to which this schedule belongs.
)The final state that the schedule transitions to after it is
has completed all the required runs (based on the repeat count
if it was set). For e.g. if the schedule is created to repeat 3
times. Then it will transition to COMPLETED
state after 4 successful runs.
)When a schedule is currently running, it can be paused to stop
any more execution of the test cases that are part of the test
suite to which this schedule belongs. The schedule remains in
this state until it is resumed, in which case it transitions to
the RUNNING state. Note that pausing
schedules in PENDING and
COMPLETED state does not affect the
state.
A Simple Schedule, as the name implies is the simplest and quickest way to create a Test Suite schedule. The Simple Schedule is based on the Quartz SimpleTrigger functionality. The options for this type of schedule are as shown below:
This is a required field that should specify a unique logical name for the Test Suite schedule.
Click on the link button to open the calendar dialog to select the date and time that this schedule should start its first run. If it is not selected, the start date defaults to "now" i.e. the schedule will take effect immediately
Click on the link button to open the calendar dialog to choose the date/time when this schedule will stop execution. The end time if specified overrides the repeat count value. This is useful if you don't care about the number of exact times the test suite executes and ould like to see it run until a specific end time at a specific repeat interval (if specified).
Specifies the number of additional times that this test suite will execute. By default this value is 0, which means that the test suite executes only once. For e.g. if the value is 3, then there will 4 total runs.
Specifies the time interval between the job repetitions. For e.g. if the inteval is specified as 5, then the test suite executes every 5 seconds until the repeat count +1 iterations or until the end time.
A cron-based schedule is an alternate way to schedule Test Suites. It makes use of a "cron" expression to specify the frequency and time-constraints of the execution of the Test Suite.
"cron" is an unix program that is used to schedule jobs (command and shell scripts) to run periodically at certain dates and times. It is generally used to automate some administration tasks like backing up data or checking email etc.
The cron-based scheduling feature of Examine leverages the powerful cron-like functionality provided by the Quartz scheduler. Quartz provides a CronTrigger that is used by Examine to schedule Test Suite executions.
The options for this type of schedule are as shown below:
This is a required field that should specify a unique logical name for the Test Suite schedule.
Click on the link button to open the calendar dialog to select the date and time that this schedule should start its first run. If it is not selected, the start date defaults to "now" i.e. the schedule will take effect immediately
Click on the link button to open the calendar dialog to choose the date/time when this schedule will stop execution.
Specify a valid cron-expression that indicates how frequently this job should execute.
Cron-Expressions are strings that are actually made up of seven sub-expressions, that describe individual details of the schedule. These sub-expression are separated with white-space, and represent:
Seconds
Minutes
Hours
Day-of-Month
Month
Day-of-Week
Year (optional field)
An example of a complete cron-expression is the string "0 0 12 ? * WED" - which means "every Wednesday at 12:00:00 pm".
For a detailed explanation of how to specify the cron-expression, please refer to the excellent Quartz documentation on this topic:
http://www.quartz-scheduler.org/documentation/quartz-2.1.x/tutorials/tutorial-lesson-06
http://www.quartz-scheduler.org/documentation/quartz-2.1.x/tutorials/crontrigger
If an Examine administrator has setup an Email and/or Jabber server as described in the sections Email Configuration and Jabber Server Configuration, then as a user, you can get notifications via email and/or instant message (XMPP protocol) whenever a scheduled Test Suite completes its execution.
To configure the notification options for the Test Suite, select the Settings tab in the Test Suite Configuration page as shown below:
After updating the notification settings, please click on the button to save the configuration information
To get notified by email select the checkbox. You can specify additional email recipients as a comma-separated list of values as well.
Ensure that you have specified your email address in the profile configuration screen as outlined in the section Profile Configuration. If a valid email address is not specified, you will not receive any email notifications (any additional recipients listed however will)
To get Instant Message (IM) notifications, check the Send Jabber notification checkbox.
Ensure that you have specified your Jabber ID in the profile configuration screen as outlined in the section Profile Configuration. If a valid IM address is not specified, you will not receive any IM notifications
Table of Contents
Examine comes with a built-in Security Token Service (STS) that can be setup by each individual Examine user to issue SAML 2.0 tokens through a WS-Trust response. The STS service is based on the JBoss PicketLink Federation project and integrates the PicketLink STS seamlessly with the Examine framework to provide an easy to setup and configure token provider. Anyone who has ever worked on setting up an STS to issue SAML tokens knows the intricacies involved in configuring and running the STS. Often this is a difficult and time-consuming task especially when you need to quickly obtain a SAML 2.0 token for testing purposes. We hope that the Picketlink STS integration will help with your testing needs.
The STS is available as a web service that can be enabled or disabled by each individual user who has an account in the Examine server. By default the STS endpoint is inactive until is configured and activated by an user.
The STS configuration involves two main sections:
Setting up the main configuration for the core STS itself
Configuring the WS-Security settings for the STS endpoint - this is inturn divided into Request and Response security configurations
One of the current limitations of the built-in STS is that it only handles the "Issue" WS-Trust binding and can only issue SAML 2.0 tokens through a WS-Trust Request Security Token Response (RSTR). Issuing SAML 1.1 tokens is expected to be implemented in a future release.
To setup the STS to issue SAML 2.0 tokens, click on the main STS tab and select the STS Configuration child tab. This brings up the main configuration screen as shown below:
Click on the to make the STS endpoint active. If the checkbox is not checked, the STS endpoint will not be available. Make sure that the button is clicked to activate the changes.
The STS Name value specifies the logical name of the STS. This is a required field and must be specified.
The Token Time-to-live field specifies the duration issued token will be valid. It defaults to 5 minutes or 300 seconds.
The STS must be configured with a valid Keystore and Signing Alias so that the issued token can be signed correctly. To do this click on the button to launch the Available Keystores dialog and select a private key from one of the available keystores as shown below:
Once the Signing alias and Keystore have been selected, they are displayed as shown below in the read-only Signing Alias and KeyStore fields.
The issued SAML token can be encrypted with the public key that corresponds to the Service Provider (Relying Party) to whom the SAML token will be sent as part of a WS request.
To do this, select the checkbox and add an
entry in the Service Providers table by specifying the Provider
Endpoint and the Truststore alias. The Provider
Endpoint value must correspond to the <wst:AppliesTo/> element value
in the WS-Trust RequestSecurityToken (RST) sent to the STS by the token requestor (client).
Note that the Truststore Alias combobox displays the
available public key aliases present in the Signing Keystore selected to sign the
issued token. For e.g. in the example above, the sts.jks keystore
selected as the signing keystore contains one private key: sts
and two public keys: client and service. These
two public keys are displayed in the Truststore Alias
field.
When the RST WS-Trust request arrives at the configured STS, if there is a AppliesTo value that corresponds to one of the Provider Endpoint values specified above, then the chosen public key alias will be used to encrypt the issued token such than only the service provider can decrypt it.
The configured STS endpoint can be secured with WS-Security settings which can be enforced for the request coming to the STS and the response sent from the STS back to the client.
To enable WS-Security for the client request coming to the STS, click on the Request Security tab and select the checkbox as shown below:
The following WS-Security Request settings can be configured -
Enabling this checkbox will require that the timestamp be present in the WS-Security header in the RST request from the client
Enabling this checkbox will require that the client send a WSS UsernameToken in the request. To authenticate the credentials, the list of allowed usernames and passwords must be specified under the Allowed username token principals table.
To require that the RST request SOAP Body must be signed by the client, select the Require Signed request checkbox and click on the button to open the Truststore selection dialog and choose a public key alias from the list of available keystores.
To require that the RST request SOAP Body must be encrypted by the client, select the Require encrypted SOAP Body checkbox and select the private key alias that should be used to decrypt the encrypted data by clicking on the button.
To enable WS-Security for the RSTR sent by the STS to the client, switch to the Response tab and select the checkbox. The available configuration options are as shown below:
Select the checkbox to add a Timestamp element to the WSS header in the RSTR. The timestamp duration defaults to 5 minutes / 300 seconds.
To sign the RSTR SOAP Body element, select the checkbox, and pick the signing alias by clicking on the button. This brings up the Signing Alias selection dialog that displays all the available keystores. Make sure you that you specify the alias password or select the checkbox to use the keystore password instead.
To encrypt the SOAP Body of the RSTR, select the checkbox and select the public key that corresponds to the client. The Encryption alias dialog is as shown below:
Note that if you select a public key alias that corresponds to a client, then only that specific client can decrypt the RSTR. As an alternative, you can enable the option if the client sends its public key in a certificate in the request after signing the RST SOAP Body. However, this option will only work if the client signs the request and its public key is available either in the request or accessible through the configured truststore (as described in the section Response Signature above)
Table of Contents
Examine also provides the following helpful tools under the ‘Tools’ tab.
XML Schema Validator
XPath Evaluator
XSL Transformer
Schema (XSD) XML Generator
JSON-XML Converter
SAML 1.1 Token Generator
STS / WS-Trust Client
XSD to XML generator JSON to XML converter XML to JSON converter SAML 2.0 Token generator
This tool is useful when you have an XML schema available and would like to validate some XML content against the schema(s) to check if the contents comply with the specified XML constructs.
There are two ways to do XML Schema validation of input XML:
Against a specifics XML Schema (XSD), or
Against a schema validation scenario
The first step is to add any schemas that should be used to validate the input xml. This can be done by clicking on the ‘Schemas’ tab.
Clicking on ‘’ will open the schema upload dialog as shown below:
Click on to select either a single schema
file (.xsd) or a ZIP archive file that contains the main
schema file and its related imports/includes as relative references from the
main schema. If a ZIP file is uploaded, Examine automatically unzips it and
displays the available schema files in the archive as shown below:
In the example above, a file called catalog.zip
was uploaded and its contents are displayed. The main file
catalog.xsd includes as relative reference two other
files (pricing.xsd and sequence.xsd)
which are co-located with it. Here it is expected that the user knows which
schema is the main/root schema and which one are the imports/includes from it.
Clicking on the schema name displays the schema contents in the ‘Schema’ tab on the right.
It is possible to edit the displayed schema and save it using the
‘’ button. ‘’ can be
used to revert any changes made prior to
clicking on . Since Examine does not keep track of
revisions, it is not possible to revert once has
been clicked
Schema validation scenarios provide a convenient way to group multiple schemas to be used as source to validate some input XML. Sometimes the contents of an XML document will need to be validated against multiple distinct schema files. This option allows you to create a schema-grouping.
To create a new validation scenario, click on ‘’ to bring up the dialog as shown below:
Specify a unique non-empty validation name and select from the
displayed schema files. Note that only those schema files which have been
uploaded to the Examine system as described earlier in the Uploading XML Schemaswill be
displayed here. You can use Ctrl/Cmd-Click to select multiple files at once.
The created scenario is displayed in a tabular form under the ‘Scenarios’ tab:
Once the schemas have been uploaded, it is now possible to validate any input XML against a specific schema / a validation scenario. To do this, first paste the XML content in the ‘Input XML’ text area under the ‘XML’ tab on the right side and then click on the ‘’ button to bring up the Validate XML dialog as shown below:
Select either the ‘Schema’ or the ‘Validation Scenario’ option and the corresponding name of the schema or scenario. Clicking on will initiate the schema validation process and the result is displayed as either a successful validation or in the case of a failure, the schema error message is displayed.
The XPath Evaluator tool can be used to evaluate XPath expressions against a source XML document to verify if the expression matches any nodes.
Currently, this tool only supports evaluating XPath 1.0 expressions.
To use this tool, copy and paste the input XML against which the XPath should be evaluated in the ‘XML’ or ‘Raw’ tabs. The ‘Tree’ tab displays the input XML in tree form which can be easier to visualize and / or make minor edits (like adding a text node or attribute). The figure below shows the XML view with some input XML and an XPath expression to evaluate the value of an element:
When the input XML is pasted in the editor, any namespace declarations specified in the document, will be automatically added to the Namespaces table as shown below. Additional user-defined namespace prefix-uri mappings can also be defined or removed.
Click on the button to evaluate the XPath expression. The result of the evaluation is displayed in the XPath Result table at the bottom of the XML view
The ‘XSL Transformer’ tool can be used to apply an XSL (XML Stylesheet Language) transformation on some input XML content and see the result of the execution. It is accessible under the -> tab.
To perform an XSL transformation, a input XSLT document and an input XML document are required. Copy and paste the XSLT file contents in the top editor screen under the ‘XSLT’ tab.
If the input XSL has any input parameters, they can be specified through the Parameters tab.
The input XML to be transformed must be copied and pasted in the editor under the ‘Input XML’ tab. The ‘’ button can be used to pretty-print the input XML contents. ‘’ removes any input already present in the text editor.
Once the input XSLT and XML contents are specified, clicking on the ‘’ button will cause the transformation to be performed and the results to be displayed in the editor under the ‘’ tab
To save the XSLT for future use against other XML content, click on the '' button to open the Save XSLT dialog and specify a unique name. The saved XSLT configurations are displayed in on the left in the Saved XSLTs table.
The XML Schema (XSD) to XML instance generator tool is useful for generating sample XML messages based on an XML Schema (XSD) document. It is accessible under XSD->XML tab under the Tools tab.
The first step is to add a schema file by uploading it to the server. This is done by clicking on ‘’ and uploading either a single schema file (.xsd) or a zip file containing the main schema file and its references.
The uploaded schema file is displayed in a table on the left and clicking on the schema file name, displays the contents in the editor (Schema tab) on the right. The ‘’ and ‘’ buttons under the Schema tab can be used to make changes to the schema being edited or revert any unsaved changes.
When the schema is displayed, the Root Element drop-down box displays all the root elements declared in the schema file, which can be used as the starting root element in the generated XML file. The screenshot below shows the process of selecting a root element in a schema file:
The XML instance generation can be configured through certain options which are available by clicking on the button. The options dialog is as shown below:
Controls whether attributes which are specified as optional in the schema will be generated
Controls whether attributes which are specified as optional in the schema will be generated
Controls whether XML comments (of the form <!-- …
-->) will be generated for the schema
particles
Controls the number of duplicate elements to generate when the maxOccurs attribute value is ‘unbounded’ for the element. Default value = 3
Controls the number of recursive calls to make when processing an element which refers to itself, or to another element which in turn refers to the element referring it. Default value = 1
Controls which element to select when processing the
<xs:choice/> element. The available options
are: First and Random. First will result in the first element
under choice getting selected and Random results in a random
pick of the element to process
Controls whether the generated XML will be in compact form or pretty-printed
Clicking on ‘’ will result in the currently selected options being applied to the generation process. A new tab displaying the generated XML is shown next to the ‘Schema’ tab for every generation.
This tool can be used to interconvert between JSON (JavaScript Object Notation) and XML content.
To convert a JSON string to XML, select the checkbox as shown below. The editor on the left represents the input JSON source that must be converted into XML and the editor on the right represents the output result in XML.

If the JSON string is in BadgerFish notation, then it can be converted to XML as is since the namespaces are already present in the JSON string.
The Options link can be used to configure the XML generation options: For JSON in BadgerFish (BF) notation, the option available is “Ignore whitespace”.
Consider the following JSON source that declares the namespaces as part
of the property names:
{"alice": {
"bob": {"$": "david"},
"charlie:edgar": {"$": "frank"},
"@xmlns": {
"$": "http://some-namespace",
"charlie": "http://some-other-namespace"
}
}}
The XML output when using BadgerFish convention is as shown below:
<alice xmlns="http://some-namespace" xmlns:charlie="http://some-other-namespace"><bob>david</bob><charlie:edgar>frank</charlie:edgar></alice>
If the input JSON string value has any whitespace characters like "\n" and the checkbox is enabled, then the generated XML will not have those whitespace characters present in the data.
For JSON in Mapped notation, the available configuration options are as shown below:
The option is as described above.
Consider the same example in mapped notation (where the prefix is present in the property, but the namespace URI is absent):
{"abc.alice":{"abc.bob":"david","xyz.edgar":"frank"}}
To convert this JSON input into XML using Mapped notation, we have the option of either specifying the namespace URI for the prefixes (abc and xyz) or leaving it unspecified. This is controlled through the option. If this option is disabled, then the Configure NS->Prefix Mapping table is enabled and we can specify the namespace URI -> Prefix mapping.
If the URI - Prefix mapping is done as follows:
Table 9.1. Namespace URI - Prefix mapping
| Namespace URI | Prefix |
|---|---|
| http://some-namespace | abc |
| http://some-other-namespace | xyz |
The generated XML output is as follows with this mapping in place:
<?xml version="1.0" encoding="UTF-8"?> <alice xmlns="http://some-namespace"> <bob>david</bob> <edgar xmlns="http://some-other-namespace">frank</edgar> </alice>
To convert an XML string to JSON, select the checkbox as shown below. The editor on the left represents the input XML source that must be converted into its equivalent JSON form and the editor on the right represents the output result in JSON.

Consider an input XML as given below that needs to be converted into JSON:
<?xml version="1.0" encoding="UTF-8"?> <alice xmlns="http://some-namespace" xmlns:charlie="http://some-other-namespace"> <bob>david</bob> <charlie:edgar>frank</charlie:edgar> </alice>
The above XML can be converted into JSON using either the BadgerFish notation or the Mapped notation. Clicking on the button opens the Conversion Options dialog as shown below:
When the checkbox is enabled, the only available configuration option is the checkbox, which if enabled, will ignore any whitespace characters present in the input XML document when generating the output JSON content. For the input XML above, the generated JSON string when using BadgerFish convention is as follows:
{"alice":{"@xmlns":{"$":"http:\/\/some-namespace","charlie":"http:\/\/some-other-namespace"},"bob":{"$":"david"},"charlie:edgar":{"$":"frank"}}}
When the checkbox is enabled, the configuration options are as shown below:
In the configuration dialog above, the option ignores the presence of any whitespace
characters in the input XML.
The option if enabled, will cause any data such as numbers to be detected as a number and output as such instead of a string. For e.g. if an element contains the value 10, then instead of outputting the value as "10", the JSON value will be output as 10.
The option if not enabled, allows you to declare the namespace to prefix mapping that should be applied when generating the JSON content. Note that even though the namespace URI is specified, the mapped convention does not allow for capturing the URI and only uses the prefix specified in the generated output. For the input XML above, the generated output is as follows with this option enabled:
{"alice":{"bob":"david","charlie.edgar":"frank"}}
Examine has a SAML 1.1 token generator tool that can be used to hand-craft a SAML 1.1 Assertion. While this is usually not the way SAML assertions are generated or issued, it does provide an easy and quick way to create a SAML 1.1 token.
The SAML 1.1. Token Generator tool is accessible from the Tools->SAML menu tab. The main configuration view is as shown below:
The SAML token generator currently can only be used to generate a SAML 1.1 Assertion. If you would like to generate a SAML 2.0 Assertion, you can use the built-in STS that can issue SAML 2.0 tokens from a WS-Trust RequestSecurityToken SOAP request and use the STS Client tool to send this RST request to it. For more information refer to these sections: STS Service and STS Client
For more information on the SAML 1.1, please refer to the specification set here: http://www.oasis-open.org/standards#samlv1.1
A SAML Assertion is a collection of information that includes one or more statements about a subject made by a SAML authority. In SAML 1.1, the Assertion can hold one or more statements that correpond to the subject. However, since the Subject information is common to the statements, this tool allows you to specify the Subject information once and have that applied to the different statements added to the assertion.
The main configuration fields are:
This field corresponds to the SAML 1.1.
AssertionID attribute. It represents the
identifier for this Assertion and is of type
xsd:ID
This field corresponds to the SAML authority that created the assertion. The issuer name should be unambiguous to the intended relying parties.
The time instant when this Assertion was created/issued.
Every type of SAML 1.1 Statement includes information about the Subject about whom the Statement is being made. Thus the Subject represents the core entity around which a SAML Assertion is focused on. Even though it is technically possible in SAML 1.1 to have statements about different subjects, in reality all statements within an Assertion are usually made about a single Subject (this is also the view taken in SAML 2.0 where the Subject information is separated from the Statement itself).
A SAML Subject consists of a <NameIdentifier/> and
<SubjectConfirmation/>.
To configure the <NameIdentifier/> element, specify the value
for the Name Qualifier field which represents the name of
the Subject, and select the URI reference that indicates the format of the name
qualifier. The possible values for the Format are:
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
A SAML Assertion can have one or more Condition elements that specify certain restrictions / conditions on the use of the assertion by the relying party. To configure the Conditions for this Assertion, switch to the Conditions tab as shown below:
Click on the calendar icon to bring up the monthly calendar with time and select the instant from which this Assertion will be valid
Click on the calendar icon to select the time upto which this Assertion will be valid
Selecting this checkbox adds the
<DoNotCacheCondition/> element to the
Assertion
Click on this button to add one or more
<AudienceRestrictionCondition> elements that
specifies that the assertion is addressed to one or more
specific audiences identified by <Audience>
elements as shown below:
Click on the link to add an Audience URI field where you can specify the URI of the intended audience
A SAML Assertion can contain an <Advice/> element that can
contain some additional information that can help the relying party process the
Assertion. To configure this information switch to the
Advice tab.
The following actions are available to add different kinds of Advice to
the Assertion:
Click on this button to open a dialog where you can specify another SAML Assertion element contents that should be packaged as an Advice. Note that the SAML Assertion element XML that you paste here must be a valid SAML 1.1 Assertion element (i.e. in the correct SAML 1.1 namespace)
Click on this button to open a dialog where you can specify the value of the ID attribute of another SAML 1.1 Assertion
Click on this button to open a dialog where you can specify any valid XML element that should be added to the Advice element
Every SAML Assertion usually contains one or more of the following kinds of Statements about a Subject:
| Attribute Statement |
| Authentication Statement |
| Authorization Decision Statement |
To add one or more of the above Statements to the Assertion, switch to the Statements tab.
To add a new Attribute Statement, click on the link to add a new tab that represents the statement. Click on the button to open the Add Attribute dialog where you can specify the name, value and the namespace of the attribute as shown below:
Click on adds a new Attribute for the Attribute Statement as shown below:
To add one or more Authentication Statement's to the Assertion, click on the button to add a new tab that represents the Statement as shown below:
Each Authentication Statement consists of the Authentication method
used to authenticate the Subject, the time at which the authentication took
place and information about the locality of the Subject.
To add an <AuthorizationDecisionStatement/> element to the
Assertion, click on the button and
configure the request URI and decision information as shown below:
The Decision Type value can be one of:
Deny
Permit
Indeterminate
To add one or more <Action/> elements click on the
button to select the Namespace of the Action
and the Content for the Action (string data).
To add an <Evidence/> element that holds either a
<AssertionIDReference/> or an <Assertion/>
element, click on the button and select either
the or buttons to specify the respective values.
Once the SAML Assertion has been configured as detailed in the above sections, you can opt to sign the Assertion using a private key to provide integrity protection to the generated Assertion. To do click on the button and select a private key alias from one of the listed keystores, and specify the private key password as shown below:
If the private key password is the same as the keystore password, you can just select the button to use the keystore password itself. Since the password was specified when creating the keystore initially, you don't have to specify the same password again!
To finally generate the configured SAML 1.1 Assertion, click on the button to generate the SAML 1.1 Assertion XML element which will be displayed in a separate dialog box as shown below. You can click on the button to save a copy of the XML to your local filesystem. Clicking on the button reformats the XML to be pretty-printed.
Once you sign the Assertion, clicking on will likely invalidate the content that was signed thus causing signature validation to fail (because of the addition of whitespace characters)
Examine has a simple but effective WS-Trust client that can be used to interact with a Security Token Service (STS) to obtain a token such as a SAML 1.1/2.0 token from the issuer. The STS Client tools is accessible from the Tools->STS Client tab.
To configure the STS client to send a WS-Trust RequestSecurityToken (RST) SOAP request to an STS endpoint, select the Main tab. The main configuration screen is as shown below:
The SOAP version radio box indicates the SOAP version of the request sent to the STS Endpoint. It defaults to SOAP 1.1.
The WS-Trust Version can be either 1.0 or 1.3 and defaults to 1.3. The WS-Trust Version maps to the following request namespaces:
Table 9.2. WS-Trust version namespace mapping
| Version | Namespace |
|---|---|
| 1.0 | http://schemas.xmlsoap.org/ws/2005/02/trust |
| 1.3 | http://docs.oasis-open.org/ws-sx/ws-trust/200512 |
This is a required field that points to the STS endpoint service.
You can specify the AppliesTo element value by selecting the checkbox and specifying the endpoint of the target/relying service as shown below:
Consider the e.g. where the Applies To value is specified as
http://localhost:9090/services/EchoService. This translates to the
following XML fragment in the WST RST request sent to the STS endpoint.
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>http://localhost:9090/services/EchoService</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
The Token Type field can be used to specify the URI of the type of token that the STS should issue to the requestor.
The specified value translates directly to the <wst:TokenType/>
element in the RST request. The button provides a
convenient way to select from a default set of pre-defined Token Type values that
can be selected. Note that you are not restricted to using one of these default
values. If the STS you are using supports issuing a different token than what is
listed here, you can specify the Token Type value directly in the text field.
The <wst:Lifetime/> element value is used to specify the desired
valid time range (time window during which the token is valid for use) for the
returned security token.
Select the checkbox and specify the
duration in seconds that the requested token must be valid for. Note that the STS
may choose to ignore this value even if it is specified. If the value is specified
as 300 seconds, the Lifetime element is generated as follows in
the RST request:
<wst:Lifetime xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2011-02-05T21:45:07.476Z</wsu:Created>
<wsu:Expires>2011-02-05T21:50:07.476Z</wsu:Expires>
</wst:Lifetime>
The <wst:KeyType/> is an optional URI element that indicates the
type of key desired in the security token being requested. The following are the key
types that can be specified in the request:
This option indicates that a public key token is requested. The
key algorithm URI value is: WST_NS + /PublicKey
where WST_NS depends on the chosen WS-Trust Version
The configuration dialog for this key type is as shown below:
If the checkbox
is enabled, then you can select the X.509 certificate that will be
sent in the <wst:UseKey/> element to the STS
service. Selecting the checkbox, displays the available keystores
dialog from which you can select a public key that holds the
certificate to be sent. For e.g. selecting the public key 'client'
results in the following XML fragment being sent as part of the RST request:
<wst:UseKey>
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate>MIICvDCCAiWgAwIBAgIE...xqECxcUnN5NZ/+HTESk4vM=</ds:X509Certificate>
</ds:X509Data>
</dsig:KeyInfo>
</wst:UseKey>
This option indicates that a symmetric key token is requested. The
key algorithm URI value is: WST_NS +
/SymmetricKey where WST_NS depends on the chosen
WS-Trust Version
The configuration dialog for this key type is as shown below:
When requesting a SymmetricKey key type, it is possible to
indicate the desired key size in the request. To do this, enable the
checkbox and specify the
value of the Key Size field. It defaults to
256.
Currently, the WS-Trust 1.3 Bearer Token Key Type (
http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer)
is not supported
To simulate the scenario of obtaining a token on behalf of another party, you can
add the <wst:OnBehalfOf/> element that indicates that the requester
is requesting a token on behalf of another entity.
The identity on whose behalf the request is being made is specified by placing a
security token, <wsse:SecurityTokenReference> element, or
<wsa:EndpointReference> element within the
<wst:OnBehalfOf> element. To add this security token, copy-paste
a valid XML fragment that represents the Security Token or EPR in the
'OnBehalfOf Element contents' text field.
The button provides a convenient way to add a
<wsse:UsernameToken/> element directly as a child of the
<wst:OnBehalfOf/> element. For e.g specifying the user as
'admin' results in the OnBehalfOf element configured as follows:
Even though, the STS client doesn't currently support the WS-Trust 1.4
specification in its entirety, it does provide support for the
<wst14:ActAs/> element that provides some delegation
functionality. Note that the <wst14:ActAs/> element is in the
WS-Trust 1.4 namespace of
http://docs.oasis-open.org/ws-sx/ws-trust/200802
To quote the WS-Trust 1.4 spec about the ActAs element:
This OPTIONAL element indicates that the requested token is expected to contain information about the identity represented by the content of this element and the token requestor intends to use the returned token to act as this identity. The identity that the requestor wants to act-as is specified by placing a security token or
<wsse:SecurityTokenReference>element within the<wst14:ActAs>element.
The behavior is similar to the <wst:OnBehalfOf/> element, though
the semantics of it are slightly different. To add this security token, copy-paste a
valid XML fragment that represents the requestor's Security Token or EPR in the
'ActAs Element contents' text field.
The button provides a convenient way to add a
<wsse:UsernameToken/> element directly as a child of the
<wst14:ActAs/> element. For e.g specifying the user as 'admin'
results in the OnBehalfOf element configured as follows:
The HTTP-level Authentication and/or SSL-usage for the STS client can be specified through the HTTP tab. Note that by default, neither HTTP authentication nor SSL usage is enabled for any communication initiated by the STS client.
Other aspects of the HTTP client configuration such as the Connect Timeout are configured through the global HTTP configuration page accessible through Settings->HTTP
To specify the HTTP Authentication credentials when sending the WST RST to the STS endpoint, select the button as shown below:
Specify the values for the Username and
Password fields and select the Authentication
Type to use - which can be Basic or
Digest.
The checkbox if enabled, will cause the STS client to send the 'Authorization' header even before the STS endpoint prompts/challenges for authentication credentials.
If the STS endpoint is accessible over HTTPS, the SSL section can be used to configure the required Server and Client SSL Authentication settings. The checkbox must be checked to enable SSL configuration. The KeyStore and TrustStore combo boxes lists all the previously configured keystores. Both the fields are optional. The KeyStore value is only required if the server requires SSL client authentication.
The TrustStore value is required if you would like Examine to verify the server certificate when performing a SSL handshake with the server. If a truststore is not configured, Examine will accept any server provided certificate.
You can leave the TrustStore value unconfigured for Web Services under development or when using self-signed certificates for the SSL endpoint
The ‘’ field determines if the hostname specified in the X.509 certificate obtained during SSL handshake will be compared against the hostname of the endpoint to which the request is sent.
The ‘’ link reloads all the available keystores and truststores.
If the STS endpoint to which the STS client is sending the WST RST request is secured using WS-Security (such as UsernameToken, Signature or Encryption), then you can configure the STS client to conform to the WS-Security requirements of the endpoint by applying a pre-defined WS-SecurityPolicy-based Security Configuration as shown below:
The Available Configurations drop-down box displays all the available WS-SecurityPolicy-based Security Configurations. This option allows for re-using a global security configuration when sending the WST RST request
Please refer to the section on Global Policy-based Security Configuration for more information on how to create a security configuration that can be used by the STS client.