Providers

In this section:

A provider is a centrally configured resource that supplies services to run time components in the server. For example, a keystore provider centralizes the definition of one security keystore, including its type, file location, and password. Each configured provider has a name. Using that name the services of the provider can be referenced in other parts of the server.

One provider can refer to another provider. The SSL provider, as an example, requires a keystore and a trust store. Each of these is a keystore of some type, so instead of configuring all of the details of the keystore, the configuration simply asks for the name of the keystore provider(s) in charge of the keystore and trust store.

Often, several providers can supply the same service, although in different ways. For example, in a secure system a certificate can be stored in a keystore or in an LDAP directory. A Certificate Revocation List (CRL) can be stored in a file system directory or in an LDAP directory. Simply specifying the name of the provider to be used to access the certificate or the CRL is all that is needed when configuring for a need. This simplifies server configuration.

A provider describes a resource available at run time, while the users of the provider are configured in the design time experience; a deployed usage is tied to the run time physical implementation only by its name. For example, a configuration requiring a certificate store can be deployed on servers having completely different storage for its certificates.

Please note that the term providers is used on several levels. While the providers available in iWay Service Manager offer services to other iWay components, providers can also refer to software that is installed into the Java Virtual Machine (JVM) that provides services to application programs. These JVM providers must also be configured.


Top of page

x
Data Provider

The Data Provider option enables you to define and configure data servers and connections. The data provider properties include:



x
Procedure: How to Add a JDBC Connection

To add a JDBC connection:

  1. In the left console pane of the Server menu, select Data Provider.
  2. Beneath the JDBC section, click Add.

    The JDBC Data Provider Definition pane displays.

  3. Provide the appropriate values for your JDBC connection as listed and defined in the following table.

    Parameter

    Description

    JDBC Connection Pool Properties

    Name *

    Enter the name of the JDBC data provider to add.

    Driver Class

    The JDBC driver class is the name of the class that contains the code for this JDBC Driver. You can select a predefined database from the drop-down list or enter your own.

    The following are sample values for the driver:

    com.microsoft.jdbc.sqlserver.SQLServerDriver
    COM.ibm.db2.jdbc.app.DB2Driver
    com.informix.jdbc.IfxDriver
    sun.jdbc.odbc.JdbcOdbcDriver
    oracle.jdbc.driver.OracleDriver
    com.sybase.jdbc2.jdbc.SybDriver

    The required .jar files for the JDBC driver must be installed and registered in the Service Manager classpath. You can use the Path Settings option on the console to add Java classes and libraries.

    Connection URL

    The JDBC connection URL to use when creating a connection to the target database. The URL generally includes the server name or IP address, the port or service, the data source name, and a driver specific prefix. You can select a predefined database from the drop-down list or enter your own.

    The following are sample values for the URL:

    jdbc:microsoft:sqlserver://server:1433;DatabaseName=DB
    jdbc:db2:database 
    jdbc:informix-sqli://HOST:PORT/DB:INFORMIXSERVER=SERVER_NAME
    jdbc:odbc:DBjdbc:oracle:thin:@HOST:PORT:SIDjdbc:sybase:Tds:HOST:PORT

    For more information, see the JDBC documentation for the specific data source.

    User

    User name with respect to the JDBC URL and driver.

    Password

    Password with respect to the JDBC URL and driver.

    Connection Pool Properties

    Initial Pool Size *

    Number of connections to place in the pool at startup.

    Maximum Number of Idle Connections *

    Maximum number of idle connections to retain in the pool. 0 means no limit except what is enforced by the maximum number of connections in the pool.

    Maximum Number of Connections *

    Maximum number of connections in the pool. 0 means no limit.

    Login Timeout

    Time in seconds to wait for a pooled connection before throwing an exception. 0 means wait forever.

    Behavior When Exhausted

    What to do when the pool reaches the maximum number of connections. Block means wait for a connection to become available for the period defined by the login timeout parameter. Fail means throw an exception immediately.

    Validation SQL

    SQL statement that can be executed to validate the health of a pooled connection. The statement should return a result set of at least one row.

    Validate on Borrow

    If set to true, the validation SQL statement will be executed on a pooled connection before returning the connection to the caller.

    Validate on Return

    If set to true, the validation SQL statement will be executed on a pooled connection before replacing the connection in the pool.

  4. Click Test to check for proper connections.

    If a connection cannot be made, an error message displays describing the problem. Typically, the driver has not been installed or the classpath has not been set.

  5. Click Add to return to the Data Provider pane.


