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.

Once used, a serverNoncecannot be used again. For that reason, the Serverreturns a new serverNonceeach time the ActivateSession Serviceis called.

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.

Table 17defines the parameters for the Service.

Table 17– ActivateSession Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters. The type RequestHeaderis defined in 7.33.

clientSignature

SignatureData

This is a signature generated with the private key associated with the clientCertificate. This parameter is calculated by appending the serverNonceto the serverCertificateand signing the resulting sequence of bytes.

If the serverCertificatecontains a chain, the signature calculation shall be done only with the leaf Certificate. For backward compatibility a Servershall check the signature with the full chain if the check with the leaf Certificatefails.

The SignatureAlgorithmshall be the AsymmetricSignatureAlgorithmspecified in the SecurityPolicyfor the Endpoint.

The SignatureDatatype is defined in 7.37.

clientSoftwareCertificates []

SignedSoftware‌Certificate

Reserved for future use.

The SignedSoftwareCertificatetype is defined in 7.38.

localeIds []

LocaleId

List of locale ids in priority order for localized strings. The first LocaleIdin the list has the highest priority. If the Serverreturns a localized string to the Client, the Servershall return the translation with the highest priority that it can. If it does not have a translation for any of the locales identified in this list, then it shall return the string value that it has and include the locale id with the string. See OPC 10000-3for more detail on locale ids. If the Clientfails to specify at least one locale id, the Servershall use any that it has.

This parameter only needs to be specified during the first call to ActivateSessionduring a single application Session. If it is null or empty the Servershall keep using the current localeIdsfor the Session.

userIdentityToken

Extensible Parameter

UserIdentityToken

The credentials of the user associated with the Clientapplication. The Serveruses these credentials to determine whether the Clientshould be allowed to activate a Sessionand what resources the Clienthas access to during this Session.

The UserIdentityTokenis an extensible parameter type defined in 7.41.

The EndpointDescription specifies what UserIdentityTokensthe Servershall accept.

Null or empty user token shall always be interpreted as anonymous.

userTokenSignature

SignatureData

If the Clientspecified a user identity token that supports digital signatures, then it shall create a signature and pass it as this parameter. Otherwise the parameter is null or empty.

The SignatureAlgorithmdepends on the identity token type.

The SignatureDatatype is defined in 7.37.

Response

responseHeader

ResponseHeader

Common response parameters (see 7.34for ResponseHeaderdefinition).

serverNonce

ByteString

A random number that should never be used in any other request.

This number shall have a minimum length of 32 bytes.

The Clientshall use this value to prove possession of its Application Instance Certificatein the next call to ActivateSessionrequest.

results []

StatusCode

List of validation results for the SoftwareCertificates(see 7.39for StatusCodedefinition).

diagnosticInfos []

DiagnosticInfo

List of diagnostic information associated with SoftwareCertificatevalidation errors (see 7.12for DiagnosticInfo definition). This list is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the request.

Table 18defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 18– ActivateSession Service Result Codes

Symbolic Id

Description

Bad_IdentityTokenInvalid

See Table 182for the description of this result code.

Bad_IdentityTokenRejected

See Table 182for the description of this result code.

Bad_UserAccessDenied

See Table 182for the description of this result code.

Bad_ApplicationSignatureInvalid

The signature provided by the Clientapplication is missing or invalid.

Bad_UserSignatureInvalid

The user token signature is missing or invalid.

Bad_NoValidCertificates

The Clientdid not provide at least one Software Certificatethat is valid and meets the profile requirements for the Server.

Bad_IdentityChangeNotSupported

The Serverdoes not support changing the user identity assigned to the session.

Bad_SecurityPolicyRejected

See Table 182for the description of this result code.