Securing InterChange Server

The WebSphere Business Integration system is a distributed system with critical business data that needs to be secured. Unauthorized parties need to be prevented from viewing or modifying the data while it is in transit or when it is stored on disk. Securing data in any system includes three security services, authentication, message integrity, and privacy. Authentication involves verifying that someone is who they claim to be. Authentication governs access control which restricts access to parts of the system based on who the authenticated user is and what permissions the user has been granted. Message integrity ensures that the data has not been modified. Privacy ensures that only authorized users can view data. Integrity, privacy and authentication can be accomplished with encryption, while RBAC can be accomplished by setting up user IDs and passwords.

Encryption

Besides the three security services, there are three security mechanisms that are involved with securing InterChange Server. Two of the mechanisms involve encoding data through encryption. They are symmetric encryption and asymmetric encryption. Symmetric encryption involves encoding data using an encryption algorithm, or key. The same key, is used to encode the data and decode the data. In a distributed system, where one process has to encrypt the data and another process has to decrypt the data, the key needs to be securely shared or exchanged, so that unauthorized users cannot use the key to access the data. The ability to share a key can also be a challenging task in symmetric encryption.

The mechanism of asymmetric encryption is commonly used to share or exchange a key. It involves encrypting data and decrypting data using a key pair. One key in the key pair is a private key that is kept secret, and the other key in the key pair is a public key that is shared and distributed to others. Data encrypted with a public key can only be decrypted by the corresponding private key in the key pair. The sender encrypts the data using the public key of the receiver, so that only the appropriate receiver can decrypt the data using its own private key. Since asymmetric encryption is that it is slow, it is not used to encrypt data. Instead, it is used to asymmetrically encrypt and decrypt the secret key, which in turn is used to symmetrically encrypt the data. This process affords the best mix of security and speed because it is the strength of the key that is more important in maintaining privacy within a system.

The private key can also be used to create a digital signature for the data, which can be used to verify the identity of the sender (authentication) and the integrity of the data sent (message integrity). To create a digital signature, the data is a small size fixed-length message digest in a process called hashing, which is a one-way function that creates a map or message digest. The message digest is encrypted with the sender's private key, which creates the digital signature. The digital signature is appended to the data, and sent to the receiver. The receiver decrypts the digital signature back into the message digest using the public key, which verifies the signature, since the public key can only decrypt data encrypted with the private key, which only the sender has. Then the receiver hashes the data to create a message digest, and compares it with the message digest that was sent. If both message digests are the same, the receiver can verify that the data has not been changed since it was signed by the sender.

To secure critical business data, InterChange Server includes the following security features:

End-to-end privacy

Adapter processes and InterChange Server communicate by sending messages. Messages are bidirectional, so that both InterChange Server and the adapter processes send messages and receive messages. SSL offers node-to-node, or link level security. Messages can be secured as they travel between nodes, but not when they are stored to disk at a node. The messages and data are in the clear, where they can be viewed and modified by unauthorized users. End-to-end privacy can secure the messages as they flow starting at the node of origin, through any intermediate nodes, to the destination node. Using asymmetric and dynamic security, messages are secured in transit and are secured as they are stored when they are at queue managers on disk, awaiting processing. Messages are secured with varying levels of security, which can include encryption and end point authentication. End point authentication occurs when the end points in the communication, such as InterChange Server or an adapter, prove they are who they claim to be by using digital signatures.

Asymmetric and dynamic security

In a distributed system, communicating parties can be both senders and receivers. When the communication needs to be secured, and the security levels are the same for incoming and outgoing messages, it is considered symmetric security. This type of security creates a tight coupling between the server and an adapter. SSL represents a form of symmetric security.

