This Serviceis used by the Clientto specify the identity of the user associated with the Session. This Servicerequest shall be issued by the Clientbefore it issues any Servicerequest other than CloseSessionafter CreateSession. Failure to do so shall cause the Serverto close the Session.
Whenever the Clientcalls this Servicethe Clientshall prove that it is the same application that called the CreateSession Service. The Clientdoes this by creating a signature with the private key associated with the clientCertificatespecified in the CreateSessionrequest. This signature is created by appending the last serverNonceprovided by the Serverto the serverCertificateand calculating the signature of the resulting sequence of bytes.
When the ActivateSession Service is called for the first time then the Servershall reject the request if the SecureChannelis not same as the one associated with the CreateSessionrequest. Subsequent calls toActivateSession may be associated with different SecureChannels. If this is the case thenthe Servershall verify that the Certificatethe Clientused to create the new SecureChannelis the same as the Certificateused to create the original SecureChannel. In addition, the Servershall verify that the Clientsupplied a UserIdentityTokenthat is identical to the token currently associated with the Session. Once the Serveraccepts the new SecureChannelit shall reject requests sent via the old SecureChannel.
The ActivateSession Service is used to associate a user identity with a Session. When a Clientprovides a user identity then it shall provide proof that it is authorized to use that user identity. The exact mechanism used to provide this proof depends on the type of the UserIdentityToken. If the tokenis aUserNameIdentityTokenthen the proof is the passwordthat is included in the token. If the token is an X509IdentityToken then the proof is a signature generated with private key associated with the Certificate. The data to sign is created by appending the last serverNonceto the serverCertificatespecified in the CreateSessionresponse. If a token includes a secret then it should be encrypted using the public key from the serverCertificate.
Serversshall take proper measures to protect against attacks on user identity tokens. Such an attack is assumed if repeated connection attempts with invalid user identity tokens happen. One option is to lock out an OPC UA Clientfor a period of time if the user identity token validation fails several times. The OPC UA Clientis either detected by IP address for unsecured connections or by the ApplicationInstanceUrifor secured connections. Another option is delaying the Serviceresponse when the validation of a user identity fails. This delay time could be increased with repeated failures. Sporadic failures shall not delay connections with valid tokens.
Clientscan change the identity of a user associated with a Sessionby calling the ActivateSession Service. The Servervalidates the signatures provided with the request and then validates the new user identity. If no errors occur the Serverreplaces the user identity for the Session. Changing the user identity for a Sessionmay cause discontinuities in active Subscriptionsbecause the Servermay need to tear down connections to an underlying system and re-establish them using the new credentials. A Servershall re-evaluate the permissions of all MonitoredItemsin Subscriptionsassigned to the Sessionafter a user identity change.
When a Clientsupplies a list of locale ids in the request, each locale id is required to contain the language component. It may optionally contain the <country/region> component. When the Serverreturns a LocalizedTextin the context of the Session, it also may return both the language and the country/region or just the language as its default locale id.
When a Serverreturns a string to the Client, it first determines if there are available translations for it. If there are, then the Serverreturns the string whose locale id exactly matches the locale id with the highest priority in the Client-supplied list.
If there are no exact matches, then the Serverignores the <country/region> component of the locale id, and returns the string whose <language> component matches the <language> component of the locale id with the highest priority in the Clientsupplied list.
If there still are no matches, then the Serverreturns the string that it has along with the locale id.
A Gateway Serveris expected to impersonate the user provided by the Clientwhen it connects to the underlying Server. This means it shall re-calculate the signatures on the UserIdentityTokenusing the nonce provided by the underlying Server. The Gateway Servershall use its own user credentials if the UserIdentityTokenprovided by the Clientdoes not support impersonation.