This Serviceis used by an OPC UA Clientto create a Sessionand the Serverreturns two values which uniquely identify the Session. The first value is the sessionIdwhich is used to identify the Sessionin the audit logs and in the Server’s AddressSpace. The second is the authenticationTokenwhich is used to associate an incoming request with a Session.

Before calling this Service, the Clientshall create a SecureChannelwith the OpenSecureChannel Serviceto ensure the Integrityof all Messagesexchanged during a Session. This SecureChannelhas a unique identifier which the Servershall associate with the authenticationToken. The Servermay accept requests with the authenticationToken only if they are associated with the same SecureChannelthat was used to create the Session. The Clientmay associate a new SecureChannelwith the Sessionby calling the ActivateSessionmethod.

The SecureChannelis always managed by the Communication Stackwhich means it shall provide APIs which the Servercan use to find out information about the SecureChannelused for any given request. The Communication Stackshall, at a minimum, provide the SecurityPolicyand SecurityModeused by the SecureChannel. It shall also provide a SecureChannelIdwhich uniquely identifies the SecureChannelor the Client Certificateused to establish the SecureChannel. The Serveruses one of these to identify the SecureChannelused to send a request. Clause 7.36describes how to create the authenticationToken for different types of Communication Stack.

Depending upon on the SecurityPolicyand the SecurityModeof the SecureChannel,the exchange of ApplicationInstanceCertificatesand Noncesmay be optional and the signatures may be empty. See OPC 10000-7for the definition of SecurityPoliciesand the handling of these parameters.

The Serverreturns its EndpointDescriptionsin the response. Clientsuse this information to determine whether the list of EndpointDescriptionsreturned from the DiscoveryEndpointmatches the Endpointsthat the Serverhas. If there is a difference then the Clientshall close the Sessionand report an error. The Serverreturns all EndpointDescriptionsfor the serverUrispecified by the Clientin the request. The Clientonly verifies EndpointDescriptionswith a transportProfileUrithat matches the profileUrispecified in the original GetEndpointsrequest. A Clientmay skip this check if the EndpointDescriptionswere provided by a trusted source such as the Administrator.

The Sessioncreated with this Serviceshall not be used until the Clientcalls the ActivateSession Serviceand proves possession of its Application Instance Certificateand any user identity token that it provided.

A Serverapplication should limit the number of Sessions. To protect against misbehaving Clientsand denial of service attacks, the Servershall close the oldest Sessionthat is not activated before reaching the maximum number of supported Sessions.

The SoftwareCertificatesparameter in the Serverresponse is deprecated to reduce the message size for OPC UA Applications with limited resources. The SoftwareCertificatesare provided in the Server’s AddressSpaceas defined in OPC 10000-5. A SoftwareCertificateidentifies the capabilities of the Serverand also contains the list of OPC UA Profilessupported by the Server. OPC UA Profilesare defined in OPC 10000-7.

Additional Certificatesissued by other organizations may be included to identify additional Servercapabilities. Examples of these Profilesinclude support for specific information models and support for access to specific types of devices.

When a Sessionis created, the Serveradds an entry for the Clientin its SessionDiagnosticsArray Variable. See OPC 10000-5for a description of this Variable.

Sessionsare created to be independent of the underlying communications connection. Therefore, if a communications connection fails, the Sessionis not immediately affected. When the communication connection fails, the Clientshould try to create a new communication connection and call ActivateSessionagain. See 6.7for more details.

Sessionsare terminated by the Serverautomatically if the Clientfails to issue a Servicerequest on the Sessionwithin the timeout period negotiated by the Serverin the CreateSession Serviceresponse. This protects the Serveragainst Clientfailures and against situations where a failed underlying connection cannot be re-established. Clientsshall be prepared to submit requests in a timely manner to prevent the Sessionfrom closing automatically. Clientsmay explicitly terminate Sessionsusing the CloseSession Service.

When a Sessionis terminated, all outstanding requests on the Sessionare aborted and Bad_SessionClosed StatusCodesare returned to the Client. In addition, the Serverdeletes the entry for the Clientfrom its SessionDiagnosticsArray Variableand notifies any other Clientswho were subscribed to this entry.

If a Clientinvokes the CloseSession Servicethen all Subscriptionsassociated with the Sessionare also deleted if the deleteSubscriptionsflag is set to TRUE. If a Serverterminates a Sessionfor any other reason, Subscriptionsassociated with the Session, are not deleted. Each Subscriptionhas its own lifetime to protect against data loss in the case of a Sessiontermination. In these cases, the Subscriptioncan be reassigned to another Clientbefore its lifetime expires.

Some Servers, such as aggregating Servers, also act as Clientsto other Servers. These Serverstypically support more than one system user, acting as their agent to the Serversthat they represent. Security for these Serversis supported at two levels.

First, each OPC UA Servicerequest contains a string parameter that is used to carry an audit record id. A Client, or any Serveroperating as a Client, such as an aggregating Server, can create a local audit log entry for a request that it submits. This parameter allows the Clientto pass the identifier for this entry with the request. If the Serveralso maintains an audit log, then it can include this id in the audit log entry that it writes. When the log is examined and the entry is found, the examiner will be able to relate it directly to the audit log entry created by the Client. This capability allows for traceability across audit logs within a system. See OPC 10000-2for additional information on auditing. A Serverthat maintains an audit log shall provide the information in the audit log entries via event Messages defined in this document. The Servermay choose to only provide the Auditinformation via event Messages. The Audit EventTypeis defined in OPC 10000-3.

Second, these aggregating Serversmay open independent Sessionsto the underlying Serversfor each Clientthat accesses data from them. Figure 14illustrates this concept.


Figure 14– Multiplexing users on a Session