I looked into this a year or so ago, and I couldn't make nginx or http do
what we need.
We can still have the services check the auth as well after the proxy auth,
and make things better than today, where we have the same problem that if
the TO mojo app is compromised, everything is compromised.
If we always route to TO, we don't untangle the mess of being dependent on
the monolithic TO for everything. Many services today, and more in the
future really just need a check to see if the user is authorized, and
nothing more.
On Sun, May 7, 2017 at 11:55 AM Robert Butts <robert.o.bu...@gmail.com>
wrote:
> What are the advantages of these config files, over an existing reverse
> proxy, like Nginx or httpd? It's just as much work as configuring and
> deploying an existing product, but more code we have to write and maintain.
> I'm having trouble seeing the advantage.
>
> -1 on auth rules as a part of the proxy. Making a proxy care about auth
> violates the Single Responsibility Principle, and further, is a security
> risk. It creates unnecessary attack surface. If your proxy app or server is
> compromised, the entire framework is now compromised. An attacker could
> simply rewrite the proxy config to make all routes no-auth.
>
> The simple alternative is for the proxy to always route to TO, and TO
> checks the token against the auth service (which may also be proxied), and
> redirects unauthorized requests to a login endpoint (which may also be
> proxied).
>
> The TO service (and any other service that requires auth) MUST hit the
> database (or the auth service, which itself hits the database) to verify
> valid tokens' users still have the permissions they did when the token was
> created. Otherwise, it's impossible to revoke tokens, e.g. if an employee
> quits, or an attacker gains a token, or a user changes their password.
>
>
> On Sun, May 7, 2017 at 4:35 AM, Amir Yeshurun <am...@qwilt.com> wrote:
>
> > Seems that attachments are stripped on this list. Examples pasted below
> >
> > *rules.json*
> > [
> > { "host": "localhost", "path": "/login", "forward":
> > "localhost:9004", "scheme": "https", "auth": false },
> > { "host": "localhost", "path": "/api/1.2/innovation/", "forward":
> > "localhost:8004", "scheme": "http", "auth": true, "routes-file":
> > "innovation.json" },
> > { "host": "localhost", "path": "/api/1.2/", "forward":
> > "localhost:3000", "scheme": "http", "auth": true, "routes-file":
> > "traffic-ops-routes.json" },
> > { "host": "localhost", "path": "/internal/api/1.2/", "forward":
> > "localhost:3000", "scheme": "http", "auth": true, "routes-file":
> > "internal-routes.json" }
> > ]
> >
> > *traffic-ops-routes.json (partial)*
> > .
> > .
> > .
> > { "match": "/cdns/health", "auth": { "GET":
> > ["cdn-health-read"] }},
> > { "match": "/cdns/capacity", "auth": { "GET":
> > ["cdn-health-read"] }},
> > { "match": "/cdns/usage/overview", "auth": { "GET":
> > ["cdn-stats-read"] }},
> > { "match": "/cdns/name/dnsseckeys/generate", "auth": { "GET":
> > ["cdn-security-keys-read"] }},
> > { "match": "/cdns/name/[^\/]+/?", "auth": { "GET":
> > ["cdn-read"] }},
> > { "match": "/cdns/name/[^\/]+/sslkeys", "auth": { "GET":
> > ["cdn-security-keys-read"] }},
> > { "match": "/cdns/name/[^\/]+/dnsseckeys", "auth": { "GET":
> > ["cdn-security-keys-read"] }},
> > { "match": "/cdns/name/[^\/]+/dnsseckeys/delete", "auth": { "GET":
> > ["cdn-security-keys-write"] }},
> > { "match": "/cdns/[^\/]+/queue_update", "auth": { "POST":
> > ["queue-updates-write"] }},
> > { "match": "/cdns/[^\/]+/snapshot", "auth": { "PUT":
> > ["cdn-config-snapshot-write"] }},
> > { "match": "/cdns/[^\/]+/health", "auth": { "GET":
> > ["cdn-health-read"] }},
> > { "match": "/cdns/[^\/]+/?", "auth": { "GET":
> > ["cdn-read"], "PUT": ["cdn-write"], "PATCH": ["cdn-write"], "DELETE":
> > ["cdn-write"] }},
> > { "match": "/cdns", "auth": { "GET":
> > ["cdn-read"], "POST": ["cdn-write"] }},
> >
> > .
> > .
> > .
> >
> >
> > On Sun, May 7, 2017 at 12:39 PM Amir Yeshurun <am...@qwilt.com> wrote:
> >
> > > Attached please find examples for forwarding rules file (rules.json)
> and
> > > the authorization rules file (traffic-ops-routes.json)
> > >
> > >
> > > On Sun, May 7, 2017 at 10:39 AM Amir Yeshurun <am...@qwilt.com> wrote:
> > >
> > >> Hi all,
> > >>
> > >> I am about to submit a PR with a first operational version of the API
> > GW,
> > >> to the "experimental" code base.
> > >>
> > >> The API GW forwarding logic is as follow:
> > >>
> > >> 1. Find host to forward the request: Prefix match on the request
> path
> > >> against a list of forwarding rules. The matched forwarding rule
> > defines the
> > >> target's host, and the target's *authorization rules*.
> > >> 2. Authorization: Regex match on the request path against a list of
> > *authorization
> > >> rules*. The matched rule defines the required capabilities to
> perform
> > >> the HTTP method on the route. These capabilities are compared
> > against the
> > >> user's capabilities in the user's JWT
> > >>
> > >> At this moment, the 2 sets of rules are hard-coded in json files. The
> > >> files are provided with the API GW distribution and contain
> definitions
> > for
> > >> TC 2.0 API routes. I have tested parts of the API, however, there
> might
> > be
> > >> mistakes in some of the routes. Please be warned.
> > >>
> > >> Considering manageability and high availability, I am aware that using
> > >> local files for storing the set of authorization rules is inferior to
> > >> centralized configuration.
> > >>
> > >> We are considering different approaches for centralized configuration,
> > >> having the following points in mind
> > >>
> > >> - Microservice world: API GW will front multiple services, not only
> > >> Mojo. It can also front other TC components like Traffic Stats and
> > Traffic
> > >> Monitor. Each service defines its own routes and capabilities. Here
> > comes
> > >> the question of what is the "source of truth" for the route
> > definitions.
> > >> - Handling private routes. API GW may front non-TC services.
> > >> - User changes to the AAA scheme. The ability for admin user to
> makes
> > >> changes in the required capabilities of a route, maybe even define
> > new
> > >> capability names, was raised in the past as a use case that should
> be
> > >> supported.
> > >> - Easy development and deployment of new services.
> > >> - Using TO DB for expediency.
> > >>
> > >> I would appreciate any feedback and views on your approach to manage
> > >> route definitions.
> > >>
> > >> Thanks
> > >> /amiry
> > >>
> > >
> >
>