x
Procedure: How to Add a JLINK Data Source

To add a JLINK data source:

  1. In the left console pane of the Server menu, select Data Provider.
  2. Beneath the JLINK section, click Add.

    The JLink pane displays.

  3. In the Name field, type the name of a new server. In this example, type NEWSERV.
  4. In the Description field, type a brief description for the new server. The default is JLINK Data Provider.
  5. From the Type drop-down list, select a JLINK server type.

    The default is WebFOCUS Pro Server.

  6. Type the required values for Host and Port.
  7. Type the required values for User and Password.
  8. From the Engine drop-down list, select a database engine.

    The default is 0 (EDA).

  9. From the Encoding drop-down list, select a codepage.

    The default value is 137 (U.S. English).

  10. To encrypt data that is transported over the wire (optional), select the Encryption check box.
  11. In the Trace File field, type the path and name of the file for the trace output.
  12. To set trace levels, select any number of the check boxes listed (optional).
  13. Click Add.

Top of page

x
Services Provider

iWay Service Manager can quickly and easily expose iWay Business Services as Web Services through the iWay Business Services Provider (iBSP).

iWay Business Services Provider is installed with an embedded HSQL repository, which is the default data store for information that is generated during design time and then published into a deployed run-time environment. HSQL is an open source Java based SQL relational database engine and includes a JDBC driver.

iBSP uses defined services providers to integrate with available data repositories. If a repository is not defined, the default HSQL repository is assumed by iWay Service Manager.

A repository migration facility is also included, which provides portability for your existing metadata and iWay Business Services. For example, you can migrate your data between development, testing, and production environments across multiple systems. For more information, see Migrating Repositories.

The settings in the Services Provider pane refer to the configuration of the iWay Business Services Provider in the base configuration of the server.



x
Procedure: How to Configure Services Provider Settings

The Services Provider pane enables you to define properties required to support iWay business services as Web Services.

To configure for a Web service:

  1. In the left console pane of the Server menu, select Services Provider.

    The Services Provider pane opens, as shown in the following image.

  2. From the Data Store Type drop-down list, select a repository you want to configure.

    The following are available:

    • Embedded Database (no data provider required)
    • File System (no data provider required)
    • IBM DB2
    • MaxDB
    • Microsoft SQL Server
    • Oracle
    • Sybase

    You must configure the tables before using the repository. For more information on configuring repository tables, see the iWay Installation and Configuration Guide.

    Note: iWay Service Manager is installed with an embedded HSQL repository, which is the default data store for information that is generated during design time and then published into a deployed runtime environment.

    For more information on the properties on this window, see the table in Services Provider Settings.

  3. From the Data Provider Name drop-down list, select an available data provider.

    For more information on how to add a data provider, see How to Add a Data Provider.

  4. Type new values or modify existing values.
  5. Click Update.


x
Reference: Services Provider Settings

The following table lists and describes the Services Provider settings.

Property

Type/Value

Description

Data Store Type

Choice

Acts as a metadata repository. The default value is Embedded Database. Select a database from the drop-down list: File System (not supported for production use), IBM DB2, MaxDB, Microsoft SQL Server, Oracle, and Sybase.

Data Provider Name

String

JDBC driver defined in the Data Provider pane. Select from the drop-down list, or click Add to define a new JDBC connection.

Connection Pooling

Boolean

When selected, turns on connection pooling for the JDBC driver.

Publishing Location

Directory

Directory where the WSDL files produced by the iWay Business Services Provider (iBSP) are stored. If the directory does not exist, select the check box to create the named directory.

Adapter Library

Directory

Directory where the iWay adapter JAR files are located. If the directory does not exist, select the check box to create the named directory.

Policy Based Security

Boolean

When selected, enforces iBSP security policy. For more information, see the iWay Business Services Provider User's Guide.