Many third party security products are based on the Secure Sockets Layer (SSL) security protocol. SSL provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. SSL is usually associated with tightly coupled systems that use symmetric security, so all data is encrypted whether the data is critical or not. SSL cannot tell non-secure data from secure data. If the security levels between incoming and outgoing messages can be different, it is considered asymmetric security. For example, suppose a user needs to authenticate with a server, using a user ID and password, before receiving a large document from the server. The user ID and password need to be encrypted, so that they cannot be viewed in transit by an unauthorized user, but the document does not need to be encrypted when in transit. Using SSL, both the user ID and password and the large document are encrypted. Encrypting the large document can impact the performance of the server.

Using asymmetric security, the message flow from the user can be set to encrypt the user ID and password, but the message flow from the server to the user can be set so it is not encrypted. The user ID and password from the user are protected by encryption, while server performance is enhanced because the large document is not encrypted before it is sent to the user. Asymmetric security also enables dynamic updates to security parameters between communicating parties. Using asymmetric security, such as SSL, security parameters are established when the communication starts. Changes to security parameters are not in effect until a new communications session begins. Using asymmetric security, changes to the security parameters can be dynamic because the communicating parties have individual security parameter definitions. A change to the security parameters for one party does not interrupt the current security session and require an update to other parties. While asymmetric security can provide flexibility, its weakness is that it directly couples with end nodes leaving the loosely or indirectly coupled middle nodes vulnerable to data to manipulation by unauthorized sources.

Using end-to-end privacy, security can be set at the application layer in order to secure messages before they enter and leave an application. This type of security eliminates the danger of unauthorized sources accessing messages while residing on middle nodes. End-to-end privacy also provides a way that different message types can have different levels of security.

Levels of security

The level of security is configured for each message type, for individual adapters and InterChange Server. There are four levels of security:

None
No security level is set, so messages are sent from an adapter or InterChange Server as normal. This is the default level of security.

Integrity
The sender, either an adapter or InterChange Server, adds a digital signature to the message. The receiver verifies the signature using the public key of the sender. The receiver is authenticating the sender by verifying the signature, since only the sender has access to its own private key, and could use it to generate the signature. The signature is a message digest of the data, so when the receiver creates a message digest and verifies that the message digest matches the message digest sent with the message, the message integrity is guaranteed. Integrity also implies authentication, since in the process of verifying that the data has not changed, the identity of the sender is verified.

Privacy
The sender completely encrypts the message. The receiver decrypts the message and passes it on for further processing. When an adapter or InterChange Server sends a message with Privacy configured, it generates a secret key; encrypts the message with the secret key; encrypts the secret key with the receiver's public key; includes the encrypted secret key with the message; then sends the message. The receiver decrypts the secret key, using its own private key; decrypts the message using the decrypted secret key; and forwards the message for further processing.

The secret key is encrypted with the public key of the receiver. The encrypted secret key can be decrypted only with the private key of the receiver, so the message is secure because only the receiver has access to its own private key.

Integrity plus Privacy
The sender adds a digital signature to each message, as described in Integrity, and then completely encrypts the message, as described in Privacy.

InterChange Server and the adapters maintain their own keystores. A keystore is a password protected file used to securely store public and private keys. InterChange Server maintains a keystore that contains its own public and private key pair, and the public keys of all installed adapters. An individual adapter maintains a keystore that contains its own public and private key pair, the public key of InterChange Server and the public keys of all the processes to which it communicates.

Combinations of the levels of security and the types of messages to secure are possible, for individual adapters and InterChange Server. For example, Integrity can be configured for administrative messages from InterChange Server, while Privacy can be configured for business object messages from the SAP adapter, and no security can be set from the e-mail adapter.

Message types

There are four types of messages, coming from an adapter or InterChnage Server, that can be secured:

All messages (All)
All messages from an adapter or InterChange Server are secured.

Administrative messages (Admin)
All administrative messages from an adapter or InterChange Server are secured.

All Business Objects (BO)
All business object messages from an adapter or InterChange Server are secured.

