Do we want to be able to apply policy to operator tools? These would be tools for inspecting a router or router network as a whole, not a particular vhost.
These tools would (under certain configurations) connect from anywhere to anywhere on the router network. Even for a single router there would be multiple sensible connection interfaces. Without a distinct way to specify the application (baked into the tools, in this scenario), I think you would need to use a special-case vhost, a la "x-operator-tools". This seems like an abuse of the vhost concept. But I'd be fine with it if you all say it works for you. Another way perhaps would be to have policy for addresses. On Thu, May 12, 2016 at 11:06 AM, Robbie Gemmell <[email protected]> wrote: > On 12 May 2016 at 18:33, Chuck Rolke <[email protected]> wrote: > > > > > > ----- Original Message ----- > >> From: "Gordon Sim" <[email protected]> > >> To: [email protected] > >> Sent: Thursday, May 12, 2016 10:46:30 AM > >> Subject: Re: Dispatch access control policy - what is the idea behind > applicationName? > >> > >> On 09/05/16 17:58, Justin Ross wrote: > >> > Hi, Jakub. Here's my proposal (two versions). > >> > > >> > ## Version 1 > >> > > >> > - Dispatch defines "applications" as policy domains > >> > - Dispatch uses one of the following, in descending priority, to > identify > >> > the app: > >> > - open.properties["application-id"] (real property name to be > >> > determined > >> > later) > >> > - open.hostname ("virtual host") > >> > - TCP connection level host (the "physical" or network host) > >> > - APIs and tools should offer ways to control the application ID and > >> > hence > >> > override the policy domain that is used > >> > > >> > ## Version 2 > >> > > >> > - Dispatch defines "vhosts" as policy domains > >> > - Dispatch uses one of the following, in descending priority, to > identify > >> > the app: > >> > - open.hostname ("virtual host") > >> > - TCP connection level host (network host) > >> > - The policy domain in use can only be determined by virtual host or > >> > network host > >> > > >> > I favor version 1, on the idea that dispatch policy domains should > have a > >> > more flexible scope. > >> > >> I favour version 2, I think. I don't think the application should be > >> responsible for identifying the policy domain that applies to it. Using > >> virtual hosts is a well known approach. I could also envisage that a > >> listener config could define the policy to apply (or the default > policy). > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > * The "TCP connection level host (network host)" has no useful > > information. That will always be the address of the router itself > > and has no hint about where the user was trying to go. > > It could perhaps be multiple homed, with eventually different > behaviour on each interface. > > > Version 2 in practice is simply the open.hostname. [1] > > > > * A patch went into 0.6 this week that defines a fallback policy that > > has rules and settings for open.hostname values that are not > > defined in the router's policy database. It now works as: > > > > IF open.hostname in policy-ruleset-db: > > use policy-ruleset-db[open.hostname] > > ELSE > > IF fallback-enabled: > > use policy-ruleset-db[fallback] > > ELSE > > connection disallowed - no defined policy > > > > * I like the concept in Version 1 of allowing some kind of > > connection.properties["application-id"] = "virtualhost" > > > > ** This lets users whose clients do not put the right thing into > > open.hostname participate in Dispatch networks before an updated > > client comes along. > > > > ** This will work today. > > > > I'd think that would often not be the case; if they can't influence > the open.hostname already, its also likely they cant influence > open.properties values either. > > Regardless, I'd also tend toward option 2, using virtual hosts is a > well known thing. > > > ** The router could be configured to allow this property to control > > policy or not. > > > > ** I see no more risk in adding this property than in using the > > open.hostname. Determined users can steer the open.hostname > > to have whatever they want. [2] > > > > -Chuck > > > > [0] > > Suppose the router is at 10.10.1.1 and the hosts file has > > 10.10.1.1 banking > > 10.10.1.1 telco > > 10.10.1.1 foobar > > > > [2] > > The client opens amqp://banking:5672 and open.hostname holds 'banking' > > The client opens amqp://telco:5672 and open.hostname holds 'telco' > > The client opens amqp://foobar:5672 and open.hostname holds 'foobar' > > > > [1] > > In all three cases the network host is 10.10.1.1. > > How is that actionable for policy? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