x
Procedure: How to Add a Data Provider

To add a data provider:

  1. Click Add in the Data Provider Name section.

    The Data Provider - JDBC pane opens.

  2. Enter a name for the JDBC data provider.
  3. From the Driver Class drop-down list, select the JDBC class for the data provider.

    You can also manually enter the name.

  4. From the Connection URL drop-down list, select the connection URL to use when creating a connection to the target database.

    You can also manually enter the URL.

  5. Enter the user ID to access the repository database.
  6. Enter the password to access the repository database.
  7. Click Test.

    You should receive a response that says:

    The JDBC data provider test completed successfully.

    If you receive an error, troubleshoot accordingly. Ensure the driver is in the iWay60\lib directory. For more information, see the iWay Installation and Configuration Guide.

  8. Click Update if the test is successful.

    You connection appears on the Data Provider pane. If you need to change its parameters, you can click the name of the connection.

    If you need to define both the target and source repositories, repeat this procedure to define another repository.



x
Migrating Repositories

You can migrate repositories using the iWay Service Manager Administration Console. These repositories can be for iWay Service Manager, the older iWay Adapter Manager, Servlet iBSP, or iWay Connector for JCA. The structure of the repository has not changed.

Some of the things you can migrate include:

Note: Monitoring tables are not migrated.

In this section:



x
Migration Steps

The following steps are required to migrate a repository:

  1. Ensure you have created the new repository tables. For more information, see the iWay Installation and Configuration Guide.
  2. Ensure the JDBC driver for your target and source repositories are in the iWay60\lib directory. For more information, see the iWay Installation and Configuration Guide.
  3. Define the source and target repositories as Data Providers using the iWay Service Manager Administration Console as explained in How to Add a Data Provider.
  4. Start the migration as explained in How to Migrate a Repository.


x
Procedure: How to Migrate a Repository

To migrate a repository:

  1. Click Services Provider in the left pane.

    The currently selected Data Store Type and Data Provider Name determine the source repository.

  2. Set the source repository by selecting the Data Store Type and Data Provider Name, and clicking Update.

    The Data Provider Name is the name you used when you defined the source repository.

  3. Set the target repository by selecting a repository you want to migrate, for example, Oracle, from the Data Store Type drop-down list.

  4. From the Data Provider Name drop-down list, select the name of the data provider, for example, OracleTest.

    The Repository section in the Services Provider pane refreshes, as shown in the following image.

    Notice the Migrate link next to the Data Store Type drop-down list.

  5. Click Migrate.

    The Services Provider - Data Store Migration pane opens.

    The table that is provided is divided into two sections:

    • Migration Source - Displays the current repository that is being used.
    • Migration Destination - Displays the destination repository to which you are migrating.
  6. Review and verify all the information to make sure it is correct.

    Note: To perform a clean migration, you can select the On check box in the Reset/Clean Destination area to delete all data that is currently in the destination repository before proceeding.

  7. Click Migrate.

    Information about the migration process appears. Ensure there are no critical errors.

    After the migration completes, iWay Business Services Provider is still set to use the source repository. You must set it to use the destination repository instead.

  8. Click Services Provider on the left.
  9. Select the type of repository you wish to use from the Data Store Type drop-down list.
  10. Select the connection you just defined from the Data Provider Name drop-down list.
  11. Restart iWay Service Manager for your changes to take effect.

Top of page

x
Directory Provider

Directory providers offer access to hierarchical maps of information. A directory might be a point in a file system or a registry of information, such as Microsoft's Active Directory. The directory providers offer access to information in a directory for some purpose. For example, an LDAP provider offers generalized access to a directory that responds to the LDAP protocol, while other providers offer directory access for more specific purposes.

For clarity, purpose-specific directory providers appear on the iWay Service Manager Administration Console under their purpose.



x
LDAP Directory Providers

A directory is a set of information with similar attributes organized in a logical and hierarchical manner. The protocol accesses LDAP directories, regardless of the form of the directory itself. LDAP sees the directory in a standard manner.

A DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a unique key (called a UUID) may be provided in the set of the entry's operational attributes.

iWay provides a simple access function to supply the value of a single LDAP attribute for use as a configuration parameter. The following function accesses the information in the directory:

