On 12 May 2016 at 19:45, Chuck Rolke <[email protected]> wrote: > > > ----- Original Message ----- >> From: "Robbie Gemmell" <[email protected]> >> To: [email protected] >> Sent: Thursday, May 12, 2016 2:06:50 PM >> Subject: Re: Dispatch access control policy - what is the idea behind >> applicationName? >> >> 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. >> > > Indeed. The current policy approves a user based on (authenticated userId, > user's host IP address, open.hostname). Also qualifying the user on the > listener over which he connected would be a significant change. > >> > 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. > > Good point. > >> >> Regardless, I'd also tend toward option 2, using virtual hosts is a >> well known thing. >> > > Option 2 is what's there today. >
Indeed, another good reason to prefer it :) >> > ** 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] >> >> > > --------------------------------------------------------------------- > 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]
