Add pluggable authentication and authorization to snapshotserver and changeserver

[kriswehner]

We need a pluggable auth system for both AuthN and AuthZ that can check that a user has a valid, non-expired key as well as use that to verify their access to their requested scopes.

[gbrail]

I opened another issue to add basic auth from my own backlog. Perhaps a pluggable mechanism is better. Problem is, of course, that golang and "pluggable" don't really go together...

[kriswehner]

My initial thought was to define a sql query (in a command line switch or config file) that would in one step check validity of the requested API and the scopes that are passed in, and then the pluggability would be adapting that sql query to your schema. Would that work for you guys?

[gbrail]

The change server runs nicely even if it can't reach postgres -- I'd like to keep it that way. I think that we can do this by having a special table that gets stored locally and used to make authorization decisions, but we'll have to do a little bit of thinking about it. I have some ideas though, so let me try some things out this week.

[gbrail]

Here's a proposal:

In the configuration for the change and snapshot servers, we'll designate a table called the "authorization table." The name of this table will be configurable (and you'll be able to leave it undefined, which means no authorization).

The table should have the following schema (but any name):

create table authorization_table (
id text,
scope text,
primary key (id, scope)
)

In addition, both servers will consume an HTTP header that stores the "user ID." By default this will be called "X-Transicator-UserID". However there will be a parameter that allows the user to customize this.

On each call to the snapshot server, the server will do the following:

1. Extract the user ID from the HTTP headers. Reject the request if there is no user ID.
2. Extract the list of scopes from the HTTP query parameters (this already happens)
3. For each scope, do the equivalent of:
   select from authorization_table where id = (User ID) and scope = (Scope)
4. If the above query does NOT result in a row, then reject the request as unauthorized.

The change server will run through all the above steps, except that it will not query the database directly. Instead, it will treat the "authorization_table" table as a special table, and rather than pass its contents on to the client, it will persist the authorization information inside the LevelDB database. This will make it possible for the change server to run even if it cannot reach Postgres.

Furthermore, in order for this to work, when the change server first starts it will retrieve the entire "authorization_table" table from the database and prepopulate its own copy before it begins replicating any changes.

[kriswehner]

That would work for us if that was a view, but if it's being replicated the view isn't going to work.

Can we do an optional (disable-able) way to not use the locally stored version and always query postgres, if you're ok with that dependency? We'd probably want a different url for hitting postgres for this query versus the actual replication stream.

[gbrail]

Actualy it best as a view for us too. So let's see if we can do that another way. The only problem is that the configuration is starting to get complicated and now I think that we need some sort of a configuration file.

[kriswehner]

So if we're going to a config file (which I agree is seeming very necessary), can we make the query pluggable too? We have some more complex usecases (superusers, for instance) that we'd prefer to not have to expose their full set of allowed scopes.

What I'd like is a query that takes the user id (token value, whatever) and requested scope(s) and returns the set of scopes that the user is allowed to see (or perhaps returns a single 0-valued column if the user doesn't have access to the scopes and a > 0 column if they do)

[gbrail]

Yes -- but there's more to think about here. For instance, we will need the
authorization logic in other places too and perhaps we're better off, at
least within Apigee, with a micro service...

On Tue, Nov 8, 2016 at 3:01 PM, Kris Wehner [email protected]
wrote:

So if we're going to a config file (which I agree is seeming very
necessary), can we make the query pluggable too? We have some more complex
usecases (superusers, for instance) that we'd prefer to not have to expose
their full set of allowed scopes.

What I'd like is a query that takes the user id (token value, whatever)
and requested scope(s) and returns the set of scopes that the user is
allowed to see (or perhaps returns a single 0-valued column if the user
doesn't have access to the scopes and a > 0 column if they do)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAf0a3iu7Mjrh4EoqycYfuC_K2f0zP61ks5q8P9DgaJpZM4Kpzcy
.

Greg Brail | apigee https://apigee.com/ | twitter @gbrail
http://twitter.com/gbrail @apigee https://twitter.com/apigee

[gbrail]

At the moment the jury is still out on whether we for our own needs need these servers to check authorization, or whether we will have an external proxy that does it. (That would however imply that we beef up the TLS support to optionally verify the client certificate.)

[kriswehner]

@gbrail we're definitely going to need authorization, but we can make it disable-able. If this is the point where we move to a separate fork, that's ok too.

[gbrail]

I'm happy to have the feature in and happy to review, test, etc. However
tight now developing it isn't a priority for me. But if have an idea or
implementation I can review and merge it.

On Fri, Nov 18, 2016 at 11:20 AM Kris Wehner [email protected]
wrote:

@gbrail https://github.com/gbrail we're definitely going to need
authorization, but we can make it disable-able. If this is the point where
we move to a separate fork, that's ok too.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAf0a1PGXJGS2AKOKPFpaJi4501wk7GOks5q_d5HgaJpZM4Kpzcy
.

[kriswehner]

I'm working on this now, hopefully in a transparent fashion

[kriswehner]

After discussing internally, we're going to change strategy on how to build this out. We'll share a proposed architecture once it's together.