UA Discovery - The Basics 

Tags:

Previous posts discussed how every UA application instance has an X509 certificate assigned to it and how UA Security Policies describe standard security configurations for UA Server endpoints. What was not mentioned was how this information is distributed to Client applications. This is an important detail because a Client cannot establish a secure channel with Server unless it knows in advance what the Server is expecting. This is a common problem whenever applications are deployed with security and considerable thought has gone into making this process as painless as possible for UA developers and end-users.

 

The UA solution relies on a special endpoint which is called the "Discovery Endpoint" which is implemented by all UA Servers as well as a special class of Servers called "Discovery Servers". This endpoint never requires any security and does nothing other than provide Clients with location and current security configuration for one or more Servers. A Discovery Endpoint always supports two methods: FindServers and GetEndpoints. The FindServers method returns the Servers known to the Discovery Endpoint (Discovery Servers may know of many Servers). The GetEndpoints method returns the Endpoints supported by the Server and all of the security information required to connect to those Endpoints.

 

The FindServers method will return ApplicationDescription records that look like this:

<ua:Server>

 <ua:ApplicationUri>urn:somehost:MyServer</ua:ApplicationUri>

 <ua:ApplicationType>Server_1</ua:ApplicationType>

 <ua:DiscoveryUrls>

  <ua:String>

    http://somehost:51211/MyServer/discovery
 
</ua:String>

 </ua:DiscoveryUrls>

</ua:Server>

 

This record provides a globally unique identifier for the Server and a list of Discovery Endpoints supported by the Server. Clients will need to use one of these Discovery Endpoints to fetch the current security configuration for the Server. Note that some Servers will use a convention where the URL for the Discovery Endpoint is the same as the Server URL with '/discovery' appended to it. This convention will allow Clients to allow users to type in URLs like they do with Internet web sites. However, in most cases, Client applications will want to fetch a list of available Servers from a Discovery Service. A Discovery Service can be a UA Discovery Server but it can also be a directory service list UDDI or LDAP or some other suitable mechanism. No matter what the implementation the Discovery Service only needs to store the information shown above. The actual security configuration must come from directly from the Server itself. This ensures that Clients will not encounter problems due to out of date records in Discovery Services.

 

The GetEndpoints method return one or more EndpointDescription records that look like this:

 

<EndpointDescription>

 <ua:EndpointUrl>http://somehost:51211/MyServer</ua:EndpointUrl>

 <ua:Server>

   <ua:ApplicationUri>urn:somehost:MyServer</ua:ApplicationUri>

   <ua:ApplicationType>Server_1</ua:ApplicationType>

   <ua:DiscoveryUrls>

    <ua:String>

     http://somehost:51211/MyServer/discovery
    
</ua:String>

   </ua:DiscoveryUrls>

 </ua:Server>

 <ua:ServerCertificate>...</ua:ServerCertificate>

 <ua:SecurityMode>SignAndEncrypt_3</ua:SecurityMode>

 <ua:SecurityPolicyUri>

  http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15

 </ua:SecurityPolicyUri>

 <ua:UserIdentityTokens />

 <TransportProfileUri>

   http://opcfoundation.org/UA/profiles/transport/wsxml

 </TransportProfileUri>

 <ua:SecurityLevel>1</ua:SecurityLevel>

</EndpointDescription>

 

The EndpointUrl is the physical address. A single Server will usually have many different URLs which support different security configurations and/or transport protocols. The ApplicationUri can be used to determine if two different EndpointDescriptions provide access to the same Server. The ServerCertificate is the X509 certificate encoded as a stream of bytes. The SecurityMode and SecurityPolicyUri indicate what security configuration must be used. The TransportProfileUri is used to identify the wire protocol since the URL scheme (http in this case) may not be enough. The example above specifies that the endpoint accepts XML encoded messages that conform to the UA Web Services mapping described in Part 6. The UserIdentityTokens element specifies what kind of user authentication mechanisms are supported by the Server (future posts will discuss this topic in more detail). The SecurityLevel element is a recommendation provided by the Server (higher numbers are preferred choices).

 

OPC COM users will be familiar with the OPC Server List service (a.k.a. OpcEnum) which can be used to list the available Servers on a machine. UA provides an equivalent called the Local Discovery Server (LDS) which should be installed on every machine with a UA Server. The LDS provides a Discovery Endpoint at a well-known URLs which are defined by Part 6 of the specification. Clients will have advance knowledge of these URLs and can use them to find the LDS on any given host. The well known URLs are defined in the following table:

 

Transport Mapping

URL

Notes

SOAP/HTTP

http://localhost/UADiscovery

May require integration with a web server like IIS.

SOAP/HTTP

http://localhost:52601/UADiscovery

Alternate if it Port 80 cannot be used by the LDS.

UA TCP

opc.tcp://localhost:4840/UADiscovery

 

 

The order in which a Client uses these URLs should be something that can be configured since different systems will have different policies.

 

To summarize, a UA Client can discover everything it needs to know to connect securely with a UA Server with the following steps:

 

1) Connect to the LDS on the machine and call FindServers

2) Choose a Server and choose a Discovery Endpoint

3) Connect to the Server Discover Endpoint and call GetEndpoints

 

This figure illustrates these steps lists above.

 

That said, all of this convenience does raise some serious security issues. For example, Clients could be tricked into connecting to a rogue Server. Clients protect themselves against this risk by checking that the Server's Certificate is trusted before they connect to the Server and by verifying that the DNS name in the Server's certificates matches the DNS name in the URLs. This is the same mechanism that is used by web browsers when connecting to websites used for commerce.

 

The next post will dive into the details of implementing the FindServers/GetEndpoints methods in a Client and Server.

 

UPDATE: The SampleClient configuration uses LDS URLs which are not specified Part 6. This is permitted but not recommended. The Samples will be updated to remove the non-standard URLs.

 
Posted by OPCF02\randyarmstrong on 10-Feb-09
1 Comments  |  | Bookmark this post with:        
 
Failed to render control: Value does not fall within the expected range.

Comments


URL Table different from the UA Sample client configuration commented on Wednesday, 11-Feb-2009
I just wanted to report that the ...\Samples\Source\Samples\Client\Opc.Ua.SampleClient.Config.xml configuration file of the sample UA Sample Client contains the following declaration : opc.tcp://{0}:4840 http://{0}:52601/UADiscovery http://{0}/UADiscovery/Default.svc apart the {0} format stuff some urls are different from the table posted here Regards ClodProgea

Name:
URL:
Email:
Comments:

CAPTCHA Image Validation