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.
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 :)
Google's CloudRun is capable of redirecting http to https without any configuration. I was not able to find any solution that would instruct CloudRun to respond 301 Permanent Redirect to all non-www requests.
I was able to instruct CloudRun to handle both www and non-www but without redirection.
I am familiar with how to set up the required logic with nginx and a traditional server. I could also do this in the application itself but since CloudRun is a serverless product, it would be better to handle this state before the app is even invoked.
Thank you.
When you reach Cloud Run, you first lands on GFE (Google Front End). This layer ensure the security (if you set your Cloud Run service in no-allow-authenticated mode, perform DDoS mitigation at Google grade, expose and manage the SSL certificates, route the request to the correct services,...). So, a lot of job for this layer but you can't customize it.
If you want to add customization, you have to add a new layer, a HTTPS Global Load Balancer. Now you can define serverless NEG backends to reach serverless product (Cloud Run, Cloud Functions, App Engine).
It doesn't offer as much as customization as a NGINX managed by yourselves, but you can perform more things.
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'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.
I am working on an asp.net mvc-4 web application and I have started implementing some web services which provides statistical information about my site. But to make sure that only authorized and authenticated consumers can call and consume the web services I am thinking of defining a master login username and password for each consumer, and when a consumer sends a web service request he should include these master login username and password (stored as a hash value ) in the web service calls.
For example the web service link to call specific web service from my web site will look as follow:-
/web/json/statistic/getsummaryinfo/areacode?j_username=masterusername&hash=D012B772672A55A0B561EAA53CA7734E
So my question is whether the approach I am following will provide a secure solution to my web services and to the consumers? OR my approach have security holes I am unaware of ?
:::EDITED::
I am using the WebAPI controllers to implement the web services inside my asp.net mvc-4.**
Best Regards
There are a few ways to make sure things are secure.
http://techcrunch.com/2012/11/08/soa-softwares-api-management-platform-and-how-it-compares-to-its-sexy-counterparts/ This article just came out today highlighting some API tools. I'm not sure how big you are or are planning to be, but if you're looking for scale, these tools seem to be pretty popular (note: I haven't had a large scale API project myself, so I haven't used these).
You can use something like ServiceStack to build your API layer. It has authorization and authentication built in with a boatload of authentication providers. It scales well and, after a call to authenticate, is session-based so you don't have to authenticate each call.
You can use "signed" requests. Signed requests often look something like: "take all the parameters for the request as a querystring, append a 'secret consumer key' to the end of the request', and then sign the request by appending the md5 hash of the results (without the secret key!!) to the request." This is a safe way of doing things because even if the request is made client-side (AJAX) it is generated server-side using a secret key. So you can ensure that things weren't tampered with.
You can go the oauth/token route (which often still uses method #3 above).
You can go with a simple API key that can be revoked (again, fotne used with method #3). bit.ly uses this method I think.
Option #2 is my favorite. I like ServiceStack. But to be honest the learning curve for your first project can be a little steep.
A master username and hashed password feels weak to me, so I'd strongly consider at least looking around at how others are doing it.
HTH
I do not consider your way to be safe. If I could listen on the wire and cache the request I will have the login an the password to the service. There even does not matter if the password is hashed or not. I like the point 3. in Eli Gassert's answer. It sounds very useful and light weight and you are not exposing the password because it is hashed "somewhere" in the request.