Not sure if we have/had the same goal:
In need for a single password for my users for multiple (web)services I host, I had a look at LDAP (in the end not even sure if it would have been a good solution), did not like it very much and ended up using https://www.keycloak.org/ as identity provider, SSO- and TOTP-provider and like it quite a lot.
It also has a self-service-module:
@hanser hmm thank you, this looks quite interesting.. i have deployed a testinstance and will have a closer look tomorrow... i guess the usecase is similar: groups (communities) of users shall get one login for multiple services such as nextcloud and matrix, and they should be able to modify things like mail and password by themself. it seems like keycloak can do that, yay :)
Sorry for quite never answering your calls for software recommendations directly but more with a: "Hey, have a look over there..." -- to address the issue from a different perspective -- which you did not ask for in the first place.
I think this was pretty similar to the situation which led to your exploration of invoiceplane/invoiceninja. Do you have invoiceninja in use now, by the way?
@hanser i am confused... but its past midnight ... yes, i do have and use incoiceninja now. v5 is still at a young state and it shows at some places, but overall it does what i need and stuff
I was talking about this: https://hofra.rocks/web/statuses/105860595180086613
You were asking for some libreoffice support and finally installed an invoice-framework
Oh and just in case you also get to that point.
One thing I got wrong about keycloak (if I finally got it right -- maybe I'm still wrong) was to think that I can incorporate different rights to different users/groups directly from within keycloak. So, to allow access to one service and deny access to another.
Instead, on correct authentication, Keycloak will always forward a login request to the service (including an identifier: name, email, id,...) and the service itself then has to decide which rights (if any) this user has. So it really is just an identity provider and not an authorization framework. Which I hoped for it to be for some time.
@hanser thanks for the warning, i don't think this would become a problem for my current usecase... but isn't this what roles do somehow? i also found https://www.keycloak.org/docs/latest/authorization_services/
what i currently try to understand tho is how i should use realms... https://www.keycloak.org/docs/latest/getting_started/index.html#creating-a-realm-and-a-user makes it sound like i should create one realm per user? i would have created them as kind of usergroups: "communityX" and so on... but yea i really gotta go to bed
I think you are right about the roles. Now I also remember my tests back then. The problem was to make the connected service (client as they are called in kc) care about the roles at all, which are basically just additional parameters the client gets during login.
For me it was way easier to just use the authorization-features of the client itself to add rights or groups to the (properly authenticated) kc-user than to use the kc-roles.
Regarding the realms, I definitely only need one, because it is for one small organization.
Multiple realms can come in handy when you have groups which are not related in any way and you can easily separate them.
The clearest division would be when a friend (totally different users and also services) asks you to also run his kc-instance on yours -- which you could separate by realm then. When you have either overlapping users or clients I would rethink this decision... I guess.
@milan well, there is a readymade #openldap docker container available at my github (or rather, three - each branch contains different data...) and i have built a generator that spews out complex yet consistent ldif files ready to import for testing - ibdont know if this would help? the repo is here: https://github.com/elbosso/docker-test-openldap
and maybe also interesting: a #java library to search in #ldap via #sql : https://github.com/elbosso/openldap-jdbcldap
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!