antal.szabo

that is right, hence why I'm asking for help

I'm not sure you understand what I'm asking

I guess I need a custom RoleManager probably

as I mentioned, I do not see an API where I could directly pass in a list of associated roles when calling Enforce, could you point me to where this is documented?

I thought this channel was for getting help...

I did

what I found regarding this

I don't really want to add an additional layer of complexity/deployment here, so would prefer to do it directly

I already should have the list of roles from a jwt, or I can get them from Microsoft, that's alright; but how exactly do I call the Enforce API? Just call it with the role name as sub?

Isn't Casdoor a separate service to set up?

Hi everyone! It's my first time using Casbin, and I'm not very experienced in implementing auth{n,z} systems either, so I would like a bit of help. I'm writing an API + SPA that needs to work with Microsoft login only (so no other system, password login, anything). Currently my understanding is that the OIDC / OAuth flow will be handled by the frontend (at least this is what ChatGPT told me to do) and once that is done the frontend will pass a JWT to the backend. How I need this to work is that user roles are defined and assigned in Microsoft AD, so the JWT would contain I guess the user's identity, and their authorized roles.

Here comes the relevant part: Once I have a user ID and a list of roles, how do I pass this to Casbin for authorization correctly? I want to be able to write policies based on roles, but also based on specific user IDs for exceptions.

One solution I've seen in a middleware implementation is that the user roles are tried in a for loop, passing each one to the enforcer to try to authorize it. I guess this works, but seems like it could cause problems in case of more complex rules, for example if there are deny rules.

The other solution I can think of is to use the RBAC APIs to call AddRolesForUser on every request on-demand, then DeleteRolesForUser at the end of every request (to prevent lingering roles in case the source of truth changes). Apart from this being a bit strange and seems kind of a misuse of the API, I'm also not sure this would be concurrency-safe. Currently I'm creating one enforcer at the startup of the service, and passing that around, I guess I could create one per request instead.

What would be really nice for this scenario is to be able to pass in a list of roles for the Enforce(...) call.