SmartClient and RBAC (Role Based Access Control)

[claudiobosticco]

Hello, we're thinking of redoing are access control system, with a RBAC approach implemented in a relational db.

I'm thinking how to best leverage it in SmartClient applications, so I'm looking for suggestions/opinions from who has already tackled this issue, ie Isomorphic and the forum community.

Currently, we're using roles with the various *requires* attributes for dataSource/operationBinding/dataSourceField. To me, it seems that we may leverage better a RBAC system if we simply check the permissions in an override of IDACall.handleDSRequest. At that level we know the dataSource, operationType, operationBinding, and even a field-level control seems feasible.
What do you think?

Also, I'm wondering how to best leverage it client side, and here it seems that the best bet is using the new Authentication class. Does it make sense?

[Isomorphic]

Hi Claudio,

We would recommend using the requiresRole and related properties anywhere you can, including things like dataSourceField.editRequiresRole, because this results in declarative XML that expresses security very clearly and concisely, in a way that even non-programmers can understand.

Then, if rules are more complicated that just a requiresRole setting, you can use a few different approaches:

1. use Server Scripting to express rules - especially good if the code involved can be simple enough that again, non-programmers can read it

2. set up variables to be used by Velocity expressions like requiresRoles - another way to make things simple enough for non-programmers to read. You could set up the appropriate variables in an IDACall subclass via dsRequest.addToTemplateContext()

3. finally, if it's more familiar, yes, just implement the rules as either DMIs (if they are method-specific) or in a general IDACall subclass (if they span lots of DataSources and neither of the above approaches are warranted)

As far as the client-side, yes, we would absolutely recommend populating the client-side Authentication class with the user's current roles. That allows you to easily use roles to declaratively control visibility or enabled state via eg button.visibleWhen and button.enableWhen, and also sets you up nicely for using Reify screens in the future.