mike1813
commented
11 months ago Con: it won't be possible to specify a service that itself uses multiple services, forwarding client requests to some, and using others on its own behalf [but] the domain model has improved so it may soon be possible to allow this.
Some more testing suggests that having a reverse proxy handle authentication for some back-end services but not others would be very problematic.
It is possible to specify this in an asserted system model, by using a ServiceProxy asset for the proxy (i.e., a process that can only be a reverse proxy), with back-end services used by the proxy some of which also control the proxy (meaning they authenticate clients, and some that do not (meaning they authenticate the proxy, which handles any authenticating of clients using those services).
Following recent improvements, the current inference rules correctly distinguish these cases, and creates the right relationships between the proxy and the back-end services. However, they don't yet distinguish correctly between clients that do or do not authenticate with the proxy.
The issue is that some clients could use some services of each type, leading to a situation where the proxy would authenticate the client only some of the time, based on which service they are requesting. That is certainly possible in principle, but at present there is no way to model the client-proxy relationship that depends on the back-end service requested. For that reason, the inference rules don't consider which services a client would be using, and just assume that all requests to a transparent proxy are forwarded.
It would be possible to infer the correct type of client-proxy relationship if and only if each client used services that do or do not require the proxy to handle authentication. So the fundamental limitation of the domain model is that clients should all be of one type, rather than all back-end services.
This limitation would make it very difficult to handle clients accessing services via a sequence of transparent proxies. The first proxy would aggregate over the clients, so the model would break unless all clients (and hence all back-end services) did the same thing.
What this means is that unless we radically overhaul the ProcessComms sub-model, there is no way to 'improve' the domain model sufficiently to overcome the second 'Con' listed at the top of this issue, despite the recent changes.
Reverse proxies come in two forms:
The only way to specify an authenticating proxy is by asserting that the process is of type ServiceProxy, a specialised process that maps an exposed endpoint to a back-end service. If any other type of Process is used, the assertion that the Process is used by a client and uses a back-end service would not imply that requests from the former are forwarded to the latter. The default assumption is that the Process is responding to clients, and sending its own requests to the back-end service while processing the client request.
However, with a transparent proxy the back-end service handles client authentication, which means it controls access to the proxy. Such a proxy can be specified using any Process, by asserting that it uses a back-end service which in turn controls the proxy.
Some types of Processes (e.g., remote access services) cannot act as transparent proxies. If they are specified to be both using and being controlled by another service, a modelling error is triggered.
Question: should we extend the modelling error so this restriction is imposed on all Process subclasses except the ServiceProxy class? To do so has both pros and cons:
This last point seems like a significant drawback. @mike1813 recommends no change until it is clear if the domain model can handle this mixed-mode of service operation.