The ‘recipients’ parameter in the Node 2 Specification, is a feature designed to enable nodes to dynamically send messages to multiple parties without the need for pre-programmed business logic. The following guidelines and best practices will assist flow developers interested in using the ‘recipients’ parameter.

Technical Details

• The Recipients parameter is a string that may be a Node URI or an email address.
• If a submission request specifies a Node URI recipient, the processed package will be forwarded to the specified recipient using the submit method.
• If a submission request specifies an email recipient, the processed package will be emailed to the specified recipient.
• Optional for a receiving node to implement functionality to process ‘recipients.’
• Required as an element in the request message (the value may be empty).
• On any error processing for the recipient parameter, a node should return a SOAP fault indicating there was an error with recipients. In this instance, the originating node must resend the submission.

Security

• The NAAS will provide authorization capabilities for ‘recipients.’ Node administrators will be able to define which users can make use of this function through standard NAAS policies.
• Nodes forwarding submissions through the ‘recipients’ parameter will need to use their own NAAS credential to authenticate with the receiving node.
• Specific security models and error conditions/messages should be defined on a flow by flow basis.

Best Practices

• Nodes should only honor ‘recipient’ values from trusted partners who have been explicitly permitted to make use of this functionality.
• Flow developers should seek to use ‘recipients’ only when it reduces complexity and improves functionality of a business process.
• This feature is not intended to be a ‘forwarding’ mechanism for multiple nodes. Flows using recipients should seek to minimize the processing and transmission that any one node would experience in the process of honoring this parameter.

1. New default security settings for Query and Solicit web services that use the Network Authentication and Authorization Service (NAAS);
2. The impact of these changes to existing data flows;
3. Special security considerations related to the EN Browser’s Guest access account; and
4. Recommended actions for Node Administrators who need to secure sensitive data, including specific instructions for OpenNode2 and EN-Node users.

Background on Publishing and Data Access

Many Exchange Network data flows are powered by Submit web services. These data flows are not publishing-oriented since they have to be initiated by the owner of the data. Some data flows on the Exchange Network make use of Query or Solicit web services. These are often referred to as publishing data flows because, unlike Submit web services, Query and Solicit web services allow data owners to make data available through their Node for others to access—assuming the owner has give them permission to do so.

Network Governance has a long-standing policy of encouraging Partners to publish more data and make it as accessible as appropriate. In support of that policy, the Exchange Network is making a change to the default security settings in the NAAS.  Node Administrators should also be aware of the security considerations related to a publicly available data access tool called the Exchange Network Browser.

What is Changing?

Previously, when a Node Administrator created a new web service for a data flow, the NAAS would, by default, create a security policy that completely restricted access to the service unless the Node Administrator specifically granted rights to a specific user. Effective immediately, new services will be open by default and Node Administrators will need to restrict access if necessary. Administrators will still have the same level of control over their data and who can see it.

If Administrators already have existing data flows with publishing web services and have placed restrictions around who can access them, those restrictions will remain unchanged. Any existing security policy on a Node supersedes this new default behavior.  If a data flow is secured today, it remains secured.  If a data flow is unsecured today, it will remain open to anyone with valid NAAS credentials.

Guest Access to the Exchange Network Browser

The Exchange Network Browser is a web-based tool that allows users to discover and access the different data flows and web services that are available on the Exchange Network.  The EN Browser is powered by the Exchange Network Discovery Service (ENDS), so a data flow or web service is only visible and available if it is registered in ENDS.  The important security consideration regarding the EN Browser is that it supports two types of access. First, it allows users to securely log-in with their NAAS user name and password to access any secure data flows for which they have been granted permission.  Second, it allows has Guest access for public users that do not have NAAS credentials.

Guest access was enabled by embedding a set of special NAAS credentials into the EN Browser. The Guest user name is: “enbrowser@exchangenetwork.net.” Guest access will be active as of December 12, 2011.  Node Administrators should consider the following three questions to determine whether to take any action to secure their data:

1. Do you have Query or Solicit services set up on your Node?
2. Are those services registered in ENDS?
3. Is the data inappropriate for public access?

If Administrators answer YES to all three of these questions, then they should take steps to deny access to the EN Browser Guest account (i.e., enbrowser@exchangenetwork.net) for the sensitive data flows. This can be accomplished by adjusting the security settings in the Node’s administration interface.

How to Adjust Security Settings to Enable or Restrict Access to Data Through the EN Browser

Many Node products offer the ability to adjust security settings directly in the administration interface. Specific instructions for users of OpenNode2 and the EN Node are included in the November 17, 2011, Open Call Presentations. Additional information exists in the Node Administration manuals for OpenNode2 and EN-Node.  Users of other Node product needing assistance should contact the software developer.

Additional Questions?

Additional questions not answered here should be directed to the Exchange Network Coordinator.

EN Governance documented the necessary changes to many national regulatory data flows in a series of addenda to the Flow Configuration Documents (FCDs). More information is available in Node 2 FCD Compatibility Guideline Development.