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