This component is used to expose an Event Process or a part of Event Process as a Web Service deployed in the Peer Server. WSDL for the service deployed can be fetched when this component is running and the URL of the WSDL can be used by Web Service clients to access the Web Service. Each instance of the component hosts a single web service. The component can be configured in two ways:
Manually defining the operations and related details in the UI
Loading a predefined WSDL and editing the populated web service details if required
The WSDL generated for the component will differ from the WSDL provided in following aspects:
End point address
If the provided WSDL contains multiple services, only the selected service will be present
The component generates request, response and error ports for each operation present in the selected web service.
During the component launch, it checks if a web service with the same web service name is already deployed. If no other service with same name exits, the web service is deployed to the Jetty Server running in Peer Server that hosts the component.
The web service deployed in the Jetty accepts requests from web service clients and sends the SOAP XML using internal JMS client to the request port of the operation there by injecting the request into the Fiorano Event Process for processing the request. On processing the request, the response SOAP XML should be generated and sent to the corresponding response / error ports. The web service receives the response from the internal JMS client and in turn sends the response as SOAP response to the client that made the request.
The component can be configured using the custom property sheet as shown in the following sections.
Figure 1: Configuration Property Sheet
This page is used to define the web service using a user interface for WSDL User can create a WSDL by manually defining different aspects of the service or can load an existing WSDL and edit the configurations.
Existing WSDL file can be used to define the web service as shown in figure 2. To load an existing WSDL file, the checkbox Load from file must be selected which shows the option below.
Figure 2: Loading Existing WSDL
The WSDL file can loaded using the file dialog that opens up
when the ellipsis 
is selected. The parent directory of the
selected file is set as the base URI for this definition. It can be changed by
clicking on the definitions node in
Basic/Advanced view of the definition and changing the Base URI field. If the loaded WSDL file has more than one service
defined, then the user is prompted to select one service for configuration as
shown in figure 3.
Figure 3: Service selection
This option can be selected if the WSDL files imported in the loaded WSDL have to be stored on the Jetty server. The imported files will be stored at FIORANO_HOME\esb\server\jetty\fps\webapps\bcwsgateway\wsdls\<ServiceName>\imports and their paths in the WSDL are updated when the component starts and deleted when the component stops.
Using this option allows the web service clients to access the import WSDLs as well relative to the actual WSDL. However, for this option to work the imported files should be present in the location specified in Base URI field and that location should be accessible from the Peer Server on which the component will be launched.
If this option is not specified, the web service clients should be provided with a copy of all imported WSDLs, if required.
WSDL dependency tree shows the WSDL and all the imported WSDL referenced directly or indirectly from the main WSDL. Each node in the tree represents a WSDL and the WSDLs that are imported in the WSDL represented by the node are represented by its child nodes. Selecting a node in this tree will show the corresponding WSDL definition in the panel below.
Editing or defining an imported WSDL is not currently. When a node representing an imported WSDL is selected the panel will be in read only mode.
Details of the selected WSDL are shown in 3 different views – Basic, Advanced and WSDL. However, web service can be configured using Basic and Advanced views only based on the expertise of the user.
This view is recommended for users who do not have a good knowledge of WSDL. In this view, web service definition can be created with the knowledge of input, output and fault type (if any). The SOAP bindings and other necessary elements for WSDL are created automatically when an operation is added in this view.
The web service definition can be configured by selecting the nodes in the tree on the left side as shown in figure 4. When a node is selected in the tree the panel corresponding to its configuration is shown in the right side pane.
Figure 4: Definition Configuration
This field is used to specify the name of the service.
This field is used to specify the target namespace of the WSDL that is generated. Note when target namespace is changed an entry corresponding to its prefix must be added in the namespace prefix table.
This field is used to provide the location from which the relative paths of imported WSDLs used in the selected WSDL will be resolved. By default it is populated with the location where the WSDL is present. It should be edited to the correct location if required.
If Save Imports is selected, this location should be accessible from the Peer Server on which the component will be launched.
This table is used to assign prefixes to all namespaces that are used in the WSDL.
The schemas which are necessary for defining the web services can be added in the view corresponding to the Types node.
Figure 5: Types Configuration
The schema content can be loaded either from a file or manually by clicking
the
button and then saving the content.
The schemas that are added will be shown in the table as shown in the figure 5. When a schema is added its target namespace and imported namespaces will be added to the WSDL with an auto generated prefix. Imported/included schemas if any have to be added to the schema repository.
In basic view, an operation can be added by selecting the option Add Operation from the context menu of the Operations node as shown in figure 6.
Figure 6: Basic Operation configuration
When an operation is added in basic view, the port type, binding, binding operation, Input and Output messages will be automatically created with prefix Auto_Created_. On deleting the operation from the basic view all corresponding elements which are no longer referenced will be deleted based on the input from the user.
The input and output and fault type/element must be specified using
the dialog which gets opened when the ellipsis
corresponding
to input is clicked.
Figure 7: Type/Element Selection
The tree shows the types and elements present in the schemas and their imports as shown in figure 7. The types are shown as children of Types node and any elements present will be shown under Elements node. The table cell corresponding to the types dialog is editable and is populated as follows.
When a type or element is selected, the cell will be populated with QName of the element/type prefixed by Type : or Element : respectively.
The QName can be given as {namespace}localpart manually. If there is no prefix attached then the QName will be assumed to be that of an element.
This view is recommended for users who have fair understanding of creation of WSDL. In this view it is possible to configure all the elements of the WSDL. The tree in the advanced view shows much detailed view of the elements of the WSDL. The configuration of a particular element can be done by selecting the node which shows corresponding panel in the right side pane. For detailed information about elements of a WSDL please refer http://www.w3.org/TR/wsdl.
This is same as the one shown in the Basic view.
This is same as the one shown in the Basic view.
The messages for the web service can be added by selecting the option Add Message from the context menu which appears on right clicking on the Messages node. This will add a message node as a child node of the messages node. On selecting the added node, the panel as shown in figure 8 is displayed in the right side pane.
Figure 8: Message Configuration
The name attribute of the message can be specified here. It provides a unique name among all messages defined within the enclosing WSDL document.
Messages consist of one or more logical parts. Each part is associated with a type from some type system using a message-typing attribute. Parts for the message can be added by using the add button in the table. The type/element for the part can be selected using the types dialog shown in the figure 7.
The port types for the web service can be added by selecting the option Add Port type from the context menu which appears on right clicking on the Port Types node. This will add a port type node as a child node of the Port Types node. On selecting the added node, the panel as shown in figure 9 is displayed in the right side pane.
Figure 9: Port Type configuration
The name attribute of the port type can be specified here. It provides a unique name among all port types defined within the enclosing WSDL document.
Operations can be added to a port by selecting the option Add Operation from the context menu which appears on right clicking on the added port type node as shown in figure 10
Figure 10: Adding Operation
This will add an operation node as a child node of the added port type node. On selecting the added node, the panel as shown in figure 11 is displayed in the right side pane.
Figure 11: Advanced Operation Configuration
The name attribute of the operation can be specified here. This need not be unique among the operations defined.
For RPC bindings, the parameter order can be specified using this field.
The value is a list of message part names separated by a single space. It MUST follow the following rules:
The part name order reflects the order of the parameters in the RPC signature
The return value part is not present in the list
o If a part name appears in both the input and output message, it is an in/out parameter
o If a part name appears in only the input message, it is an in parameter
o If a part name appears in only the output message, it is an out parameter
Input tab
Name
The name of the input can be specified using this field. This name along with operation name and operation’s output name uniquely identifies an operation within the enclosing port type..
Message
Input message can be selected from the combo box. It is recommended that the messages are added prior to configuring the operation.
Output tab
Name
The name of the output can be specified using this field. This name along with operation name and operation’s input name uniquely identifies an operation within the enclosing port type.
Message
Output message can be selected from the combo box. It is recommended that the messages are added prior to configuring the operation.
Faults tab
Figure 12: Adding faults to operation
Multiple faults can be added by using the table shown in figure 12. The message corresponding to the fault can be selected from the drop down.
The bindings for the web service can be added by selecting the option Add Binding from the context menu which appears on right clicking on the Bindings node. This will add a binding node as a child node of the Bindings node. On selecting the added node, the panel as shown in figure 13 is displayed in the right side pane.
Note : Port Types must be present in the definition or imported WSDLs before defining bindings
Figure 13: Binding configuration
The name attribute of the binding can be specified here. It provides a unique name among all bindings defined within the enclosing WSDL document.
The port type corresponding to this binding can be selected from the drop down list.
Figure 14: SOAP Binding configuration for binding
The SOAP binding information of the binding can be specified by selecting the tab SOAP binding as shown in the figure 14.
The value of the required transport attribute indicates which transport of SOAP this binding corresponds to.
The value of the style attribute is the default for the style attribute for each contained operation.
Binding operations can be added to a port by selecting the option Add Binding Operation from the context menu which appears on right clicking on the added binding node as shown in figure 15
Figure 15: Adding binding operation
This will add binding operation node as a child node of the added binding node. On selecting the added node, the panel as shown in figure 16 is displayed in the right side pane
Note: Port Type corresponding to this binding must have operations defined for defining binding operation.
Figure 16: Binding operation configuration
The various details of binding operation can be specified by selecting the tabs as explained below.
Operation tab
Name
The name of the operation to which this binding operation corresponds can be selected from the drop down.
SOAP Binding
This information corresponds to the attributes for the soap:operation element that will be added to the binding operation element.
SOAP Action
The soapAction attribute specifies the value of the SOAPAction header for this operation.
Style
The style attribute indicates whether the operation is RPC-oriented (messages containing parameters and return values) or document-oriented (message containing document(s))
Input tab
The input tab can be used to specify the binding input information as shown in figure 17.
Figure 17: Binding input Configuration
Input name
The name of the input for the binding operation can be specified here. This along with operation name and the output name uniquely identifies the operation to which the binding operation corresponds to.
SOAP Binding
The binding (body and headers) information can be configured here.
Body tab
This tab can be used to configure the attributes of the soap:body element.
Namespace
This can be used to specify the namespace corresponding to the SOAP body. This namespace should not be present in the namespaces defined in the definitions panel.
Parts
The optional parts attribute indicates which parts appear somewhere within the SOAP Body portion of the message. If the parts attribute is omitted, then all parts defined by the message are assumed to be included in the SOAP Body portion.
Use
The use attribute indicates whether the message parts are encoded using some encoding rules, or whether the parts define the concrete schema of the message.
Encoding Styles
The value of the encodingStyle attribute is a list of URIs. The URIs can be added using the table as shown in figure 17. The URI represents encodings used within the message, in order from most restrictive to least restrictive.
Headers Tab
SOAP header corresponding to the input/output can be specified by adding them to the table as shown in the figure 18.
Figure 18: Adding SOAP Headers
The SOAP Headers can be configured by clicking on the ellipsis
which opens the panel as shown in figure 19.
Figure 19: SOAP Header configuration
Namespace
This can be used to specify the namespace corresponding to the SOAP body. This namespace should not be present in the namespaces defined in the definitions panel.
Message
The message and the part reference the message part that defines the header type. The referenced message need not be the same as the message that defines the SOAP Body.
Part
The message and the part reference the message part that defines the header type. The schema referenced by the part MAY include definitions for the soap:actor and soap:mustUnderstand attributes if use="literal", but MUST NOT if use="encoded".
Use
The use attribute indicates whether the message part is encoded using some encoding rules, or whether the part defines the concrete schema of the message.
Encoding Styles
The value of the encodingStyle attribute is a list of URIs. The URIs can be added using the table as shown in figure 19. The URI represents encodings used within the message, in order from most restrictive to least restrictive
Header Faults
The Header faults corresponding to a header can be defined by selecting
the tab header Fault and adding an entry in the table SOAP Header Faults
table. The SOAP Header fault can be configured by clicking on the ellipsis
as shown in figure 20.
Figure 20: SOAP Header fault configuration
The header fault elements allows specification of the header type(s) that are used to transmit error information pertaining to the header defined by the soap:header. The attributes namespace, message, part, use and encoding styles are similar to those defined for SOAP Header.
Output tab
The output tab can be used to specify the binding output information as shown in figure 21.
Figure 21: Binding Output configuration
Output name
The name of the output for the binding operation can be specified here. This along with operation name and the input name uniquely identifies the operation to which the binding operation corresponds to.
SOAP Binding
The SOAP binding information for the binding output can be configured similar to Binding input explained in the previous sections.
Faults tab
The binding information for faults can be defined by adding entry in
the table and clicking on the ellipsis
which opens
dialog as shown in 22.
Figure 22: Faults configuration
Fault Name
The name attribute of the fault element can be specified here.
SOAP Binding
Fault Name
The name attribute for soap:fault element. This is not editable and is same as the fault name.
Namespace
This can be used to specify the namespace corresponding to the SOAP body. This namespace should not be present in the namespaces defined in the definitions panel.
Use
The use attribute indicates whether the message parts are encoded using some encoding rules, or whether the parts define the concrete schema of the message.
Encoding Styles
The value of the encodingStyle attribute is a list of URIs. The URIs can be added using the table as shown in figure 22. The URI represents encodings used within the message, in order from most restrictive to least restrictive.
The service for the web service can be added by selecting the option Add Service from the context menu which appears on right clicking on the Services node. This will add a service node as a child node of the services node. On selecting the added node, the panel as shown in figure 23 is displayed in the right side pane. Only one service per instance is supported now.
Figure 23: Service and ports configuration
The name of the service can be specified here. The service name must be unique for WSStub instances configured on same peer server.
A port defines an individual endpoint by specifying a single address for a binding.
The name attribute of the port can be specified here. It provides a unique name among all ports defined within the enclosing WSDL document.
The binding corresponding to port can be specified from the combo box.
The SOAP address binding is used to give a port an address (a URI). The URI scheme specified for the address must correspond to the transport specified by the soap:binding.
This is a read only view of the WSDL that is generated from the configuration done using basic/advanced views.
Figure 24: WSDL view
The errors pane is present at the bottom of all the panels. When a node is selected and configured. The validations are done when switching to other node/view. In this case any validation errors are shown in the error pane. User can navigate to other node only if the configuration is valid. In any case if the configuration is not possible without switching, thee node that is being configured has to be deleted.
All elements of WSDL can define context specific documentation. This
can be defined by clicking on the ellipsis
against
the property Documentation which opens the editor shown in figure below.
The input must be a well formed XML element.
This page is used to define WS Standards like WS-Addressing, WS-Reliable Messaging and WS-Security.
Figure 26: WS Request Security
Order of actions
The order of a security function determines when this function will
be applied when multiple security functions are being used. The order
of the actions can be increased and decreased by using the
and
respectively. To enable an action/security
function the check box against it must be selected. In figure 26 Username
Token and Timestamp functions are enabled and the Username Token action
will be applied followed by Timestamp action.
The different actions and the properties to be set for using them are explained below.
Username Token
Determines whether the server should perform Username token identification or not.
Password Callback Class
This is needed by the security functions to get the password and to verify the username/password pair. The password callback class should implement org.apache.ws.security.WSPasswordCallback class. This Password Callback class should be the fully qualified name of the class. The jar which contains the password callback class must be placed in '%FIORANO_HOME%\esb\server\jetty\fps\webapps\bcwsgateway\WEB-INF\lib'.
Timestamp
Determines whether the soap request has timestamp in security header or not. In this case, the message is valid up to 5 minutes or 300 seconds after the creation of the message.
Timestamp Precision in MilliSeconds
If this is set, timestamps will have precision in milliseconds. Otherwise it will be seconds.
Encrypt
Determines whether the soap request (or some parts of it) is encrypted or not.
Encryption Properties File Name
The name of the crypto property file to use for decryption of the soap request. If this parameter is not specified and if both the "Signature Properties filename" and "Signature" are set to yes, then the decryption function uses signature property file. Otherwise the handler throws an AxisFault. The properties file must be placed in '%FIORANO_HOME%\esb\server\jetty\fps\webapps\bcwsgateway\WEB-INF\classes'
An example of a properties file content:
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.file=C:\\Documents and Settings\\Fiorano\\Desktop\\fiorano.ks
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=fioranopass
org.apache.ws.security.crypto.merlin.keystore.alias=fiorano
org.apache.ws.security.crypto.merlin.alias.password=fioranopass
The properties descriptions:
org.apache.ws.security.crypto.provider: Implementation class for security provider. Fiorano internally uses bouncycastle, to use the same this property must be set to "org.apache.ws.security.components.crypto.Merlin". To use other providers, the provider jar must be placed in '%FIORANO_HOME%\esb\server\jetty\fps\webapps\bcwsgateway\WEB-INF\lib' and fully qualified name of appropriate provider class has to be set for this property.
org.apache.ws.security.crypto.merlin.file: The path to the keystore file.
org.apache.ws.security.crypto.merlin.keystore.type: The keystore type, for example JKS for the Java key store. Other keystore type, such as pkcs12 are also possible but depend on the actual Crypto implementation.
org.apache.ws.security.crypto.merlin.keystore.password: The password to read the keystore. If this property is not set, then the pwcallbackproperty must be defined.
org.apache.ws.security.crypto.merlin.keystore.alias: The alias name under which the private key/certificate stored in keystore
org.apache.ws.security.crypto.merlin.alias.password: Password for private key/certificate inside keystore stored under given alias (not used for encryption)
Signature
Determines whether the soap request (or some parts of it) is signed or not.
Signature Properties File Name
The name of the crypto property file to use for SOAP Signature. Please see the description of "Encryption Properties filename" for the details of the properties file.
SAML
Determines whether the server should perform SAML Token identification or not.
Signed SAML
If Signed SAML is used at client side for request, then the client performs two actions inserting a SAML Token (unsigned) and an associated Signature. So define both the actions SAML Unsigned and Signature here to resolve these security headers.
Figure 27: WS Response security
Order of actions
The order of a security function determines when this function will
be applied when multiple security functions are being used. The order
of the actions can be increased and decreased by using the
and
respectively. To enable an action/security
function the check box against it must be selected. In the figure 27 Username
Token, Timestamp and encrypt functions are enabled and they will be applied
in the same order.
The different actions and the properties to be set for using them are explained below.
Username Token
Determines whether the server should perform Username Token Identification on response or not. If this property is set, the response from server contains Username and Password security headers.
User
This property is used as username for the UsernameToken security function. It is also used as the alias name in the keystore to get user's certificate or private key to perform signing for the Signature security function. It is also used as the fallback for the encryption security function in case of "Encryption User" is not specified and "Encryption" in response is enabled.
Password Callback Class
This is needed by the security functions to get the password and to verify the username/password pair. The password callback class should implement org.apache.ws.security.WSPasswordCallback class. This Password Callback class should be the fully qualified name of the class. The jar which contains the password callback class must be placed in '%FIORANO_HOME%\esb\server\jetty\fps\webapps\bcwsgateway\WEB-INF\lib'.
Password Type
Password type: The Password type can be either PasswordText or PasswordDigest
PasswordText
Password is sent in raw text format with in the security header of the soap response.
PasswordDigest
Password is sent in digest format with in the security header of the soap response.
Nonce Security Element
Specifies whether to use nonce element in the security header or not. When UsernameToken security function is used, then nonce security element can be employed to prevent message replay attacks. A nonce is a random value that the client creates to include in each UsernameToken that it sends. Although using a nonce is an effective countermeasure against replay attacks, it requires server to maintain a cache of used nonce’s, consuming server resources.
Created Security Element
Specifies whether to use Created element in the security header or not. This element denotes the time of creation of a nonce. Combining a nonce with a creation timestamp has the advantage of allowing a server to limit the cache of nonce’s to a "freshness" time period, establishing an upper bound on resource requirements.
Timestamp
Specifies whether the soap response from server should contain timestamp header or not.
Timestamp Precision in MilliSeconds
If this is set, timestamps will have precision in milliseconds. Otherwise it will be seconds.
Encrypt
Determines whether the server should encrypt the soap response (or some parts of it) or not.
Encryption User
Username for the encryption function. The encryption function uses the public key of this user's certificate. If this parameter is not set, then the encryption function falls back to the "User" parameter to get the certificate. The encrypt function will not authenticate user. So there is no need to set any password call back class for encrypt.
Encryption Properties File
The name of the crypto property file to use for SOAP Encryption in response. If this parameter is not specified and if both "Signature Properties filename" and "Signature" in response are set, then the encryption function uses signature property file. Otherwise the handler throws an AxisFault. The properties file must be placed in '%FIORANO_HOME%\esb\server\jetty\fps\webapps\bcwsgateway\WEB-INF\classes'. Please see the description of "Encryption Properties filename" in request security for the details of the crypto properties file.
Encryption Parts
Parameter specifies which parts of the response shall be encrypted. The value of this parameter is a list of semi-colon separated element names that identify the elements to encrypt. An encryption mode specifies and a namespace identification, each inside a pair of curly brackets, may precede each element name. The encryption mode is either {Content} or {Element}. 'Element' encryption mode will encrypt the entire element including start and end tags. 'Content' encrypt mode will encrypt only the content of the specified element. The default encryption mode is 'Content'.
For example if we set "{Element}{http://example.org/paymentv2}CreditCard;{}{}UserName" list to this property, then the first entry of the list identifies the element CreditCard in the namespace http://example.org/paymentv2, and will encrypt the entire element. In the second entry the encryption modifier and the namespace identifier are omitted. In this case the encryption mode defaults to Content and the namespace is set to the SOAP namespace.
The element name, the namespace identifier, and the encryption modifier are case sensitive. To specify an element without a namespace use the string Null as the namespace name (this is a case sensitive string). If no list is specified, the handler encrypts the SOAP Body in Content mode by default.
Encryption Key Identifier
Select the key identifier type to use.
DirectReference
The security function takes the signing certificate, converts it to a BinarySecurityToken, puts it in the security header. Thus the whole signing certificate is transferred.
X509KeyIdentifier
The encryption method uses the public key associated with this certificate to encrypt the symmetric key used to encrypt data. The certificate is converted into a KeyIdentifier token and sent to the server. Thus the complete certificate data is transferred.
SKIKeyIdentifier
The security function uses SKIKeyIdentifier.
IssuerSerial
The encryption method uses the public key associated with this certificate to encrypt the symmetric key used to encrypt data. The issuer name and the serial number of the signing certificate are sent to the server.
Signature
Determines whether the soap response (or some parts of it) should be signed or not.
Signature Properties File
The name of the crypto property file to use for SOAP Signature. Please see the description of "Encryption Properties filename" for the details of the properties file.
Signature Parts
Parameter specifies which parts of the request shall be signed. Please see the description of "Encryption Parts" for the syntax.
Signature Key Identifier
Select the key identifier type to use. Please see the description of "Encryption Key Identifier" for the descriptions of key identifiers.
SAML
Determines whether the server should perform SAML Token Identification or not.
Signed SAML
Specifies whether to use signed SAML or unsigned SAML. If Signed SAML is used, then server performs two actions inserting a SAML Token (unsigned) and an associated Signature. So define both the actions SAML Unsigned and Signature at client side to resolve these security headers. If Signed SAML is used, the signature properties should be specified in this panel with out selecting the property "Signature WS-Security".
SAML Properties File
The name of the SAML properties file. This file must be placed in '%FIORANO_HOME%\esb\server\jetty\fps\webapps\bcwsgateway\WEB-INF\lib'.
An example of properties file content:
org.apache.ws.security.saml.issuerClass=org.apache.ws.security.saml.SAMLIssuerImpl
org.apache.ws.security.saml.issuer.cryptoProp.file=crypto_wsc.properties
org.apache.ws.security.saml.issuer.key.name=fiorano
org.apache.ws.security.saml.issuer.key.password=fioranopass
org.apache.ws.security.saml.issuer=fiorano
org.apache.ws.security.saml.subjectNameId.name=uid=mule,ou=people,ou=saml-demo,o=example.com
org.apache.ws.security.saml.subjectNameId.qualifier=www.example.com
org.apache.ws.security.saml.authenticationMethod=password
#org.apache.ws.security.saml.confirmationMethod=senderVouches
org.apache.ws.security.saml.confirmationMethod=keyHolder
Figure 28: SSL Configuration
Use SSL
Select this option to enable SSL Settings. Rest of the properties in this editor are enabled and configurable only when this property is checked.
Accept Server Certificate
When accessing https URLs, this property determines whether the server certificates should be accepted or not. If selected, the certificate will be accepted without any validation, otherwise exception is sent to ON_EXCEPTION port.
Ignore Hostname Mismatch
If this option is selected the certificate will be accepted even if hostname in the certificate does not match with the hostname in the request URL. If its not selected exception is thrown.
Protocol Handler Packages
Determines protocol handler packages property.
Security Protocol
Determines Security protocol
Security Provider Class
Determines Security provider class.
Key Manager Factory Type
Algorithm for the Key Manager Factory.
Key Store Type
Type of the Key Store whose location is specified by Key Store Location should be specified in the fileld.
Key Store Location
Location of the key store file can be provided using the file dialog
that opens up on clicking the ellipsis. The KeyStore is
used by the component for client authentication.
Key Store Password
Password of the specified key store can be specified in the field.
Key Store Client Key
Determines Key Store Client Key
Trust Manager Factory Type
Algorithm for the Trust Manager Factory.
Trust Store Location
Location of the trust store file should be specified. TrustStore is a file where digital certificates of trusted sites are stored and retrieved for authentication during an SSL connection. TrustStore is used to authenticate a server in SSL authentication.
Trust Store Type
Type of Trust Store whose location is specified by property Trust Store Location.
Trust Store Password
Password of the specified trust store should be specified in the field.
Figure 29: HTTP Authentication
Use HTTP Authentication
HTTP authentication support for the Web Services can be provided by selecting this property.
Type
The type of HTTP Authentication can be selected for the drop down. At present only BASIC authentication is supported.
Username
Username to be used by the WSStub component while deploying the Web Service. The entry for this user name has to be present in Realm.properties file. If this user name is not present, the component will not launch.
Password
Password to be used by the WSStub component while deploying the Web Service. If this password is not present in Realm.properties file the component will not launch.
Using Basic Authentication
Before enabling this property in WSStub, basic authentication has to be enabled in FPS Jetty Server and in bcwsgateway web application (FIORANO_HOME/esb/server/jetty/fps/webapps/bcwsgateway). Procedure to enable basic authentication in Jetty Server and in the web app is explained below.
1. Enabling Basic Authentication in Jetty Server
2. Stop the FPS Server if it is running.
3. Open FPS profile in Fiorano Studio and navigate to FPSàFioranoàEsbàJetty.
4. Select the Jetty mbean. In the properties window, set the property Basic Authentication to yes and give the fully qualified path of Realm.properties file against the property Realm Properties. More information on Realms and Realm.properties file content is discussed in the next section.
5. Save the profile.
Figure 30: Enabling Basic Authentication in FPS Jetty server
Enabling Basic Authentication in webapp
1. Open Web.xml file located at FIORANO_HOME/esb/server/jetty/fps/webapps/bcwsgateway/WEB-INF.
2. Uncomment the security-constraint and login-config elements and save the file.
3. Delete the Peer Server cached profile from FES runtime by deleting the folder FIORANO_HOME/runtimedata/EnterpriseServers/<Profile Name>/FES/peers/<peer profile>.
4. Start the FPS server.
The basic authentication is enabled in FPS Jetty Server and in the webapp. Now the authentication can be enabled in WSStub by setting the value of Enable authentication property to yes. Provide a set of username and password which is present in Realm.properties file.
Note: To confirm the authentication, when the WSStub component is launched right-click the component and select View WDSL option. Web browser prompts the user to enter the username and password to display the WSDL.
When the authentication is enabled in WSStub, client can access the Web Service only if it uses the basic authentication with correct credentials.
UserName
Username to be used by the WSStub component while deploying the Web Service. The entry for this user name has to be present in Realm.properties file. If this user name is not present, the component will not launch.
Password
Password to be used by the WSStub component while deploying the Web Service. If this password is not present in Realm.properties file the component will not launch.
Security realms allow securing the web applications against unauthorized access. Protection is based on authentication (identifying who is requesting access to the webapp) and access control (restricting what can be accessed and how it is accessed within the webapp).
A webapp statically declares its security requirements in the web.xml file. Authentication is controlled by the <login-config> element. Access controls are specified by <security-constraint> and <security-role-ref> elements. When a request is received, the web container checks if the user performing the request is authenticated and if the user has a role assignment that permits access to the requested resource. Access to the resource is allowed only when the user is authorized and has the required permissions.
A realm has a unique name, and is composed of a set of users. Each user has authentication information (Example: a password) and a set of roles associated.
More than one realm can be configured depending on the needs.
Fiorano uses a simple realm whose authentication and authorization information is stored in a properties file. Each line in the file contains a username, a password, and 0 (zero) or more role assignments. The format is:
username: password[,rolename ...]
where:
username is the user's unique identity
password is the user's password
rolename is the user's role
Sample content of Realm.properties file is shown below:
admin: admin,admin
user: password,user
guest: guest,read-only
Figure 31: FES Connection Configuration
FES URL
The URL of Enterprise Server to which the Peer Server on which the component is running is connected.
Username
User name that should be used to connect to the enterprise server.
Password
Password that should be used to connect to the enterprise server.
FES Backup URL
The alternate URL that should be tried for connecting to the Enterprise Server if the Enterprise Server cannot be connected to using the URL mentioned against property FES URL.
Note: In case of Enterprise Servers in HA mode, this should point to Secondary Server URL if the primary is set against Server URL property and vice-versa.
Figure 32: Execution Configuration
Execution Timeout
WSStub component receives client request on its output port and sends the request message to the connected components. After the processing is completed by the connected components response message is sent to WSStub input port and from there it will be sent to the client.
WSStub component accepts the response if it reaches before the timeout period. If no response is received, on timeout Error message will be sent to the client saying No message received till the timeout period.
Note: Request will be processed by the connected components in the Event Process even after the timeout but the response is not sent back to the client by WSStub.
Execution Timeout of 0 indicates infinite timeout.
Request Timeout
This value is set as Time to live property on the request message. The request message will be discarded after the timeout.
0 indicates infinite time.
The ports will be generated based on the configuration of WSDefinition as follows
For each operation which has SOAP binding defined request, response and error ports will be generated.
The name of the ports will be prefixed by the type of SOAP binding i.e., SOAP11 or SOAP12.
The prefix is followed by _<operation name>_ and the type of port.
Example:
For an operation with name operationName and SOAP11 binding, ports with following names will be generated
Output port with name SOAP11_operationName_REQUEST
Input port with name SOAP11_operationName_RESPONSE
Input port with name SOAP11_operationName_FAILURE
Figure 33: Scenario demonstration
Figure 33 demonstrates how WSStub can be used to deploy the Event Process as Web Service.
In the flow, WSStub is connected to an SMTP component. WSStub component sends the client requests to SMTP and gets the SMTP response which is sent back to the client. An operation is added in basic view and its input part type is set as root element of SMTP component’s input port schema, output part type is set as root element of SMTP component’s output port schema and a fault part is added and its part type is set as root element of error port schema of SMTP component.
When the Event Process is launched, it gets deployed as Web Service with service name and added operation name specified in the CPS. On right-clicking and selecting view wsdl, the user can view the wsdl for this WSStub in a web browser.
A WebserviceConsumer component can be configured to invoke this Web Service by providing the URL of this wsdl (in the Managed Connection Factory panel of WS consumer's CPS) and by selecting the Web Service Operation (In Interaction Configuration Panel).
Sample request and response to WebserviceConsumer component which accesses the deployed Web Service is shown below.
Figure 34: Sample Request
Figure 35: Sample Response
For SSL to work properly the JDK version used should be greater than 1.5.0_08 and the jars present in JDK_HOME/jre/lib/ext should be copied to $FIORANO_HOME/esb/lib/ext.
When WSStub component is configured to launch on HA (High Availability) Peer Servers
o If both Primary and Secondary Servers are on the same machine
Initially, if WSStub is launched on the Primary Server, the generated WSDL URL contains Primary Server’s jetty port number. In case of Primary Server failover, the Secondary Server becomes Active and relaunches the component. WSDL will be regenerated and if the Secondary Server uses a different jetty port then the WSDL URL is changed. The clients have to be reconfigured to use new URL in this case.
To avoid this situation, it is recommended to use same jetty ports for both Primary and Secondary Peer Servers.
Jetty service will be started only after the server is started successfully. In case of HA, only one server will be active at a given time and the Jetty Server will be running only in the active server and there will be no bind exceptions even if both the servers use same port number for Jetty.
o If both Primary and Secondary servers are on different machines
In this case if the failover happens the hostname/IP address in the WSDL URL will be changed. So the clients have to be reconfigured accordingly.
HTTP headers are received from the gateway as message properties with the header name prefixed with http_. For example, http_Content-Type.
The service name must be unique for WSStub instances configured on same peer server.
WSStub instances that are configured previously can be used as they were without opening the CPS. However, if the WSStub instance is reconfigured then there will be following changes
o Port names are changed
This would result in the routes leading to and from the component to disappear on closing the CPS.
o Schemas on ports are changed
This would mean that the already defined transformations are no longer valid and will have to be redefined.
So it is recommended to save the transformations defined on the route externally and redefine the transformations after the component is configured.
o Web Service name changed
The webservice name will be the context name appended with suffix "Service" for the old WSStub components. If we deploy the same WSStub with out any configuration changes, then the web service name will be context name itself. No suffix will be appended. This will result to reconfigure the Web service consumer components configured to use this service should be reconfigured to fetch the service name.
Copyright © 2008-2010, Fiorano Software Pte. Ltd. and affiliates.
All rights reserved.
This software is the confidential and proprietary information of Fiorano Software ("Confidential Information"). You shall not disclose such Confidential Information and shall use it only in accordance with the terms of the license agreement enclosed with this product or entered into with Fiorano.