Individual Business Object (BO specification name)
Specific business object messages from an adapter or InterChange Server are secured by specifying the name of the business object specification to be secured.

To secure messages using end-to-end privacy, an administrator needs to determine what type of messages to secure, what level of security is required, and then configure both InterChange Server and individual adapters. When end-to-end privacy is configured for InterChange Server, it only applies to messages sent from InterChange Server. When end-to-end privacy is configured for an individual adapter, it only applies to messages sent from the individual adapter. All existing events must be removed from the system before turning on end-to-end privacy. Existing events will not be processed correctly when end-to-end privacy is configured. For more information concerning configuring end-to-end privacy, see the System Administration Guide.

Role-based access control

To prevent unauthorized users from accessing any system, user IDs and passwords address a basic security requirement. A user ID is issued to a user, who is an individual or a process that wants to access the system. Authenticating a user does not mean that they should have access to all parts of the system. There might be critical or sensitive parts of the system that should only be accessed by select users, while other parts of the system can be accessible to all users. Access control refers to restricting access to parts of the system based on who the authenticated user is and what permissions the user has been granted. Individual users can be granted permission to access various components, but managing permissions in this way can be time consuming for administrators. Role-based access control authenticates users who want to access InterChange Server, then limits the access the user has to individual components based on what role the user has been assigned.

Roles

A role is a collection of one or more users that have some functional association. Assigning permissions based on roles reduces the administrative burden significantly. For each operation that needs to be secured, the administrator defines roles that are allowed to perform the operation. Only users that are members of the permitted roles are allowed to perform the operation. When permissions are assigned to roles, the role permissions are referred to as the security policy for the role. Users can be assigned to multiple roles.

An operation or an action is not secured if no roles are assigned to it, and every authenticated user can perform the action. Users are only allowed to perform an action that is secured if the user has been assigned to a role that has been granted access to the action.

A predefined role of administrator has been included with InterChange Server as a default role. Members of the administrator role have permission to perform all operations on the server, including creating users, creating roles and granting permissions to roles. The administrator has the ability to create additional roles that better reflect the organizational structure. For example, an organization may have several developer roles such as Finance Developers or Redevelopers to restrict access to the components developed by the different groups. Users can belong to multiple roles. Default roles cannot be deleted.

An administrator can query the system for users who are currently logged in to the system. A user can be logged in to a maximum of 20 sessions at one time. The administrator can logout the particular session of any user that is currently logged in. The administrator can also logout all the open sessions of a user, so that if a user has forgotten to logout, the administrator can logout for the user. An exception is thrown when a user tries to log in and already has 20 open sessions. An administrator can also reset a user's password.

A guest user has been predefined as a default user, and assigned a password of guest. Default users cannot be deleted. There is no limit to the number of sessions that guest can log into.

InterChange Server administrator can import or export security policies, which are the permissions assigned to components, as security.xml. Role definitions and role membership information can be exported to and imported from a file, from the System Manager and from the command line tool repos_copy by a user with the appropriate role. The file is named RoleMembership.xml. Users and passwords can be exported to and imported from a binary file, which can be imported to another server. Exporting passwords is a security risk. The file should be exported to a directory that is secured by the operating system security and should be deleted after it is imported.

The default security policy is that only a user in the administrator role can start, stop, administer security, export config files and deploy config files in InterChange Server. The default permissions for a new component are that all actions can be performed by an authenticated user. A component is not secured by default.

Role-based access control is not automatically configured during InterChange Server installation. To configure role-based access control, refer to the System Administration Guide. Before turning on role-based access control, at least one user must be added to the administrator role. If InterChange Server uses a repository implementation, a user needs to be created to add to the administrator role. If role-based access control has been turned on and the server is started without at least one user in the administrator role, the server logs an error message and starts with role-based access control turned off. A user ID and password are not required to start the server, and all users have access to all operations. When role-based access control is turned on, a user ID and password are required to start the server and all permissions or access checks are functional.

