End-to-end example

[travisghansen]

End-to-end example

[ajbouh]

I should add that I'm really excited about what you've put together and am excited to try it out!

[travisghansen]

@ajbouh absolutely! Glad you're willing to try it out. The approach is pretty unique so I think it takes a minute to settle in, once it has though it's pretty easy to understand.

Can you share some details about your environment? Which reverse proxy? Kubernetes? etc.

There's a fairly complete example available here:

• https://github.com/travisghansen/external-auth-server/blob/master/HOWTO.md

It's specifically focused on oauth2 plugin with github as a provider using traefik under kubernetes. Most the instructions translate pretty easy to other variations though.

[ajbouh]

Environment is Kubernetes + Ambassador. Am currently using a custom built AuthService (an Ambassador concept). My existing AuthService works great for HTTP API requests, but I don't have a solution for browser-based traffic yet.

Thanks for the pointer to documentation, though I was hoping to see what the final UX looks like from the user standpoint.

[travisghansen]

@ajbouh not sure I follow, there is no UX to the end-user (aside from oauth/openid provider). So do you have a service that you want to authenticate via API and browser-based stuff currently? If so this project will work perfectly. Do you have an identity provider that you want to use for oauth?

[ajbouh]

Yes, I think you understand what I'm trying to do. I plan to start with GitHub and Google as oauth providers.

[travisghansen]

@ajbouh ok perfect, and what do you intend to use for API style access? Static list of username/password? LDAP? Or did you have something else in mind altogether?

[ajbouh]

For the API I already have a custom authserver implemented that works via bearer token or basic auth.

[travisghansen]

Ok, not being familiar ambassador as much I may need some additional context. Typically external auth services can only have 1 URL configured in the reverse proxy so I'm not sure what the approach would be here.

With your existing service are they using jwt for the bearer tokens that you issue? How is basic auth handled? htpasswd file or ldap?

Sorry for all the questions just trying to see how this would best fit into your flow :)

[ajbouh]

Bearer tokens are opaque random tokens, as I don't personally trust JWT. Basic auth is essentially the same as bearer tokens, with the same random token used as a username.

The spec for AuthService in Envoy/Ambassador is (roughly):

1. send the HTTP headers of a request to the AuthService and buffer the request while waiting for a response from the AuthService
2. If the AuthService returns a 200 response, copy any headers from the AuthService response to the header of the buffered request and route it accordingly
3. If the AuthService returns a non-200 response, it sends that response back to the user/browser/http client

[travisghansen]

@ajbouh ok that sounds sane. So does ambassador let you configure more than 1 authservice per host/path? If not how do you intend to continue to use your existing service and this project?

[ajbouh]

That's what I'm trying to figure out :) I expect I'll be keeping what I already have and adding to it in some way, though I'm not completely clear on how eas works just yet.

…

On Fri, May 17, 2019, 18:10 Travis Glenn Hansen ***@***.***> wrote: @ajbouh <https://github.com/ajbouh> ok that sounds sane. So does ambassador let you configure more than 1 authservice per host/path? If not how do you intend to continue to use your existing service and this project? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=AAABZHLPB3URHB4PWCYOW4LPV5JQPA5CNFSM4HNX27R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWE2DA#issuecomment-493636876>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAABZHNHX5O6G7ZUMBBHKQTPV5JQPANCNFSM4HNX27RQ> .

[travisghansen]

Well, good question. This project is meant to be the external auth provider. So, a couple options:

1. Migrate your existing API clients to one of the plugins provided by this project
2. I implement a new plugin which is http (2nd layer external auth). I really like this idea regardless so I'll implement it anyhow :)

What do you check your opaque tokens against? Something in a DB?

[ajbouh]

I don't think migrating my existing clients to this package will work in the short term, so the second seems like a better option, although I'm worried about putting eas in the critical path of my API requests. Seems better to use eas as a fallback for browser-based authentication. Is that straightforward?

[ajbouh]

Yes, tokens are resolved to internal customer IDs via a database lookup.

[travisghansen]

