The SecureFlow Manager

The SecureFlow Manager is an implementation of a filter. The SecureFlow Manager is only required in some quite specific cases, as described below.

Note: The technical documentation (often) uses the word 'filter' when referring to the SecureFlow Manager; as the filter can be used to implement a number of functions other than bypassing the back end.

Note: If you want to secure your resources without using the SecureFlow Manager see Managing Restricted Resources without the SecureFlow Manager.

If your web site uses only static resources then you do not need the SecureFlow Manager. Even if your site is login-protected, as long as there is no need (during a visitor-engagement session) to access either dynamic resources or protected resources then you do not need the SecureFlow Manager.

If, however, you have any resources at all that are protected or dynamically generated then you will need the SecureFlow Manager. There are associated advantages to using the SecureFlow Manager but the technical requirement rests solely on the nature of the resources that will be accessed during visitor-engagement sessions.

Note: If, for whatever reason, you do not wish to use the SecureFlow Manager but still need to protect some online assets, there may be workarounds. See Managing Restricted Resources without the SecureFlow Manager (filter) to find out if there is an appropriate workaround for your particular case.

Note: The SecureFlow Manager is not required if you are sure you will never need to view session-specific data/images during a co-browsing session. This seems simple enough but it can be tricky to discern whether you will need the SecureFlow Manager for session-specific resources. Make sure you are aware of what is ‘session-specific’ and what is not. In general, all personal or customer-specific data, especially in graphical form, is session-specific. See Session-Specific Content.

The nature of your use cases will determine whether you will need the SecureFlow Manager or not. For example, if you have a public web site (with no login requirement) and all resources are open and available to all visitors then the SecureFlow Manager is not required. This is the simplest case; with no protected resources nor any dynamically generated content to worry about the Agent can see what the visitor sees. However, it should be borne in mind that such a use case strongly implies a site with a lot of traffic. So, while the SecureFlow Manager would not be required to perform the technical machinations that enable the Agent to see potentially sensitive information or access protected resources, the bandwidth efficiencies might make the SecureFlow Manager an attractive option (as the SecureFlow Manager would only inject the code snippet when a co-browsing session is started).

Note: Even if your site is login-protected, as long as you are sure that all of the resources across all visitor-engagement activity are static then you would not need the SecureFlow Manager.

As use cases become more complex we must assume that there will be personal or sensitive data that will be shared during a session. For example, loans, mortgages, credit cards; everything that constitutes retail banking, can only be handled with static resources up to a point. That is; one might be able to engage with visitors, help them, direct them to offers or deals or other information that builds relationships, but when you need to actually do some business with visitors then you may need the SecureFlow Manager.

For example, as we move up the ‘engagement hierarchy’ to investment banking or trade finance or mergers and acquisitions the complex engagement requirements themselves define your technical requirements. There are many complex activities that can still be performed without the SecureFlow Manager. For example, your analysts can share charts or offer market insight to investors or your economists can outline their recommendations and strategies using static resources. Essentially, if you want to use unblu to do marketing and general relationship management, using static resources, you would not need the SecureFlow Manager. You will need the SecureFlow Manager if you intend to make transactions such as completing contracts or selling services; any engagement that requires your agents to share personal or sensitive information that must be protected will require the SecureFlow Manager.

Using the SecureFlow Manager can massively lower your web infrastructure requirements by dynamically injecting the snippet only when you need it. Co-browsing will account for only a fraction of your website traffic so, if you have a lot of traffic, it makes sense if only the required JavaScript files are loaded at the right time.

The decision on when to inject what is rule based. The rules are the main configuration element of the SecureFlow Manager. The Collaboration Server provides a JSON-based configuration, including rules and injection advice for the filter.

To deploy the SecureFlow Manager see: Installing the SecureFlow Manager (Filter) and Configuring Apache 2 Example.htm.

The core purposes of the Filter are:

  1. Resource Histories

  2. Dynamic snippet injection

  3. Session-Specific Resources

  4. Automatic uploads for document co-browsing

DOM Capturing

Installing the SecureFlow Manager (Filter)

Filter Specification

Managing Restricted Resources without the SecureFlow Manager (filter)

  • deployonprem

results matching ""

    No results matching ""