I'm using traefik as a reverse proxy. I want to set OAuth2 authentication for a entry point.
In the document, I found the Forward Authentication which I think may be useful for this. But the document is just too simple
This configuration will first forward the request to http://authserver.com/auth.
If the response code is 2XX, access is granted and the original request is performed. Otherwise, the response from the authentication server is returned.
I've no idea how can I achieve authentication OAuth2 within a forwarding?
I've tried oauth2_proxy but didn't find a solution.
In this issue/comment guybrush provided a solution. But that, in fact, was a double reverse proxys.
I've recently built an app for this: https://github.com/thomseddon/traefik-forward-auth
It uses Forward Authentication, as you mentioned, and uses Google OAuth to authenticate users.
There's an example Docker Compose setup here: https://github.com/thomseddon/traefik-forward-auth/blob/master/examples/docker-compose.yml. See the traefik.toml file to see how Traefik is configured to point at the app.
Let me know if it is helpful!
Instead of trying to make Traefik support your case, let Traefik do what it does best and instead use Keycloak Gatekeeper for authentication (and potentially authorization).
This would change your setup from
Client -- Traefik -- Service
to
Client -- Traefik -- Gatekeeper -- Service
This means that both Traefik and Gatekeeper act as reverse proxy.
It's incredibly simple to model complex auth setups with this approach. One potential drawback is however the additional RP layer, so for high performance setups this may not be an ideal solution.
Note that Gatekeeper can work with any OIDC compatible IdP, so you don't have to run Keycloak to use it.
Related
We have a service that sends delivery notification messages to a client via HTTP requests - meaning, the client must also act as a Server (must expose an HTTP endpoint) in order to receive these notifications.
Some of our clients are asking that our requests authenticate against their endpoints via OAuth. We would prefer to implement this using a third-party so as to avoid having security features implemented in-house (and avoid security issues/not well-handled edge cases that we could end up introducing); More specifically, we'd prefer to have a reverse-proxy.
The idea would be that our service would send a request to the client through the reverse proxy, which would identify that the request is missing a token and would be responsible for getting a token and injecting it into the request.
I googled for this but couldn't find anything; perhaps I'm not searching for the correct keywords. Is there a packaged/"market" reverse-proxy solution for this? Or perhaps a programmable reverse-proxy that could bootstrap a solution for us?
I can see two approaches for this:
have an oauth2 client library in your own code to handle the oauth2 authentication flow for your app. Most programming languages have an oauth2 client so you wouldn't re-implement anything and have a secure authentication mechanism,
use a proxy that implements an oauth2 client so it would do that part of the flow for your service but I'm not sure it exists. I couldn't find anything also related to this because of the fact that most of the languages have an oauth2 client that's readily available.
I hope you find the solution to your problem :)
I would like to deploy this on Kubernetes. Would it make sense for both the Auth Server and the Policy engine to talk to the API Gateway independently or is it more accurate for only the Auth Server to talk to the API Gateway and the OPA to talk to the API Gateway only via the Auth Server
At Curity we have some good resources related to this. Usually the first key consideration is around components that use data sources:
APIs
Authorization Server
These are always deployed with a reverse proxy / gateway in front of them, so that an attacker has to breach 2 layers to access data sources - this is covered in our IAM Primer.
In addition the gateway can then provide some interesting capabilities:
Token Introspection and Caching
Dynamic Routing
In terms of OPA it depends how you will use it - here are a couple of possible options:
Gateway calls OPA to perform high level checks to grant or deny accesx as in this OPA use case
The API calls OPA and passes it a Claims Principal, then uses the response to decide how to filter results, as described in our Claims Best Practices article
I have tried the SCDF Security with UAA + LDAP example (link).
However, Im looking for some more Security approaches while using SCDF local. It 'll be great if having example (source, document)
It is not an official sample, but we have another full-blown UAA based end-to-end solution that works with local, and as well the other platform choices that we support.
See: jvalkeal/randomstuff/dataflow-uaa.
With this, you can run UAA as a standalone process served at 8080, and SCDF+Skipper running separately it can negotiate with and use the UAA backend for authentication/authorization flows. Feel free to customize the uaa.yaml with desired users, roles, and the associated scopes. Once again, all this is outside of SCDF, and it comes down to how much you'd want to rely on UAA like identity providers.
Keycloak is another excellent option for a local deployment experience. I believe there's a Docker image for Keycloak.
I'm looking for an API management system, that will intergrate with Keycloak (Keycloak should provide all of the authentication).
Wicked.io (kong based) looks nice.
I've tried adding oAuth2 as an auth method, but wicked keeps generating its own client ids and secrets.
Is there any way to do this with wicked?
wicked.haufe.io maintainer here.
Combining wicked/Kong with KeyCloak may not be a very good idea. Wicked solves a lot of the problems KeyCloak is intended to solve as well, and the overlap is quite big, e.g. doing identity federation (SAML, OAuth2) to an OAuth2 workflow and all that.
KeyCloak and wicked/Kong follow different principles though; KeyCloak issues tokens which are validated via a KeyCloak library inside your services. This more or less replaces the API Gateway - it's implemented inside your services, based on the KeyCloak library.
wicked/Kong as a contrast is built up differently, where the big differentiator is the API Portal wicked provides on top of Kong and that you have a dedicated API Gateway (Kong). Wicked provides you with its own client credentials, and it also wants to do the entire authentication and authorization bit. What you get in exchange for that is the self service API Portal; if you don't need that, you will probably not need wicked.
What you can do is to federate a KeyCloak OAuth2 flow into wicked, by having KeyCloak act either as a SAML or OAuth2 identity provider. You would then register your KeyCloak Authorization Server as an identity provider with wicked (using a single service provider (SAML) or client (OAuth2)). The "but" here is that you would still need to provide an entry point to your services which do not go via the KeyCloak library.
wicked/Kong always works like this: It takes away the need to implement Authentication/Authorization inside your services; instead you need to check for the headers X-Authenticated-UserId and X-Authenticated-Scope. With wicked, this will typically contain something like sub=<some id>, also depending on which type of identity provider(s) you have configured wicked to use. But this approach usually replaces KeyCloak. The upside is that you can have one single entry point to your services (=Kong), and you have a quite lightweight way how you can protect arbitrary services - not only services written in languages KeyCloak supports! - behind an API Gateway while providing self service access (with configurable plans, documentation,...) via an API Portal.
All these things are obviously somewhat complicated; wicked is extremely flexible in its usage, but it's not really meant to be combined with KeyCloak (which is likewise. It all boils down to really understanding the use case and finding a solution architecture which solves your use case in the best way.
If your use cases involve an API Portal and API documentation (it should), going wicked/Kong may be a good possibility. If it doesn't, you may be happier sticking to KeyCloak (which you can see as a headless API Management system with a decentralized gateway of you want).
Disclaimer: My knowledge on KeyCloak is somewhat outdated; it may be that there are updates which also go into the API Portal direction, but of this I am not aware.
I want to replace haproxy with traefik. But in order to that, I have to replace a Lua script which handles authentication (via auth token calling a rest API) and custom redirect (certain docker service) depending on headers and authentication from before.
Is there an (easy) way to that?
Right now as for migrating I was thinking to leave haproxy for now and routing all valid traffic to traefik.
Authentication and Traefik is not an easy thing. At my company, we just switched back from Traefik to nginx since handling ldap/kerberos/pki etc. With Traefik can be painfully awkward. There is the possibility to pass authentication on from Traefik to a 3rd party and collect the session token or other relevant information using Forward Auth, so maybe take a look at that. You can also use BasicAuth
Although getting it to run with your setup might prove hacky.