Hi,

Not exactly, as the point of an OPC UA SDK, in general, is to provide a higher-level abstraction and thus to try hiding the complex raw communication details.

10+ years ago the communication layers of OPC UA typically looked like:

+----------------------+
|         TCP            |
+----------------------+
|      UA Stack       |
+----------------------+
|       UA SDK        |
+----------------------+
|  UA Application  |
+----------------------+

Stacks were responsible to handling the raw socket connections, encoding messages to binary and then provide a raw request-response layer for the actual services. SDKs then abstract things more and provide something more use-able. What you basically say you would want would have been inside the Stack level, though ‘SecurityToken’ is not actually a “user token”, but instead details related to the opc.tcp SecureChannel.

Nowadays Stacks are basically gone extinct. Some history regarding our SDK: https://documentation.prosysop…..ck-changes .We did make a mistake 15+ years ago that the stack classes were used directly in the SDK APIs, unfortunately fixing that might be impossible at this point. But basically other than those (and some util classes), classes being in ‘com.prosysopc.ua.stack’ package and subpackage should be considered to be “SDK private API”.

That all is to say that it is not intended that you would normally handle the raw requests and doing so could break SDK’s own functionality.

That being said, we do have some options, but it does require a bit more work. We would instead recommend using things that the sampleconsoleserver example shows, those are the intended ways, though that does involve attaching numerous XXXListeners to places for access control.

Anyway, you could try the following and let us know how it goes:
Subtype UaServer, override protected createXXXServiceHandler methods. Return sub-typed XXXServiceHandlers where ‘XXX’ is either ‘Attribute’, ‘NodeManagement’ or ‘Subscription’. There exist also a SessionServiceHandler, but we recommend not to touch that one. Note that there are some methods that are final, those are historical Stack-to-SDK entry points and cannot be overridden.

However, you could override the com.prosysopc.ua.server.ServiceHandler.validateRequest(EndpointServiceRequest). It is recommended to call super first, to receive the ServiceContext that needs to be returned. You could throw ServiceException to fail the entire service. The ServiceRequest can be obtained from EndpointServiceRequest.getRequest(). However, I would be very cautious on doing any ‘rate limiting’ attempts, it is not something expected by UA Clients, they will either break or retry immediately, which would defeat the point.

The ServiceContext does tell the Session and from the Session you can get the ServerUserIdentity, which is server-side variation of the UserIdentity a client would use. The ServiceContext is a parameter in most of the recommended Listener-ways for handling authorization, it is passed along the call chain, see below.

An alternative is to look for methods such as https://documentation.prosysop…..dResponse- , and override them. These are called after the validate and then some of them will then split up more to other protected methods, then eventually they will go to YYYManagers. XXX and YYY might not be the same, but e.g. in Sessions it will go to SessionManager, which you can get normally from UaServer. It would provide info (a bit) about the sessions (UA has a Diagnostics concept). Many of YYY will have also YYYListener, here SessionManagerListener, that provides handles to react to their creation etc.

As this post is already quite long, I’ll stop here for now, but please ask more and explain more about specifics what you would want to do.