A detailed guide to SSO on Kubernetes
talkingquickly.co.uk
talkingquickly.co.uk
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:
https://en.wikipedia.org/wiki/Thawte
Starting a "high trust" business from one's basement is perfectly fine.
That being said, a far more important point is testing / validating the existence of an actual market for your product.
Whether you build your solution out of your basement or a lavish penthouse office is irrelevant.
The best and brightest team working out of swank office space will still fail if the market for their product doesn't exist.
Hope that helps :-)
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.
Before you can answer that - how do you differentiate from the existing competition? What's your target customer?
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.
Right now I'm looking towards https://github.com/sonicnkt/glauth-ui/ to solve that problem, but it's definitely not anywhere near there yet.
Perhaps you could enlighten us with a few key differentiators of your ideal solution to other common ones?
I have it in production at work. Three instances, clustered (infinispan), running in docker containers orchestrated by kubernetes.
Each instance (pod) is upper-limited to 2gb ram (or 3, can't recall the details now).
It works very well and very reliably, serving about 750 users (as in, real people).
If you have 2GB to spare and a physical core, you can run keycloak with no problems at all.
After all, it all depends on the amount of traffic. Little traffic = little cpu load.
Don't dismiss keycloak because it's written in Java... Quite the contrary, you can tune the JVM to work with little memory (-Xms -Xmx iirc).
Ten years ago it was very common to see tips and tricks to make grails web apps work on as little as 64mb of ram on chap VPSes.
https://github.com/ivangfr/springboot-keycloak-openldap/blob...
So now I need to look up the default values for
Vendor, Username LDAP attribute, RDN LDAP attribute, UUID LDAP attribute, User Object Classes, Connection URL, Users DN, Custom User LDAP Filter, Search Scope, Bind Type, Bind DN, Bind Credential
If I knew what vendor openldap was considered setting the Vendor would fill a bunch of of those in. Well let's try following through this this random blog post and hope it works: https://geek-cookbook.funkypenguin.co.nz/recipes/keycloak/au...
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.
Regarding RAM, Wildfly uses 650MB. Keycloak.X is a new, more lightweight approach using Quarkus.
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.
In the meantime people are already offering managed keycloak instances as a service.
they look fine, and they look like they already have customers.
I've written more about Authorization Services: https://gruchalski.com/posts/2020-09-05-introduction-to-keyc...
And can recommend these resources: https://www.janua.fr/tag/technical-blog/
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.
The GPL allows you to copy & modify code for your own desires very generously.
The limitations you fear apply if you distribute the code (in source or other forms) or modifications yourself.
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.