_LDAP( filter, attribute, context [,providername])

For example: _LDAP("cn=John Doe",mail,'dc=example') might return the mailing address for John.

LDAP providers may also be used to hold certificates for security operations.



x
LDAP Directory Provider as a Certificate Store Provider

An LDAP system can also be used to hold certificates for security operations. A configured directory provider pointing to an LDAP system can be used in the configuration of the components that support a certificate store, such as AS2. A certificate store, also called a certstore, is a database of public key certificates and certificate revocation lists. An LDAP server used as a CertStone must support anonymous access.

The structure within the LDAP must follow the RFC2587 specifications to store the certificate information. The directory provider configuration screen provides a test facility. This simply verifies that the specified LDAP URL can be used to access the directory. It does not validate security or other attributes of the directory.



x
Procedure: How to Define a Directory Provider

To define a directory provider:

  1. In the left console pane of the Server menu, select Directory Provider.

    The Directory Provider pane opens.

  2. Click New in the Defined LDAP Providers section.

    The Directory Providers: LDAP pane opens.

  3. Provide the appropriate values for your LDAP connection parameters as listed and defined in the following table.

    Parameter

    Description

    Name *

    Enter the name of the directory server definition to add.

    Description

    Enter a description of the use of this directory server.

    LDAP Initial Context Factory

    Fully qualified class name of the LDAP Initial Context Factory, default is com.sun.jndi.ldap.LdapCtxFactory

    URL *

    URL to reach LDAP directory. LDAP URLs are in the form: ldap://host[:port] or ldaps://host[:port]

    Pool Size

    A pool of connections to the LDAP server reduces contention but increases memory use. iWay suggests a range of 2-10 for a normally loaded system.

    Authentication Mechanism

    Specifies the authentication mechanism to use. Select Not Specified to use the JNDI default. If the User ID and Password are absent, the default is none, otherwise the default is simple. When using an LDAPS URL, the default is always simple. You can also type a space separated list of mechanisms to try in order of preference.

    Authentication Realm

    For some SASL authentication mechanisms, this is the domain from which the user ID should be chosen. If you do not specify a realm, then any one of the realms offered by the server will be used.

    User ID

    User ID registered for appropriate access to this LDAP directory.

    Password

    Password for access to the LDAP directory.

    SSL Context Provider

    iWay Security Provider for SSL Context. This parameter is required when using an ldaps: URL. When an SSL Context is given with an ldap: URL, this will upgrade the normal LDAP connection to one protected by TLS/SSL using the LDAP StartTLS extension.

    Quality of Protection

    Some SASL mechanisms support integrity and privacy protection of the communication channel after successful authentication. Choose Not Specified to rely on the JNDI default.

    Encryption Strength

    Some SASL mechanisms support different ciphers and key lengths used for encryption.

    Referrals

    Specifies how JNDI referrals are handled.

    Dereferencing Aliases

    Specifies how aliases are handled.

  4. Click Test to test the connection to the LDAP provider.
  5. Click Add when you are finished.

    You are returned to the main Directory Provider pane and the new LDAP directory provider that was defined is added to the list.

  6. To define multiple directory providers, repeat this procedure.

    A defined directory provider can be used as a named provider during the configuration of supporting components such as AS2.



x
Security Provider

A cryptographic system requires a mechanism for the storage and use of cryptographic information. For more information on iSM security and security providers, see the iWay Service Manager Security Guide.

A keystore is a collection of keys and certificates. There are two types of keystore entries:

Entries in a keystore are referred to by their "alias", which is a simple unique string.

A truststore is a keystore used to hold the certificate of trusted Certificate Authorities.

A system may need to use a variety of keystores for different purposes. iWay Service Manager identifies named keystore providers, each of which represents one keystore and the appropriate access credentials and algorithms needed to access that keystore's information. The keystore provider is identified by name to other components of the system that require access to the security information, such as AS2 or HTTP inlets.



x
Definition References

A keystore is a database of key material. Key material is used for a variety of purposes, including authentication and data integrity. There are various types of keystores available, including "PKCS12" and Sun's "JKS." Some keystores can contain both encryption keys and security certificates. Formally, however, a keystore holds the private key for one or more PKI key pairs.