Given the limitation of 1 external auth endpoint per service you're kinda stuck unless you have some way of applying finer grained rules at the proxy level. For example maybe all API requests are behind a specific route, or you serve up the app from 2 hosts and apply the auth urls to the respective services.

Totally understand apprehension around putting it into the critical path. I'd love to help however I can. Another perspective and set of eyes are great to have involved so thanks for the interest.

If you have control over the custom built auth service you currently use maybe you could implement #2 in reverse and make eas the 2nd layer based on browser agent strings or whatever.

Aside from implementing #2 if the DB lookups are fairly sane/simple for the opaque tokens I could implement a generic DB plugin as well. Now that infrastructure is all in place creating new plugins is generally 50-100 lines of code. So if it's a simple select and check for existence that would be pretty easy (as in, 30 minutes or less of programming easy).

In essence, how difficult would it be to re-implement you existing auth service? There's quite a solid foundation to build from on my side with plugins and custom assertions etc that are all ready to go..

[ajbouh]

I don't mind proxying requests to eas through my auth service. The API authentication state machine is a bit nontrivial, so I'm not sure it'd be straightforward (or worth it?) to port it up front.

…

On Fri, May 17, 2019, 21:42 Travis Glenn Hansen ***@***.***> wrote: Given the limitation of 1 external auth endpoint per service you're kinda stuck unless you have some way of applying finer grained rules at the proxy level. For example maybe all API requests are behind a specific route, or you serve up the app from 2 hosts and apply the auth urls to the respective services. Totally understand apprehension around putting it into the critical path. I'd love to help however I can. Another perspective and set of eyes are great to have involved so thanks for the interest. If you have control over the custom built auth service you currently use maybe you could implement #2 <#2> in reverse and make eas the 2nd layer based on browser agent strings or whatever. Aside from implementing #2 <#2> if the DB lookups are fairly sane/simple for the opaque tokens I could implement a generic DB plugin as well. Now that infrastructure is all in place creating new plugins is generally 50-100 lines of code. So if it's a simple select and check for existence that would be pretty easy (as in, 30 minutes or less of programming easy). In essence, how difficult would it be to re-implement you existing auth service? There's quite a solid foundation to build from on my side with plugins and custom assertions etc that are all ready to go.. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=AAABZHORKN6NCB5FOMMRMVTPV6CLXA5CNFSM4HNX27R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWHQWQ#issuecomment-493647962>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAABZHM26RGEAIBYPP6NWZDPV6CLXANCNFSM4HNX27RQ> .

[travisghansen]

So as long as your auth service proxy ended up behaving the same as auth services do generally I don't see why that wouldn't work. Meaning, sends headers down appropriately and pushes responses back directly.

General idea would be ambassador is configured to talk to your custom auth service, if it fails or based off user agent sniffing or whatever would conditionally forward down to eas. Basically a mini pipeline idea like exists in this project.

I have been thinking about ways to let 3rd parties inject their own plugins into the mix. While seasoned in programming, node is not my forte by any stretch. I have some research to do to see how to make that sane and dynamic on the technical level.

[travisghansen]

@ajbouh OK, I just committed a plugin that allows for integration with another external/forward auth provider. It's literally (or should be) a proxy of the response from the upstream url.

https://github.com/travisghansen/external-auth-server/blob/master/PLUGINS.md#forward

I still see some challenges for your particular use-case with this as you really want to change the ultimate response based on user-agent (ie: machine to machine vs browser-based). Even before you brought this up I've been think about exactly that since I think it's a valid use-case.

The challenge is sanely determining what's considered "browser" vs not. I'll put some more thought on it but if you have any ideas let me know.

[ajbouh]

For now I'm fine with treating some URLs differently than others. That way some URLs will get passed through to eas and others will just get handled internally.

…

On Sat, May 18, 2019, 16:53 Travis Glenn Hansen ***@***.***> wrote: @ajbouh <https://github.com/ajbouh> OK, I just committed a plugin that allows for integration with another external/forward auth provider. It's literally (or should be) a proxy of the response from the upstream url. https://github.com/travisghansen/external-auth-server/blob/master/PLUGINS.md#forward I still see some challenges for your particular use-case with this as you really want to change the ultimate response based on user-agent (ie: machine to machine vs browser-based). Even before you brought this up I've been think about exactly that since I think it's a valid use-case. The challenge is sanely determining what's considered "browser" vs not. I'll put some more thought on it but if you have any ideas let me know. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=AAABZHJ2HB75ZGJWD7KIG5LPWCJH5A5CNFSM4HNX27R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWX76I#issuecomment-493715449>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAABZHKRTYUZSAHNOBMYSI3PWCJH5ANCNFSM4HNX27RQ> .

