Are you building an app where users can play multiple roles with different levels of access to many resources? If so, how do you manage the link between users and actions they’re allowed to perform?
I suspect you either wrote a solution to handle this yourself, or were going to. From my own experience, this problem starts simple but it quickly gets complicated. In the end, you’re left with database optimizations, migrations, and a potential security nightmare.
It seems that there is usually an instinct to build even when alternatives exist. I'm trying to figure out if that's also what many hackers are thinking around this topic as well. Perhaps it isn't on anyone's mind how to do this and which case, whatever. But maybe it is.
My validation is simple, our team has been encouraged to expose what we write as microservices as possible external products. I really like what we wrote for this, but I'm not sure anyone else would. Since I'm all for experiments, perhaps I could propose that you use the API I’ve built temporarily for free. That would possibly make it sure sure it’s a solution that actually solves a real problem and not just our internal one.
(I tried posting something similar on reddit and did not get a good response :(, I'm hoping here will better for me.)
Hi Warren,
We're thinking through these problems now. Your solution resonates with us, but I don't think it will resonate with the majority of hackers on the MVP project. This is OK.
Thinking about security too early is classic over-optimization. But I'm seeing more hackers embrace (for instance) social media login over login and password because it's both easier to start, and easier to maintain over time than rolling their own auth systems.
For who is multi-tenancy a problem from the get go?
It is for us because we focus on b2b information sharing.
Our permissions need to exist on many different levels (user, org, groups, updates, metrics, actions). And we don't yet have security experts on our team.
Despite us having the exact problem your selling, we have a few immediate concerns:
The biggest concern is the fear of investing time or money in a solution that ultimately won't work.
Building your marketing (segmentation + copy + design) and exploring a hands on sales process could be a decent way to build adoption. Also - having a very generous free tier to remove some of the perceived opportunity cost.
If you'd like to chat more: marcus@venturemark.co
I am building an Auth service that converts various Authentication protocols (oAuth, SSO, Email/pass) to JWT. This lets you have a single login for all of your apps and even supports products like Google Firebase or Hasura.
My email is kevin@sparkstart.io if you're curious. I'd love to learn more about how you're thinking about auth.
That's really great to hear. We were also thinking the solution best helps in the multi-tenancy world as well.
You are asking the difficult right questions :). I'm happy to delve into them in more depth for anyone that is interested, to quickly touch on a couple of points:
We definitely want to bring the bar down when it comes to migrations, either to what we provide or away from. (If a customer wants to leave, it doesn't make any sense to try to make it difficult. We understand when it may not be a good fit).
We have something we just put it, I'm not sure if it will resonate with you, but I definitely suggest checking it out: https://authress.io. I will also send you an email.
I recently finished a short MVP where we addressed this issue. We built a bunch of webAPI's to surface the simple data CRUD operations, and restricted access based on permissions/claims (ie. read:events, create:events...etc). We then created RBAC roles within Auht0 and assigned the appropriate permissions. Simple...
How do you handle needing to control access at the record/resource level?
I do provide a basic user system for userTrack.net, although it's not the main focus of the app. Not ideal and might pose some security issues, but it does it's job for now.
I implemented my own system, I have a number of levels (0-5, where 5 is admin) and actions. Each action is usually a separate PHP file, and the permission is checked at the start of the file. So it looks something like this:
An example of the line that has to be included to check for permission:
What happens when you want to give someone the ability to add a tag but not delete recorded client, is that possible in that system?
I would but
ADD_TAGto level 1.I decided to use this level system instead of a more granular action access as it makes it easier to understand what each user has access to, and most of the platforms I know also have a similar permission structure (eg. user, moderator, administrator instead of giving access to specific actions). I think this also allows for a more logical structuring of permissions, so for example, you know that if someone can add a user then it means he can delete one.
But that would cause everyone with level 1 to gain that ability. I'm suggesting that You want to give it some people with level 2, some people with level 3, but not to all people with level 2 currently. How would you go about that?
Also what happens when you need to create a level between 3 and 4, do you run a database migration to swap the value assigned to each user?
It's not possible, that's a limitation of the system I decided on when designing it (as I mentioned in my previous comment)
The system could be changed to have granular permission, just use a bitset in the database and for each permission set the bit to one, but in my case, that type of granularity is not useful and makes it a harder to manage roles.
It's like IRL, when a specific position or role gives you access to specific actions and information. (eg. You're a teacher in a school, all teachers have the same rights)
For teachers though, don't you need to control access at the resource level? I.e. don't teachers in different departments have access to resources in that department. Science teachers need access to chemistry labs, whereas others do not. And how about homerooms, do teachers have offices that only they can access?
How do you handle substitute teachers?
I was thinking more of elementary school teachers, where they don't have a specific role, but your example makes sense. I do thing that in software usually in that case you would just create a key that works for all departments and all teachers have access to all departments, as they are trusted.
I didn't think about this use-case, but it feels like it's really enterprise-oriented, as most web applications usually only have "one department" and if you had more (eg. Google Ads Admin and Google Maps Admin), they will just be 2 different apps instead of the same app with 2 different user categories (Ads Admin access and Maps Admin access).
I am not sure what the substitute teacher equivalent would be in my app, maybe that I can always add and remove a role?
In my 3 previous jobs, as a team we implemented custom and similar solutions to the problem you explained.
I think solution is called RBAC. The problem is, every organization is different and it can require custom levels or schema of authorization. For example in one of my previous jobs, we created a schema that involves 'location, company, user, role, permission, and asset'.
For your information, there is a powerful open source solution, Apache Shiro, to implement multi level authorization concepts.
But in the future I may consider choosing a SaaS that provides flexibility, security, and easy of integration, instead maintaining it myself.
Sure every system is different, the question is there a way to map it to something that makes sense giving the product model and still extensible.
We are definitely at this point, I guess the question is what would change before it "becomes the future", what would be holding your product back from using a SaaS solution already today?
The thing that holds me is, I was using .Net Core and they have built-in simple solution for role management. It was enough for my project so I went with it and built everything on top of it, without abstracting that layer.
This is a common problem for any multi-tenant application. There are many companies working in the field oAuth0, Okta, plus many solutions like Firebase Auth/Security Rules that are tied to specific stacks. One of the questions you'll constantly have "why should I learn a new technology from somebody I don't know or trust? How hard it will be to integrate into our stack?". I would suggest you find some software stack and integrate with it to pretty much "one-click" solution and try to sell it inside their twitter, discord, groups, or any other channel they use to discuss their tech stack.
Having used most of the options, not sure any of those offer the kind of granularity that most apps need. Sure if you want to validate user <=> DB row that's usually easy, but multi resource checking and resource hierarchies aren't usually provided. Auth0 and Okta don't offer anything like that as far as I know.
Your idea about integrating into some stacks is interesting. Which stacks do you use for your products?
I'm using Firebase and/or Clojure/ClojureScript w/PostgreSQL. Depends whether I need back-end or don't.
My suggestion for you to put your advantages in the top section of your website. I briefly looked over the website and wasn't able to build a full picture without going into details too much.