A truststore is a database of key material. It holds the public certificates of trusted partners for message exchange. Although it is possible to share a single file with the keystore, more formally a truststore and a keystore are separate entities.

A certificate store, also called a certstore, is a database of public key certificates and Certificate Revocation Lists. The CRL is required to stop the use of a certificate when it would otherwise be considered valid. A CRL is not needed to tell you a certificate is bad once its expiration date is reached. In fact, CRLs are usually cleaned of expired CRLs after one complete CRL revision period has elapsed. This means the expired CRL will continue to appear in at most one CRL after it expired.

If certificate revocation is turned on, you will need one CRL for each CA in the certificate chain you want to verify. If a CRL is missing, there is no way to know whether certificates issued by that Certificate AUthority are still valid. Therefore, all certificates issued by this CA will be considered revoked. A CRL that contains no certificates is acceptable. It belongs to a Certificate Authority that did not revoke any certificates.



x
Directory CertStore Providers

CertStore providers define the directories from which certificates and CRLs can be loaded. A configured Directory Certstore provider can be used as a named provider in the components that support CRL checking for messages.



x
LDAP CertStore Providers

The following section describes LDAP certstore providers.



x
Adding Debug Information for Certstore

If you encounter issues running the LDAP Certstore provider, you may wish to enable additional debugging. You can add the system property -Djava.security.debug=certpath to trace what the Sun CertStores and CertPathBuilder are doing. This will show you more information regarding the way certificates are being loaded and used.



x
Sun PKIX CertPathBuilder

The Sun PKIX CertPathBuilder takes the RFC2587 literally and demands that certificates in the reverse field of the crossCertificatePair be a CA. In particular, it demands that a BasicConstraints extension be present with maxPathLen greater or equal to 0. The End Entity certificates are stored in the crossCertificatePair. The Basic Constraints for an End Entity specifies that this certificate is not a CA and therefore the maxPathLen is -1. This breaks the Sun PKIX CertPathBuilder. As the result, if you send incomplete certificate chains to our AS2 listener, make sure you also set the PKIX JCE Provider to BC to make it work properly.



x
Procedure: How to Define a CertStore Directory Provider

To define a CertStore directory provider:

  1. In the left console pane of the Server menu, select Security Provider.

    The Security Provider pane opens.

  2. Click New in the Directory CertStore section.

    The Directory CertStore Definition pane opens.

  3. Provide the appropriate values for your Directory CertStore provider parameters as listed and defined in the following table.

    Parameter

    Description

    Name *

    Enter the name of the Directory CertStore definition to add.

    Description

    Enter a description of the use of this Directory CertStore.

    CertStore Location *

    CertStore directory location.

    Certificate Factory JCE Provider

    JCE Provider to use when creating the X.509 Certificate Factory.

    Reload Period

    Minimum time to wait before the provider checks if the directory contents was modified, hereby forcing the CertStore to be reloaded. The format is [xxh][xxm]xx[s]. Enter 0 to check the directory every time the CertStore is requested. Leave the parameter empty to never reload the CertStore.

  4. Click Add when you are finished.

    You are returned to the main Security Provider pane and the new Directory CertStore provider that was defined is added to the list.

  5. To define multiple Directory CertStore providers, repeat this procedure.

    This allows you to configure multiple CertStore directory providers where each can have a different configuration.

    A defined CertStore directory provider can be used as a named provider when configuring components such as AS2 that support certificate validation.



x
Keystore Providers

Keystores are standard repositories of security certificates that are used in encryption and operations involving digital signatures. iWay Security Provider configuration supports the creation of multiple keystores that can be used as named providers in the corresponding components, such as AS2 and HTTP. This allows the system to contain multiple types of keystores which may contain different credentials, algorithms and other configurations.



x
Procedure: How to Define a Keystore Provider

