About Third-Party Compliance
With this solution, IM and Presence Service integrates with one or more third-party compliance servers for compliance logging or ethical wall functionality. The IM and Presence Service administrator can select which IM, presence, or group chat events are passed to the compliance server(s), and which events are blocked. The events must be selected based on policy. For example, the system could be configured to filter IMs between certain users, or groups of users, and block or modify content depending on the originator and recipient of the IMs.
To use the third-party compliance solution you must configure the third-party compliance server(s) for your cluster. IM and Presence Service passes all configured events that are generated in the processing of user login, logout, presence sharing, IM exchange, or group chat activity to the third-party server(s). The third-party compliance server applies any relevant policy or filtering to the event, then instructs IM and Presence Service as to whether the event should be processed further. Note that you may potentially experience performance delays in your network because of the volume of events that pass between IM and Presence Service and the third-party compliance server. If IM and Presence Service loses its connection to the third-party server, all IM traffic stops.
Third-party compliance requires these components:
-
IM and Presence Service - IM and Presence Service uses the Event Broker component to send events to the third-party compliance server.
-
Third-party compliance server - All IM and Presence Service nodes in the cluster will redirect events to the configured compliance server(s) unless you are upgrading from a system with compliance already configured.
-
IM Client - Supported clients include Cisco clients such as Cisco Jabber, third-party XMPP clients, and other third-party clients used in federated networks.
Note |
IM and Presence Service does not provide a secure TLS/SSL connection between IM and Presence Service and the third-party compliance server. |
The following figure highlights the third-party compliance components and message flow.
Compliance Profiles
A compliance profile contains a set of Jabber Session Manager (JSM) and\or Text Conferencing (TC) events that you can use to monitor for compliance. You can create a compliance profile that consists of only JSM events, only TC events, or a combination of both JSM and TC events.
When you configure a compliance profile, choose which JSM and TC events you wish to be logged to the compliance server. You can also decide what type of handling is performed by the compliance server, how IM and Presence Service handles error responses from the compliance server, and whether the IM and Presence Service node waits for a response from the compliance server before processing the event further. You can also configure how the events should be processed if no response is expected.
The following tables describe the JSM events and parameters.
Caution |
If a combination of Bounce, and Fire and Forget is selected, an event to which this applies will be passed to the compliance server and then discarded. This means it will not be processed further by IM and Presence Service. Use this combination with care. |
Event | Description |
---|---|
e_SESSION |
Packets sent during login, which is the creation of a new session. |
e_OFFLINE |
Packets sent to users who are offline. Offline users are users who do not have an active session. |
e_SERVER |
Packets sent directly to the server for internal handling. |
e_DELIVER |
The first event for packets coming in from another server; the second event for packets coming in from a user on the same server. (The first event for packets coming in from the same server is es_IN.) |
e_AUTH |
IQ packets sent during authentication. |
e_REGISTER |
Packets generated during registration of a new account by a user. |
e_STATS |
Packets sent periodically that contain server statistics. |
e_DISCOFEAT |
Triggered when a user sends a disco#info query. |
e_PRISESSION |
Determines a user's primary or default session when the user has more than one session. An EventBroker component may dictate the choice of a user's primary session. |
es_IN |
Generated when a stanza is about to be received by a user's session. |
es_OUT |
Generated when a stanza is sent from a user's session. |
es_END |
Packets generated when a user logs out. |
Parameter | Description |
---|---|
Packet Type |
Select one
of the following XMPP packet types:
|
Handling |
Select bounce if errors returned from the compliance server should be bounced back to the originating party or component Select pass if they should be discarded. |
Fire and Forget |
Leave the check box unchecked if the IM and Presence Service node must wait for a response from the compliance server before it continues to process the event. Check the check box if the IM and Presence Service node does not require a response from the compliance server before it continues to process the event further. |
The following tables describe the TC events and parameters.
Caution |
If a combination of Bounce, and Fire and Forget is selected, an event to which this applies will be passed to the compliance server and then discarded. This means it will not be processed further by IM and Presence Service. Use this combination with care. |
Event | Description |
---|---|
onServicePacket |
The system receives a packet from the router that is either addressed directly to the TC service or to a room that does not currently exist on the system. |
onBeforeRoomCreate |
A gear is attempting to create a room on the system. |
onAfterRoomCreate |
A room has been successfully created on the system. The only valid response is PASS with no modification to the original stanza. |
onServiceDiscoInfo |
An entity has sent a disco#info packet to the TC service. The only valid response is PASS. |
onServiceReconfig |
The TC service receives a signal to reconfigure itself. The only valid response is PASS. This is a notification event only. The XDB packet will be of a type="set". The external component should not respond to this packet. |
onDestroy |
A room owner closes a room. The only valid response is PASS. |
onClose |
A gear requests to close a room. |
onPacket |
A new XML stanza is directed at a room, or participant within a room. |
onMetaInfoGet |
Room configuration information is available. The only valid response is PASS. |
onBeforeMetaInfoSet |
A room configuration is about to be modified by a user. |
onAfterMetaInfoSet |
A room configuration has been modified by a user. The only valid response is PASS with nothing in it. |
onExamineRoom |
A Jabber entity requests information, either by browse or disco, from a room. The only valid response is PASS. |
onBeforeChangeUser |
A change has been requested of a user role, nickname, or presence. This includes on entry, exit, nick change, availability change, or any role change (granting or revoking voice, moderator privilege). |
onAfterChangeUser |
A user has changed. The only valid response is PASS with nothing in it. |
onBeforeChangeAffiliation |
A user affiliation is about to change. |
onAfterChangeAffiliation |
A user affiliation has changed. The only valid response is PASS with nothing in it. |
onBeforeRemoveAffiliation |
A user affiliation is about to be removed. |
onAfterRemoveAffiliation |
A user affiliation has been removed. The only valid response is PASS with no modification to the original stanza. |
onBeforeJoin |
A user is about to join a room. |
onAfterJoin |
A user has joined a room. The only valid response is PASS with nothing in it. |
onLeave |
A user has left a room. The only valid response is PASS. |
onBeforeSubject |
A room subject is about to change. |
onAfterSubject |
A room subject has changed. The only valid response is PASS with nothing in it. |
onBeforeInvite |
A user is about to be invited to a room. |
onAfterInvite |
A user has been invited to a room. The only valid response is PASS with nothing in it. |
onHistory |
A room's history has been requested. The only valid response is PASS. |
onBeforeSend |
A message is about to be sent in a room. |
onBeforeBroadcast |
A message is about to be broadcast in a room. |
Parameter | Description |
---|---|
Handling |
Select bounce if errors returned from the compliance server should be bounced back to the originating party or component Select pass if they should be discarded. |
Fire and Forget |
Leave the check box unchecked if the IM and Presence Service node must wait for a response from the compliance server before it continues to process the event. Check the check box if the IM and Presence Service node does not require a response from the compliance server before it continues to process the event further. |
If the same compliance profile is assigned to more than one compliance server, events are load balanced across each of the compliance servers. This reduces the load on individual compliance servers. Events are routed using an algorithm that ensures that related events are routed to the same compliance server. For one to one IMs, events are routed based on the combination of the to/from address, regardless of the packet's direction. This means that the full conversation between two users is routed to one compliance server. For group chat, events for a given chat room are routed using the chat room address, so that all events for a room are routed to one compliance server.
A system default profile is available in the system after fresh install or upgrade. This profile is called SystemDefaultComplianceProfile and cannot be deleted or modified. You can assign and unassign this profile as with any other.
The SystemDefaultComplianceProfile profile has four JSM and five TC events configured. If this profile is assigned, when any of its events occur in an IM and Presence Service cluster, they are passed on to the compliance server for handling, and a response is expected. The IM and Presence Service node handles the events based on the response from the compliance server. These events are previewed in read-only format if the SystemDefaultComplianceProfile is selected from the list of available compliance profiles.
JSM Events | TC Events |
---|---|
e_SESSION |
onBeforeInvite |
es_END |
onBeforeJoin |
es_IN (for message stanzas only) |
onBeforeRoomCreate |
es_OUT (for message stanzas only) |
onBeforeSend |
onLeave |
If the same event(s) are configured in multiple profiles and these profiles are assigned to different third-party compliance servers, the events are handled in order as specified by routing priority. By default, routing priority of all profiles is defined by the order in which the profiles were added to the system. The routing priority can be re-configured.
Compliance Profiles Routing Priority
You can configure routing priority when there is more than one compliance profile assigned and some or all of the events from one profile exist in the other profile(s). If each compliance profile has different events configured, routing priority is not applicable.
The default routing priority of the profiles configured in the system is the order in which they were configured.
Example
The following is an example of when you would use compliance profiles routing priority:
You have a compliance profile configured for events subject to Ethical Wall scrutiny, and another for the same events subject to IM logging. Each is assigned to a different compliance server. If you want the events subject to Ethical Wall scrutiny to be routed to the Ethical Wall server before being logged in the IM logging server, you must assign the Ethical Wall compliance profile the higher priority.