Yup agree, that's exactly what's being used here, along with some tweaks to make it easier to do things like passing the auth JWT's back to the underlying app etc
My dream is to one day create an SSO solution for companies. I've been doing research for a time being, but I am worried that I wouldn't find any clients, because who would trust an SSO created by one guy in his basement?
I think the first step to overcome that would be having a completely Open Source solution, but how to avoid other companies grabbing it and selling as their own?
Or do you think it is better to develop it anyway and then worry about customers later?
> because who would trust an SSO created by one guy in his basement?
If you think you've got a good idea and a unique proposition - and your technical skills are up to scratch - then don't worry about starting out from your basement.
Have a look at Thawte Consulting - a certificate authority founded by Mark Shuttleworth in his parents' garage - which he later sold to Verisign for $575 million dollars:
The smaller scale homelab/selfhosting people really need a better solution. I think open source developers do as well.
What we really need is a small easy to set up solution that provides a clear way for us to integrate our app into it.
My ideal would be something that
* Supports ldap and OIDC
* Can be deployed to docker using one compose file
* Only needs to support hundreds of users (keep it simple, easy to deploy, and able to run on a raspberry pi)
* Provides basic user management, I want to be able to put users into groups and (if the app supports it) use those groups for in-app ACL.
If that service worked well in my homelab (a single-pc docker swarm that runs a few private web services like jellyfin) I'd very likely end up deploying it on my employers infrastructure. My employer is a small business with maybe ~30 users.
I'm not sure how to convert something like that into sales though. Still, starting with an open-source solution that solves problems for the little guys often has a "trickle up" effect.
Okaaay, now I have a keycloak server and an ldap server running. I guess my next step is to shell in to the ldap host, wget https://github.com/ivangfr/springboot-keycloak-openldap/blob..., edit it to my needs, look up how to generate openldap password hashes, go back in to keycloak, and try to configure that to talk to my ldap server.
Compare that to the experience of deploying say, wordpress. And hey look, it already comes with an authentication backed!
Sure, you can build something that does more or less the same thing but you have to do a fair bit of work to get to that point. Realistically if you haven't done it before, and if you don't have any ldap experience, you're looking at a solid couple of hours to get that set up.
And it's still apparently going to use 100s of MB of ram.
Where as wordpress goes up in a few minutes, handles user account but uses less ram, I don't really need to do any extra work, and I'm confident it's going to work.
I'm not looking to build a skill, I'm looking to just have an auth server I can use and that I can link my own apps against easily.
As an aside I had seen that one before and it is workable, it's just a lot of work to get from there to an actual working deployment I can use on my home server.
>because who would trust an SSO created by one guy in his basement
You don't have to tell everyone that you are one person company operating from basement. Why not use phrases like "our company", "our clients", have different email addresses like support@, sales@, hr@ subtly insinuating there are more of you, use picture from photobank when listing address of your company's headquarters(basement) etc.. You won't be first nor last person doing this.
And Open Source/Proprietary doesn't need to be either/or problem. You can dual license it as AGPL/Proprietary and make contributors sign CLA.
Personally, I think the answer has to come from your customers. If the pain you're solving is great enough that they want it, but the only showstopper is future-proofing, then you might be able to work with them to find a solution.
It might be a case that you deploy into their infrastructure and give them a licence to use the source code should you shut down.
The current business players in the space all range across the spectrum of closed blackbox Saas (Auth0) to open core / open source (HC Boundary, arguably)
Before you can answer that - how do you differentiate from the existing competition? What's your target customer?
I read the headline, "A detailed guide to SSO on Kubernetes", as "A detailed guide to Single-Stage to Orbit on Kerbalnetes" and was thoroughly disappointed after clicking.
Does anybody have a good, comprehensive guide to Keycloak? I looked at it a while back and it seemed like a giant web UI with a million poorly documented knobs, but I keep seeing people who claim to be using it. I've used Auth0, Okta, Dex, and ORY and none of them seemed quite as incomprehensible
Keycloak is designed to be super flexible and support almost every combination of auth methods out there. A lot of companies don't need this kind of complexity though, which is where something like Dex may be more appropriate--it's quite a bit simpler.
Edit: Keycloak is licensed with the Apache 2.0 license, so none of this is relevant for Keycloak.
GPL is only a problem if you import or change the source code. If you just run it in the backend, as a service, you're most likely fine.
If you customise Keycloak through code, you're probably in GPL violation territory. With the customisability of Keycloak, I doubt that this is something many projects will ever run into.
That's true; assuming you run the software on your own premises, GPL won't hurt you at all. If you sell premium software packages to be run over at your clients' hardware this can be a problem, though.
However, after looking into Keycloak more closely, the software seems to be licensed with the Apache 2 license, so none of this is a concern.