Posts by ncolter

    clara_kt is correct, service registration should be handled in by creating a prototype version of Application.prototype.onRegisterServices in your application.

    There are several callbacks you can expect the Application to execute:

    Application.prototype.onLoadConfiguration Executed after the Application has parsed the configuration file but before creating/populating the DxlClientConfig object that will be used to connect to the fabric.
    Application.prototype.onRegisterEventHandlers Executed after the DXL Client has connected to the fabric. Used for registering event handler callbacks for the service.
    Application.prototype.onRegisterServices Executed after the DXL Client has connected to the fabric, after onRegisterEventHandlers. Used for creating and registering services.
    Executed after the DXL Client has connected to the fabric, after onRegisterServices. Used for any behavior you wish to execute immediately after the client has connected but before running the Application.
    Application.prototype.onRun Executed after the Application has started running (after loading configuration, and connecting to the fabric).

    Here is an example a prototype function implementation for Application.prototype.onRegisterServices:

    The broker port 8883 does not need to be opened in both directions - the port only needs to be opened to allow the child broker to reach out to the parent broker.

    The child broker will always be initiating the connection to the parent broker.

    It's recommended that users who want to get started with the DXL nodes/flows available for Node-RED visit the OpenDXL Node-RED Nodes solution. The GitHub repository for that project contains a wiki and documentation that not only help with setting up the required environment, but provide samples and API information.

    Additionally, there is also the OpenDXL Node-RED Docker solution. There you will find a Docker image that is ready out-of-the-box to support the official OpenDXL Node-RED solutions available. Note that some additional environmental requirements may need to be met for the various community-built solutions that use Node-RED.

    Hi Vhardy,

    Unfortunately the OpenDXL team doesn't have the information on hand regarding TIE product features (at least the ones unrelated to DXL) .

    We'll see if we can locate documentation regarding TIE's reporting node functionality and let you know as soon as possible. One thing that may help you get started would be the following TIE 2.3.0 Installation Guide: Configure the TIE server extension. Note that the information regarding a "Reporting Secondary" server requires a second deployment of a TIE server.

    There may be additional helpful information in the TIE 2.3.0 Product Guide.


    - Update -

    This is outside of our wheelhouse, it seems.

    We recommend that you speak with your point of contact in McAfee Support to directly request information on this issue. They should be able to help you more detailed information regarding TIE reporting nodes.

    Glad to hear you're enjoying the start of this new feature for OpenDXL. Having this kind of information available has been a popular request, and it's great to finally be able to provide it.

    We are planning to increase the available number of API specifications for solutions to include all McAfee-created solutions (including commercial solutions such as TIE and MAR. Partner solutions may eventually get API specifications as well, provided by the partner themselves.

    Each McAfee-created solution with an API specification will also have the specification available in YAML or JSON format - in fact these formatted documents are used to generate the more reader-friendly version you see in the API Specification tab.

    We should have many more specifications available soon!

    As you mentioned, the online documentation for the various OpenDXL solutions are hosted using Github Pages. To set them up, we used the following guide:

    (For whatever reason, GitHub typically tries to direct users to a more general "What is GitHub Pages?" article, which is much less helpful.)

    We can see how the current functionality of the certificate export/import for multi-ePO fabrics could lead to confusing circumstances when combined with OpenDXL's built-in provisioning. Our team will have to take some time to evaluate if a change (or customization) to this feature would reduce the potential for misunderstandings.

    It sounds like you are using the CLI option outlined here: Command Line Provisioning (CLI). To use client certificates generated using this method across brokers managed by different ePO Servers in a Multi-ePO DXL fabric, you would need to access the keystore on the brokers themselves, which we don't recommend unless absolutely required. Please let us know if you need more information about this particular method.

    An easier and safer option for enabling clients to connect to brokers managed by different ePO Servers on a Multi-ePO DXL fabric is to generate your own CA and import it in the DXL Certificates (Third Party) section of the ePO Server Settings. If that option works for your environment, please see the following instructions:

    (Found under External Certificate Authority (CA) Provisioning in the Data Exchange Layer (DXL) Python SDK Documentation)

    1. Certificate Files Creation (PKI)
    2. ePO Certificate Authority (CA) Import
    3. ePO Broker Certificates Export
    4. ePO Broker List Export
    5. Repeat Step 2 on the other ePO Servers on your Multi-ePO DXL fabric (using your new third party CA)
    6. Use Agent Wake-Up prompt the brokers to check for updates
    7. Connect your client to any broker managed by an ePO that has your third-party CA

    Hi Exie ,

    There still isn't a concrete date on the OpenDXL Java Client, our team's recent push has been focused on the new OpenDXL JavaScript Client, as well as bug fixes and updates to existing Python solutions.

    Rest assured that our team wants to provide a Java-based client to the community as soon as possible!

    We do not have a set release date for any of the packages as of yet. However, there are several releases planned for the next few months specifically centering around the OpenDXL Node-RED extension, so you can expect to see updates fairly soon.

    We're excited to provide this new tool to the community, and we're working to get it into your hands as soon as possible!

    When it comes to determining the danger posed by external files, there are a number of reputation providers that have OpenDXL solutions available for community use (many of which can be found under the Threat Detection category.

    As far as hooking up those solutions to tools like Jabber or Lync, an intermediary tool or service hook would need to be created that made use of the above Threat Detection solutions. We encourage community members like yourself with unique requirements to experiment, and feel free to use existing solutions to create new ones that address needs such as these!

    Certificate-based topic authorization configuration settings that have been set on one ePO Server in a Multi-ePO environment will be applied to the entire Multi-ePO fabric, as long as all ePO Extensions and DXL Brokers in the Multi-ePO environment are DXL 4.0 and above.

    It may take up to 24 hours by default for certificate-based topic authorization policy to propagate across the entire Multi-ePO fabric.