Security is a key feature of UA but security requires that the Servers be able to publish their security requirements so Clients can know how to connect. UA makes this possible via the Discovery Services which have been discussed in prior posts. Unfortunately, the information that a Client needs to connect often depends on where the client is.

For example, a UA Server inside a NAT firewall does not have an externally visible IP address or hostname which means the Client needs to know how to access the Server via an externally accessible address assigned by the firewall.

UA provides a number of protocol independent options that allow developers and administrators to deal with this problem.  However, it would be best to start with a quick review of the process that UA Clients use to discover the security information required to connect which is illustrated in the figure below.

In the first step, the Client calls the FindServers service on a Discovery Server which then returns a list of Servers known to the Discovery Server. This list of Servers includes a list of Discovery URLs which the Clients can use to request the detailed connection information for a specific Server.

In the second step, the Client calls the GetEndpoints service on the Server which then returns a list of Endpoints exposed by the Server. This list includes a URL for each Endpoint and is specified by the Server's configuration.

In each of those steps the Client provides an EndpointUrl parameter which specifies the URL that the Client used to contact the Server. This information allows the Server to determine what to return to the Client. In most cases, the Server will look at the domain in the Client provided URL and only return URLs that match that domain. However, it is up to administrators to specify the exact URLs used because the externally accessible URLs could use different ports and/or have different paths.

Applications built with the UA .NET SDK allows Administrators to specify the additional URLs with the AlternateBaseAddresses element in the  Configuration file. The following example configures a server running on a machine called ' server01' to be accessible via mycompany.com addresses.

<BaseAddresses>

  <ua:String>opc.tcp://localhost:61210/MyServer</ua:String>

  <ua:String>http://localhost:61211/MyServer</ua:String>

</BaseAddresses>

<AlternateBaseAddresses>

  <ua:String>http://mycompany.com:40000/MyServer</ua:String>

  <ua:String>opc.tcp://mycompany.com:40001/MyServer</ua:String>

</AlternateBaseAddresses>

Unfortunately, not all Servers will know the external URLs which can be used to access them which will create problems for Clients. Clients can detect and recover from this problem by checking if the domain of the URL used to call the GetEndpoints service matches the domain of the Discovery URLs in the Endpoint Descriptions (The Discovery URLs are contained within the Server element). If the domains are different then the client can replace the domain and port with the domain and port from the Discovery URL and apply the same change to the Endpoint URL.  Unfortunately, URLs which use a scheme different from the scheme used to fetch the information will likely have to be discarded because the Client cannot know if they are reachable. The following table illustrates the conversions done by the Client.

Of course the manipulating URLs does have security implications for that reasons Servers should be configured with all URLs that can be used to access them and they should provide the correct URLs to the Clients based on the value of the EndpointUrl parameter. In addition, the Server's application certificate should include all domains that can be used to access the Server in the X509 Subject Alternate Name Extension. The compliance tests for Servers will check that Servers have this capability.