To define a keystore provider using the iWay Service Manager Administration Console:

  1. In the left console pane of the Server menu, select Security Provider.

    The Security Provider pane opens.

  2. Click New in the Keystores section.

    The Keystore Definition pane opens.

  3. Enter the parameters for the keystore and make sure to select the appropriate values from the Keystore Type and the Keystore Provider drop-down lists that will correspond to your keystore configuration.
  4. In the Callback Handler field, optionally enter the fully qualified name of a callback handler that will satisfy authentication callbacks for the keystore.

    The callback handler must satisfy the javax.security.auth.callback.CallbackHandler interface and be available in the classpath for iWay Service Manager.

  5. Click Add.

    You are returned to the main Security Provider pane and the new keystore that was defined is added to the list.

  6. To define multiple keystore providers, repeat this procedure.

    A defined keystore provider can be used as a named provider when configuring other iWay components (for example, listeners, services, emitters, and so on).


Top of page

x
SSL Context Providers

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide security and data integrity for communications over TCP/IP networks such as the Internet. These protocols allows client/server applications to communicate across a network in a manner designed to prevent eavesdropping, tampering, and message forgery. TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end. In cases in which iSM requires SSL or TLS support, the appropriate component requests the name of an SSL Context Provider.

In the typical usage, authentication is unilateral; only the server is authenticated to the end point. That means that the client is aware and sure of the identity of the server but not vice versa. These protocols also support bilateral authentication, in which both the client and the server exchange certificates and are aware of the others identity. This is common in business interactions. Identification is accomplished by the exchange of signed certifications containing the URL, name and address of the end point that sends the certificate. The certificates are in turn signed by a trusted Certificate Authority.

Once defined, an SSL Context Provider can be associated with one or more components (server such as nHTTP or client such as an nHTTP emit agent) using SSL or TLS. This is done be naming the provider in the component's configuration. The SSL Context Provider, in turn, relies on keystore and trust store providers that have been previously configured. The provider manages the connections and handshakes between end points, and attempts to optimize connection reuse where possible and consistent with communications security.

If you are configuring an SSL Context Provider to be used for server side, you will need a Keystore Provider as the source of your public certificate which will be recognized by the client. If you configure your SSL Context Provider to require client client authentication, you will need a Truststore Provider as the source of the trusted client certificates.

If you are configuring an SSL Context Provider to be used on the client side, you will need a Keystore Provider as the source of your public certificate and a TrustStore Provider as the source of the certificates of the servers to be trusted.

An SSL Context Provider requires that both be configured, even though both may not be needed. We can not tell to which use the Provider will be used. However if you are your application does not require a value in one of the other (Keystore or Truststore) the contents is not used. The format of the Keystore and Truststore must be correct.



x
Procedure: How to Define an SSL Context Provider

To define an SSL context provider using the iWay Service Manager Administration Console:

  1. In the left console pane of the Server menu, select Security Provider.

    The Security Provider pane opens.

  2. Click New in the SSL Contexts section.

    The SSL Context Provider pane opens.

  3. Enter the appropriate values for the SSL context provider parameters.

    For more information, see Parameters for SSL Context Providers.

  4. Click Add when you are finished.

    You are returned to the main Security Provider pane and the new SSL context provider that was defined is added to the list.

    Note: To activate any new security providers that have been configured, you must restart iWay Service Manager.

  5. To define multiple SSL context providers, repeat this procedure.

    A defined SSL context provider can be used as a named provider when configuring IP-based components such as AS2 and HTTP.



x
Reference: Parameters for SSL Context Providers

The following table lists and describes all of the available parameters for SSL context providers.

Parameter

Description

Name

Name for the SSL context provider.

Description

Brief description of the use of this SSL context provider.

Keystore Provider

Specified security provider to be used as a keystore for this SSL context provider. Select the available keystore provider from the drop-down list.

Truststore Provider

Specified security provider to be used as a truststore for this SSL context provider. Select the available truststore provider from the drop-down list.

Security Protocol

Drop-down list options for the supported security protocol, which include:

  • SSL - General SSL support
  • SSLv2 - Supports SSL version 2 or higher
  • SSLv3 - Supports SSL version 3
  • TLS - General TLS support
  • TLSv1 - Supports TLS version 1

SSL Context Provider

JCA provider for SSL context. Select one of the following options from the drop-down list:

  • NOT_SPECIFIED
  • SunJSSE

Server Key Alias

