> On 22 Sep 2016, at 12:16, Christian Schneider <ch...@die-schneider.net> wrote: > > I think the model I described can be more secure as only the proxy needs > access to the intranet but I clearly see the need for both approaches as you > correctly stated that my approach is more complex. > > I agree about the proposed changes in Topology Manager and zookeeper > discovery. They should cover both approaches. > > The change in the existing distribution manager would not be needed in my > approach. Instead we would need a separate distribution manager that takes > care of the proxying or external proxy config. I think we could implement > this using the Aries specific Distributionprovider SPI > (https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/DistributionProvider.java). > This should make the code pretty small compared to a full distribution > provider. > > There is one thing I am missing in your description. How do you configure the > proxy server that provides the secure endpoint? I think the typical > production approach will be to use an existing HTTP proxy server that has an > API to configure the forwarding. Would that happen in the REST provider? I am > not sure if that would be a good idea as we will likely have to support > different proxy APIs and I would rather avoid putting all that into the REST > provider. Another thing is that we might need the same or very similar > functionality for SOAP endpoints.
My understanding of what happens here is that the proxy server has a static mapping from URI path /foo/bar/* to back end server X. Therefore the back end server can work our the proxy URI by prepending https://proxy.server:1234/foo/bar/ to “some/service/path”. This proxy is configured by the system operator, and the RSA implementation is notified of the path prefix using config admin. > > So I guess it might be better to just provide an SPI somehow in Aries RSA > where people could plug in for the different proxy servers. Config Admin seems like the right choice to me, as I assume the proxy will not be running in the same process, but there are a lot of options here. > > Christian > > > On 22.09.2016 12:26, Timothy Ward wrote: >> 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: >> >> Topology: >> >> * String+ of filters to apply to the Discovery EndpointEventListener >> >> Discovery: >> >> * MSF for allowing multiple simultaneous configurations >> * String+ of filters to apply to the Discovery EndpointEventListener >> >> Distribution: >> >> * 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 end >> * Services can be deliberately exported as *only* insecure endpoints for >> use at the back end >> * 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. >> >> Regards, >> >> Tim >> >> On 22 Sep 2016, at 09:23, Christian Schneider >> <ch...@die-schneider.net<mailto:ch...@die-schneider.net>> wrote: >> >> 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: >> >> See http://liquid-reality.de/display/liquid/Zones+for+Aries+RSA >> >> 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? >> >> Christian >> >> >> 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. >> >> Regards, >> >> Tim >> >> >> On 19 Sep 2016, at 13:52, Christian Schneider >> <ch...@die-schneider.net<mailto:ch...@die-schneider.net>> wrote: >> >> I just had a discussion with Panu Hämäläinen about the DiscoveryPlugin >> mechanism. >> See https://issues.apache.org/jira/browse/ARIES-1613 and >> https://issues.apache.org/jira/browse/ARIES-1614 . >> >> 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 >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
