----- 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. > > ** 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]