Alias for the key to be used to identify secure servers using this SSL context. If not supplied, the key will be selected using JSSE default behavior.

Client Key Alias

Alias for the key to be used to identify secure clients using this SSL context. If not supplied, the key will be selected using JSSE default behavior.

Session Cache Size

The maximum number of SSL sessions that will be retained in the session cache.

Session Timeout

Maximum length of time (in seconds) that an SSL session can remain in the cache.

Enable Certificate Revocation

If set to True, use the CRLs from the CertStore to check whether the signer's certificate has been revoked.

JCE PKIX Trust Manager Provider

Defines the JCE provider to construct the PKIX Trust Manager. Select one of the following values from the drop-down list:

  • NOT_SPECIFIED {NOT_SPECIFIED}
  • SunJSSE {SunJSSE}

JCE Signature Provider

Defines the JCE provider used to verify the digital certificate signatures during the handshake. Select one of the following values from the drop-down list:

  • NOT_SPECIFIED {NOT_SPECIFIED}
  • SUN {SUN}
  • SunRsaSign {SunRsaSign}
  • SunJSSE {SunJSSE}

PKIX Certificate Store

The certificate store from which certificate revocation lists are loaded.

Enabled Cipher Suites

If supplied, only cipher suites on this list will be enabled for SSL sockets or SSL engines created using this provider. Make sure that enabled cipher suites are supported by other components that are specified.

You can enter your values as comma-delimited list or use the FILE() function.

Hostname Verification

If set to True, client SSL connections using this provider will attempt to verify that the server's certificate matches its host name.



x
XML Digital Signature JCE Providers

The XML digital signature agents use the services of the XML digital signature JCE provider. This provider is a standard part of JDK 1.6 and requires no special installation instructions when running with JDK 1.6.

If you are using JDK 1.5, you must add the javax.xml.crypto.jar file to your class path. iWay Software produced this file by compiling (with JDK 1.5) the subset of JDK 1.6 sources that deal with XML digital signatures. You must also declare the provider in jre/lib/security/java.security using a line with the following form:

security.provider.N=org.jcp.xml.dsig.internal.dom.XMLDSigRI

where:

N

Is the highest provider number already present plus one.


Top of page

x
XML Namespace Map Providers

The XML namespace map provider is used to map XML namespace prefixes to the XML namespace URIs. It is also possible to declare multiple XML namespace map providers. Each provider can have any number of namespace declarations. The agents that need to know namespace prefixes have a parameter where you can enter a provider name to declare the namespaces. This can be used to allow namespace prefixes in XPATH expressions like /soapenv:Envelope/soapenv:Header/wsse:Security, or it can be used in reverse to choose which prefix to use when generating new XML content.

The following table lists a sample set of XML namespaces that can be declared with typical prefixes:

Namespace Prefix

Namespace URI

ds
http://www.w3.org/2000/09/xmldsig#
ec
http://www.w3.org/2001/10/xml-exc-c14n#
saml
urn:oasis:names:tc:SAML:1.0:assertion
soapenv
http://schemas.xmlsoap.org/soap/envelope/
wsa
http://schemas.xmlsoap.org/ws/2004/08/addressing
wsse
http://docs.oasis-open.org/wss/2004/01/oasis-20040
1-wss-wssecurity-secext-1.0.xsd
wsu
http://docs.oasis-open.org/wss/2004/01/oasis-20040
1-wss-wssecurity-utility-1.0.xsd
xsd
http://www.w3.org/2001/XMLSchema
xsi
http://www.w3.org/2001/XMLSchema-instance

You can access the XML Namespace Map Provider window in the iWay Service Manager Administration Console to construct an XML namespace map.

In this example, two XML namespace maps have been added and a third one is in the process of being defined. When you are finished, click Add Provider to make the XML namespace map available.

Once the map is complete, the following XPATH function will locate the y element in a document where the wsa namespace defined in the map matches the namespace URI for that element in the actual document:

xpath('/x/wsa:y', samplemap)

Note: It is not required for the namespace prefix in the map to match the actual namespace prefix used in the target document.



x
NHTTP Emit and HttpClient Providers

