Userservice - Part 1
- 20 May 2018
A few weeks ago a good friend of mine and me had a discussion about the usefulness of frameworks and libraries mixed with the desire “to know how things work” and such build them yourself.
For a certain application the userhandling was still one of the missing pieces and I suggested “why not use one of the many frameworks available for golang”, since quite a few popped up during an initial search - the awesome go lists some of them in a section. He replied “well, user handling ain’t that complex and I want to know how it works anyways”. Both valid points. Since my view was only based on some quick searches (in regard to the golang side of things), I felt that it could be worthwhile to validate my assumption. Definitly not to proof my point but moreover to learn some more about golang and its ecosystem.
What features would I want to have in such a user handling layer?
- local users (so we don’t rely on an external user directory, one of the things that annoys me about the IDB since it raises the bar for quick installations)
- possibility to hook into a user directory such as Active Directory, OpenLDAP
- later-on: possibility to add OAUTH2, SAML or similar
- role-based permission model
- in each tenant each user can have any role, eg. no special ‘head-users’
- a user can be part of N tenants, eg. is able to switch tenants or do searches across all tenants items
- self-service (“I forgot my password’)
- allow for addition of two-factor auth
First step: based on these wishlist items, look for the framework to use.
I will track the progress with a series of blogposts.