aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <>
Subject Re: [Discuss] Support zones for Aries RSA. Also related to cloud support
Date Thu, 22 Sep 2016 10:26:21 GMT
Hi Christian,

This is very nearly the approach that I suggested, but it adds an additional zone into the
mix which I think is unnecessary, and I feel that hides the fact that exactly the same security
concerns exist with it.

In the layout that you’ve drawn the backend server publishes a service using RSA (the fact
that it’s REST/HTTP is immaterial). This is discovered by nodes in the backend zone using
a backend ZooKeeper. The “Proxy” node is also in this Back End discovery zone, and imports
services from it - this is the “DMZ” where both networks intersect. The firewall has to
have a rule configured to allow the DMZ to talk to the backend ZooKeeper in this model, just
as it does when the DMZ is bigger.

As the proposal isn’t more secure I would avoid this “forwarding” approach, and instead
have each back-end server use a ManagedServiceFactory to configure itself with two discovery
zones (i.e. two EndpointEventListeners with different configurations). These zones could use
two ZooKeepers, or two just namespaces within a single ZooKeeper. Each discovery configuration
should also be able to provide a String+ of filters that will be placed on the Discovery EndpointEventListener
(these would be anded with the core discovery filter). As a result you get purely config-admin
driven partitioning of the discovery space based on EndpointDescription Properties.

The front end services would be configured with just the one discovery zone which doesn’t
need special filtering, or any other special handling from the client Topology Manager

The remaining work needs to be done in two places:

  1.  The “back-end” topology manager should have a configurable EndpointEventListener
filter (just like the discovery layer), which allows it to be configured ignore the “secure”
endpoints. This is much simpler than a Topology plugin model, and follows the RSA spec.
  2.  The distribution provider - this is the only part which is related to the protocol/transport.
In this case the REST Distribution provider simply needs to be configurable with a secure
proxy endpoint, and to add a service intent which indicates that the transport is secure (e.g.
message.confidentiality). This allows exported services to *require* the intent by setting
the service.exported.intents property. Services which do specify this intent would not be
exported insecurely, something that is not possible in the forwarding model.

Effectively I believe there is only a small amount of work to do here, all of which is within
the scope of the existing RSA spec:


  *   String+ of filters to apply to the Discovery EndpointEventListener


  *   MSF for allowing multiple simultaneous configurations
  *   String+ of filters to apply to the Discovery EndpointEventListener


  *   Support for configurable additional base urls which map to one or more service intents
  *   Ensure that Aries RSA is spec compliant when it comes to intent matching

The advantages of this model are that:

  *   Services can be deliberately exported as *only* secure endpoints to be used by the front
  *   Services can be deliberately exported as *only* insecure endpoints for use at the back
  *   The secure endpoint information correctly identifies the source framework, service id
and endpoint id
  *   There is no “republishing” component to build and install, and the overall system
is simpler as a result.

I hope this is clear enough to outline what I’m thinking.



On 22 Sep 2016, at 09:23, Christian Schneider <<>>

So lets think about a practical example. We want to expose a REST service that is visible
to the inside via its direct url on the server that exposes the service and also via a proxy
server where this service will have a different url.

So the server side topology manager would detect that the service is to be published. It would
call the distribution provider to export the service.

The provider would then return two ExportRegistrations one for the direct access and one for
the access over the proxy. They could each have a special property like "zone" to distinguish
them (like "backend" and "frontend").

The TopologyManager on the front end client side then could be configured to only consider
Endpoints that have (zone=frontend) for imports.

I think on the client I like this approach. It would also need only minimal additions to the
TopologyManager code. We would either need a config setting for a import filter or a SPI where
the user can supply custom filtering logic.

On the server side I am not so sure. The distribution provider would need to know about the
proxy and it might even need to communicate with it to get the alias address for the service
it exports. Another problem is that in such a scenario the server administrator would be able
to poke new holes into the firewall.
On the positive side I agree that the DistributionProvider might know more about the details
of the protocol to be qualified to create a suitable address than the TopologyManager.

Generally I think I would prefer a more central approach where you have a system that is part
of the firewall that manages which services to expose to the outside world. Maybe this can
also be done with Remote Service Admin.

How about this:


We use a system with two instances of the zookeeper discovery. One that communicates with
the backend zookeeper and one that communicates with the frontend zookeeper.

The backend discovery would report all internal services to the TopologyManager. The TopologyManager
would select the backend services for import using a special proxy DistributionProvider.

The proxy DistributionProvider would create an OSGi service with the necessary prorperties
to be exported as a proxy for the frontend. The TopologyManager would detect this service
and export it using the same proxy DistributionProvider which would create an ExportRegistration
with the url of the proxy Endpoint it would also either implement an HTTP Proxy for the service
or configure an external proxy server.

This approach might even be able to cover both cases the case where we have one zookeeper
with all addresses and the case where we have spearate zookeepers for frontend and backend.

If I understand correctly then the Endpoint information for the proxy service would always
be sent to all discovery providers, or can the TopologyManager select where to export it?
If it can not then I think we would need a filtering config for the zookeeper discovery so
the frontend zookeeper will only contain the frontend services and the backend zookeeper would
only contain the backend services.

What do you think?


On 21.09.2016 11:49, Timothy Ward wrote:
Hi Christian,

From an RSA perspective this is a Topology Management issue, not a discovery issue. Services
should be exposed by the Distribution Provider with multiple ExportRegistrations (and hence
multiple EndpointDescriptions), one for the “internal” URL and one for the “proxied”
URL The Topology Manager on the client side should then import the Endpoint Description that
gives the behaviour that it desires.

Using multiple discovery services to do this sort of scoping is possible, but much more complicated
than controlling it using the Topology Manager. Adding a simple filter to the client side’s
Topology Manager’s EndpointEventListener would probably be sufficient, and could be done
easily using Config Admin.



On 19 Sep 2016, at 13:52, Christian Schneider <<>>

I just had a discussion with Panu Hämäläinen about the DiscoveryPlugin mechanism.
See and

What he needs is to have two zones of services, a backend zone and a frontend zone.

The (or some) services in the backend will be published with http. Inside the backend zone
the services should be available using this http url.

In the frontend zone these services should also be visible but their url should point to a
proxy server that offer a https connection and potentially some additional security mechanisms.

So we can not simply have one (zookeeper or other) discovery view. Instead we need a different
discovery view for backend and frontend and some mechanism to make some services from one
zone available in the other while also applying some changes like pointing to a proxy.

Do you think it makes sense to support this case in Aries RSA in some way?

I thought we might also be able to interact with one of the existing proxy servers to automatically
register the proxy for each service. Such a mechanism is very typically for cloud enabled
architectures. So that might also bring us nearer to good cloud support.

I would be happy about any ideas and feedback.


Christian Schneider

Open Source Architect

Christian Schneider

Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message