Sphinx TUserRoles etc. & handling access rights

BIZ TMS Sphinx
1

Suppose I have an XData server and I want three levels of access rights to the API. Let's say User, PowerUser and Admin I can then control access through the EntityAuthorizeScopes attribute. For example:

  [Entity, Automapping]
  [EntityAuthorizeScopes('User', EntitySetPermissionsRead)]
  [EntityAuthorizeScopes('PowerUser', EntitySetPermissionsWrite)]
  TMyEntityClass = class

The XData server can access the database with a single (DB server) user account.

In the SphinxConfig.OnConfigureToken event, I suppose I can add the claim(s) to pass the user level(s) to the XData server.

Looking at the database generated by Sphinx, I see various tables that seem to associate users with roles and claims (all empty by default):

image
image199×166 3.68 KB

  1. Is there any documentation on these tables (or associated entities: TUsers, TUserRoles, etc.) and how these work together (e.g. a data model)? I have looked everywhere but I cannot seem to find anything.
  2. Are these entities (tables) indeed meant to be used for scenarios as described above or are they reserved for other purposes?
  3. Must I 'manually' add the claim (e.g. 'PowerUser') to the token in the SphinxConfig.OnConfigToken event or is this done automatically by Sphinx if these tables (entities) are populated? Tables like sx_role_claims and sx_user_claims seem to suggest something to that extent...

Thanks for clarifying!

1 Like
2

No, there isn't.

They are intended for that, but not implemented yet. Reserved for the future.

Yes, for now.

3

OK, I'll do some experimenting to see if I can figure it out myself.

Once I have something, I'll upload it to see if it is "as intended" or "as planned".

1 Like
4

@wlandgraf

Can you provide an outline of how you see these being used and when it is likely to be implemented? We are in the process of redoing our permissions in our apps and so an indication on this would be much appreciated.

Thanks.

5

In the current structure, a user can have many roles, and each role can have a list of claim names and values.

So, when a user logs in, the access token associated to it will have the combination of the claims defined in the roles associated to the user.

Maybe we will also add a list of defined scopes for each role.