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]
