> 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
> 

Reply via email to