I'll be refactoring a large system with fairly complex business requirements that could also change in the future and we already have a type of resource-based auth that's poorly implemented. In essence, I need to have fine-grained control over user access on a item-per-item basis. If our database has, for example, books, authors, publishers I would need the capability to:
- Give a user read access to all books by authors
XandY - Give a user write access to books
book1,book3andbook72 - Give a user read and write access to all books from
publisher1
Since the data is quite dynamic the access needs to be evaluated on each request by any user. Permissions can't be cached. There can also be quite a few resources, in the ballpark of 10-100k items.
I'm researching the best way to do this. I'm assuming there are open source and paid solutions for this though a quicky google search didn't come up with anything too useful. Perhaps I'm using bad keywords.
I was looking at keycloak but it seems quite unwieldy. I need to create each book/publisher/author as a resource in keycloak. It also seems like I also need to add a explicit permission for each resource/user combination AND that there is no simple way of modeling the relations between the resources to grant access to all books sharing a publisher. Might be wrong on that. The fact that I have to keep my data up to date between my database and keycloak seems like bad practice and, it seems like keycloak is just a hindrance here.
From what I've seen so far, it seems to me like the best solution would be to write my own auth logic and use keycloak or another service only as an identity provider. Since performance is important, I'd wager I could just keep the user permissions in my PG database alongside my actual data in the form of many-to-many tables and evaluate access using inner joins in the actual query fetching the data from PG. Am I missing any reason why this would be a bad idea?