Auditing

Auditing allows administrators to track who performed secure operations, such as logging in, logging out, and administering users, roles and permissions. Auditing data that is collected includes the date and time, user ID, operation performed and status of the operation, such as success, access denied or an exception occurred. The audit log is not written to the usual Interchangesystem.log file. It is written to a separate file in the your_ics_dir_name/log/audit directory, which is not secure. The audit log file contains information that should be secured by the operating system, so that unauthorized users cannot view the files. The size of the log file and the frequency with which new log files are created can be configured. The name of the file depends on how often a new log files needs to be created, after the log file exceeds the file size settings. Frequency options include daily, weekly and monthly. The default value is weekly. The format of the audit log file name is

    Daily file: icsaudit_yyyymmmdd_nnn.log
    Weekly file: icsaudit_yyyymmmwx_nnn.log
        Where x = 1,2,3.... Week numbers
    Monthly file : icsaudit_yyyymmm_nnn.log

where yyyy is the year, mmm is the month, dd is the day, wx is the week number and nnn = 001......999, when multiple files need to be created in a period because the log file size setting has been exceeded. The operations that can be audited include:

User Registry

The user registry is the system that stores usernames and passwords. By default, users and passwords are stored in the local WBI repository. The userRegistry configuration parameter can be used to configure InterChange Server to use a Lightweight Directory Access Protocol (LDAP) directory as a user registry. The LDAP is a protocol for accessing enterprise directory services. Enterprise directories are used to store information that can be shared across several applications. For example, user information that may be required by all enterprise applications may include username, password and email address. If this data is stored in the proprietary database of each individual application, the data is duplicated, and it is difficult to be kept synchronized. When a new employee joins the company, a user ID and password have to be created for the employee in each application. However, with a directory service, the user ID and password only need to be created once in the directory, and enterprise applications can reuse that information.

The provider is set to LDAP to use an LDAP directory for the user repository, while it is set to REPOS to use the local WBI repository as the user registry. When the WBI repository is used for storing users and passwords, it is strongly recommended that a separate database be used for this. The URL for the database that hosts the user registry can be specified. This is a hierarchical property called USER_REGISTRY in the configuration file interchangesystem.cfg. The structure is identical to the existing REPOSITORY property such that a databaseURL, username and password can be specified. The property can be edited using the server configuration tool. It is recommended that there be one user registry per enterprise, whether using LDAP or a WBI database, so that multiple instances of InterChange Server can share the same user registry without importing and exporting users and passwords. InterChange Server can use the username and password from an LDAP directory, using the InetOrgPerson schema as described in RFC 2798. The InetOrgPerson schema has Object Identifier (OID) 2.16.840.1.113730.3.2.2, which are numbers assigned by IETF that uniquely identify each schema. InterChange Server makes no assumption on the directory tree structure within the directory. Users can specify a base distinguished name (baseDN) as part of configuration for both users and role. This baseDN is used as the root for any searches or updates.

Securing components and actions

The list of components that can be secured, along with securable actions, includes:

Table 2. Securable components

Securable components Securable Actions
InterChange Server
  • Start
  • Shutdown
  • Security - administering roles and users
  • Monitor
  • View failed events
  • MMS - Deploy
  • MMS - Export
  • MMS - Delete
  • MMS - Compile
  • MMS - Export config files
  • MMS - Deploy config files

Collaboration objects
  • Start
  • Stop
  • Pause
  • Shutdown
  • Execute (Access Framework call)
  • Resolve transactional status
  • Submit failed events
  • Delete failed events
  • Cancel LLBP flow

Connectors
  • Start
  • Stop
  • Pause
  • Shutdown agent
  • Submit failed flow
  • Delete failed flow

Maps
  • Start
  • Stop

Relationships
  • Start
  • Stop

Benchmarks
  • Start
  • Stop

Copyright IBM Corp. 1997, 2004