Yes, but it would be correct to also write the same Id in AccessToken's User claims so that the Id attribute of casdoorsdk.User structure for in/out operations is the same, isn't it? To resolve this inconsistency, it is better to separate the two structures: one for writing to JWT Claims (with an Id assigned by casdoor), and the other for user modify operations, which will not have the Id field since it is immutable.
Hello, guys! It seems that I have found some unexpected behavior when using the casdoor-go-sdk: when parsing the accessToken JWT, I get a casdoorsdk.User{} structure with the Id attribute, which is set by casdoor itself. Then, I want to call the casdoorsdk.UpdateUser method, passing a reference to the new casdoorsdk.User structure with the Id and Groups attributes set. However, the method returns an error "The user: / doesn't exist" because it uses its own Id generated from the combination of the Owner and Name attributes (https://github.com/casdoor/casdoor-go-sdk/blob/348c6d99dc24fd6f66e39ced23e41137715c7765/casdoorsdk/user.go#L442). It seems that is not ok, and I can make a PR to fix it.
P.s.
Checked in other SDKs, the situation is the same there.
And in each organization, is there an opportunity to assign a separate role from the list that is shared between all organizations in the tree?
Well, I’ll try 😅 I need to differentiate access to tenants between users. Each user can belong to multiple tenants in different roles (in one tenant, the user is an administrator, in another, just an editor). My hypothesis on how to do this: a “tenant” is a group in Casdoor, and in the user's profile, the groups field lists all the “tenants” user has access to, and the roles field lists their roles in these groups in the format "admin_of_groupXXX", "editor_of_groupYYY". Access control is managed through the built-in Casbin. This approach has a drawback - we don't have shared admin/editor roles, and new roles are created for each group, which can be cumbersome. Do you have any ideas on how to simplify this?
Hey, Guys! First of all, I would like to express my immense gratitude for creating the product and releasing it as open-source - what you're doing is incredibly cool. Secondly, I would like to ask for advice on organizing authorization in my application from people who understand the product much better than I do after a quick read of the documentation.
Introduction: we are developing an application for collaborative work, that is close to Notion, Google Docs, or Miro, where a domain model of the "project-workspace" format is assumed:
- When a regular user signs up, they are assigned a project in which they can create multiple workspaces and invite other users to their project, giving them access to view/edit the workspaces.
- When an organization consisting of multiple users registers, they are also assigned a project. When users log in via SSO, they immediately see a list of available workspaces, and the organization's administrator can modify the rights/roles of organization members in the project.
Here's how I envision this authorization model using Casdoor:
- For regular users, a single shared organization and application are created in Casdoor, with the ability to sign up using email+password and several social login options. Access control to projects is implemented using groups (each user has their own personal group created during sign up or initial login, where they can add other users to that group via our service's API). In this scenario, the only option for access control seems to be creating separate roles (admin_groupId, editor_groupId) for each group and configuring RBAC through Casbin - however, this approach seems overly cumbersome and heavy to maintain.
- For each corporate client (company), their own organization and application are created in Casdoor, with the ability to log in exclusively through corporate SSO. In this case, it seems that groups are not needed, and it is sufficient to simply create roles (admin_organizationId, editor_organizationId) and configure regular RBAC.
Am I thinking correctly, or are there alternative ways to configure Casdoor for such an authorization scheme that would be simpler to maintain and more concise in terms of architecture?