The HttpClient provider allows HTTP connections to be shared among iWay Service Manager components. An instance of the HttpClient provider represents a pool of connections. Connections in this pool can share proxy settings, local interface bindings, and, for HTTPS, a single SSL socket factory. Currently, the provider is used by the NHTTP and NAS2 emitters, as well as by the NAS2 MDN subsystem for sending asynchronous MDN messages via HTTP.



x
Procedure: How to Define NHTTP and HttpClient Providers

To define NHTTP and HttpClient providers:

  1. In the left console pane of the Server menu, select Pooling Providers.

    The Pooling Providers pane opens.

  2. Click New in the Defined HttpClient Providers section.

    The HttpClient Provider Settings pane opens.

  3. Enter the appropriate values for the HttpClient Provider parameters.
  4. Click Add when you are finished.

    You are returned to the main Pooling Providers pane and the new HttpClient Provider that was defined is added to the list.

  5. To define multiple Pooling Providers, repeat this procedure.


x
Reference: Parameters for HttpClient Providers

The following table lists and describes all of the available parameters for HttpClient providers.

Parameter

Description

Name *

Name for the HttpClient provider.

Description

Brief description of the use of this HttpClient provider.

Maximum Connections Per Host *

Defines the maximum number of simultaneous connections allowed per host. When this threshold is reached, new connections will not be accepted until current connections are closed and the total number of connections is below the limit. Leave this field blank (default) or set a value of zero to have no maximum limit of connections.

Maximum Total Number of Connections *

Defines the maximum number of simultaneous connections that are allowed overall. When this threshold is reached, new connections will not be accepted until current connections are closed and the total number of connections is below the limit. Leave this field blank (default) or set a value of zero to have no maximum limit of connections.

Connection Timeout

Maximum length of time (in milliseconds) that a request will block while waiting for a connection to become available from the pool. The value 0 means there is no timeout.

Set TCP No Delay

If set to True, disables Nagle's Algorithm on the client socket. This will result in faster line turnaround at the expense of an increased number of packets.

Proxy

If set to True, emit through a proxy server.

Proxy User ID

User ID for the proxy challenges.

Proxy Password

Password to access the proxy server.

Proxy Domain

Domain for NTLM proxy authentication.

Proxy Host

Host where the proxy can be accessed.

Proxy Port

Port where the proxy can be accessed.

SSL Context Provider

Named iWay Security provider for SSL Context. Defaults to the value assigned to the SSL Context Provider.

IP Interface Host

Local IP Interface from which the outgoing IP socket originates.

Idle Timeout

Time in seconds that an unused connection can remain in the pool. If set to 0, connections will remain in the pool indefinitely.



x
Authentication Realms

In version 6.0.1, iWay Service Manager supports pervasive use of authorization realms. Authorization Realms are used to associate Users with Roles and to control user access to resources. Realms are established by logon activities. For example, an HTTP authentication and authorization will establish a realm for the handling of the arriving traffic. The server supports establishment of named realms, each of which can be associated with a login-type operation by its name. The realm associates a user name with the associated credentials to authenticate the user, and to associate that user with named realm tokens.

Available realm types include:

The authorization name and credential, along with the roles associated with that user under that credential, define a principal which is the standard name for this identity. The current principal, including the name and credential (usually a password) and the associated roles can be examined through the iWay Functional Language (iFL) expressions. For example, a process flow can take appropriate branches depending upon whether or not the principal supports a specific role.


Top of page

x
Data Quality Providers

iWay Data Quality Center (DQC) is an essential tool for complex data quality management. iWay DQC is designed not only to evaluate, monitor, and manage data quality in different information systems, but also to prevent incorrect data from entering these systems in the first place. iWay DQC is bundled with a specific set of business rules and localized dictionaries.

iWay Data Quality Center (DQC) is integrated with iWay Service Manager (iSM) through the Data Quality Provider. This Provider is used to reference a DQC plan and to manage a pool of execution threads if required. All iSM components invoke DQC using a defined Data Quality Provider. In addition, you can configure one or more Providers, each representing a specific DQC Plan.

For more information about using iWay DQC, see the iWay Data Quality Center Getting Started documentation and iWay Data Quality Center User's Guide.


iWay Software