Database design for application with multiple useres We have a task to design a software using entity frame core and a Central SQL DB. The software will have multiple users with RBAC(Role Based Access Control). DB design shall implement user group table and users with many to many relationship.

I've read about RBAC and RLS (Row Level Security) in SQL but I can't link it to code. It will take alot of effort to create secured layer in the Database but I don't know how to use this in the code. I mean putting effort in the database design tables will be implemented in the code using the poco-class but putting all this effort in data security will affect the performance and will make the software very dependent on the the database


How can I implement RBAC in the code?
Where to start searching?
Should I just but my restrictions in the code using the queries and GUI?
Should I depend on the DBMS to manage my security or use it just as a backup layer?
What is the best practice or design pattern for the application and the Database? Should I map users in the database with RBAC and RLS and then just using them to sign in the application?


Note: it is a limited scale project with less than 100 user in the Database using a company intranet
Just to give you some ideas here are some of the ways I have seen this implemented:


all interactions with the database use stored procedures and views to limit access
groups are implemented in Active Directory. Members are added to groups. When a user logs on and is authenticated to the domain by AD the application calls a stored procedure which returns all the groups the user is a member of. The membership is cached in memory for the duration of the session. Behind the stored procedure are tables for groups, users, user => group, group=> permission  (create a unit of work, process, close...)
in the application every time a page or view loads you check what the user is authorized to do.  It leads to some less than elegant code like   IF CAN_READ then ....ELSIF CAN CREATE then....  There are undoubtedly more sophisticated ways to set the permissions.
the database has an active directory group for the administrators and a generic app user with permissions on all the stored procedures. This method means the application enforces the permission structure set in Active Directory not the database.  Others prefer the database to have roles which set user permissions but then you lose your Active Directory Management.