[travisghansen]

I have dreamed up a very powerful solution actually. I'll put some more thought on it and implement soon.

In essence what it will allow is early termination of the pipeline of plugins bases on arbitrary assertions. You could for example return the response from the forward plugin when the request contains an Authorization header. Otherwise let the oauth process kick in.

[travisghansen]

@ajbouh ok, I've just landed pcb support. Your use case should be fully supported based on some simple configuration now.

[ajbouh]

Excellent, thanks!

Is there a live demo anywhere I can interact with?

I'm trying to evaluate eas against something like https://github.com/netlify/gotrue-js/blob/master/README.md

[travisghansen]

@ajbouh from just a brief look it appears the 2 projects are trying to solve different things. gotrue appears to be more close related to https://github.com/clems4ever/authelia or something of that nature.

The purpose of this project is to implement a forward authentication scheme using existing standards/tools rather than creating a new one. So instead of issuing tokens for example, I'm focused on simply validating them and leaving the issuing of them to oidc providers, etc. I know it gets a little fuzzy.

So hypothetically, you could use gotrue to issue tokens and then they could be validated by this project (if gotrue didn't/doesn't support a forward auth component already).

Not sure if that makes much sense but as such, this platform has 0 UI at all. There is nothing for users/admins to interact with other than creating the config_token from the cli and configuring their reverse proxy of choice with the appropriate URL.

[ajbouh]

I see, that makes sense now. Do you distinguish between expired vs invalid tokens? What sort of signal do you pass back when authentication is invalid/missing?

…

On Mon, May 20, 2019, 12:37 Travis Glenn Hansen ***@***.***> wrote: @ajbouh <https://github.com/ajbouh> from just a brief look it appears the 2 projects are trying to solve different things. gotrue appears to be more close related to https://github.com/clems4ever/authelia or something of that nature. The purpose of this project is to implement a forward authentication scheme using existing standards/tools rather than creating a new one. So instead of issuing tokens for example, I'm focused on simply validating them and leaving the issuing of them to oidc providers, etc. I know it gets a little fuzzy. So hypothetically, you could use gotrue to issue tokens and then they could be validated by this project (if gotrue didn't/doesn't support a forward auth component already). Not sure if that makes much sense but as such, this platform has 0 UI at all. There is nothing for users/admins to interact with other than creating the config_token from the cli and configuring their reverse proxy of choice with the appropriate URL. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=AAABZHITVA32V4OS4KMJOJLPWL4V7A5CNFSM4HNX27R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVZ3KDI#issuecomment-494122253>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAABZHNRRAEXD637N2B7BWTPWL4V7ANCNFSM4HNX27RQ> .

[travisghansen]

@ajbouh if we're talking jwt then currently the distinction I have is:

1. Return a 401 if basic token verification fails (presuming options are set as desired) - https://www.npmjs.com/package/jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback
2. I just added custom assertions to jwt so if token verification passes but custom assertions fail I return a 403

With that said, remember that this project queues all auth plugins into a pipeline of sorts. So you can auth the same service via jwt and oidc for example (perhaps from the same provider/issuer). With the work I did over the past few days you can:

1. forward the request to your existing auth provider if and only if the request contains an Authorization header of either scheme Bearer or Basic.
2. If the request gets forwarded to your existing auth service then respond directly with whatever it returns (ie: don't continue the auth pipeline if it fails).
3. If the request doesn't contain an Authorization header assume is a browser-based user and authenticate them via the oidc or oauth2 plugin.

If you added authelia or gotrue to the mix hypothetically this project would allow you to mix and match services based on the needs of the particular endpoint (assuming plugins are created for those service or they natively support oauth2 or oidc or something of that nature).