User story #2595: Managing user authorizations - Rudder - Issue Tracker

Actions

Copy link

User story #2595

closed

Managing user authorizations

Added by Vincent MEMBRÉ over 12 years ago. Updated about 12 years ago.

Status:

Released

Priority:

N/A

Assignee:

Vincent MEMBRÉ

Category:

Web - Maintenance

Target version:

2.4.0~beta3

Pull Request:

UX impact:

Suggestion strength:

User visibility:

Effort required:

Name check:

Fix check:

Regression:

Description

every users should not be able to access every parts of the web application.

There must be numerous permissions so that users could be personnalised.

Depending on the user roles/permissions:

Some pages should have a restricted access.
Some features on some pages sould be masked.
Some actions should be forbidden.

Subtasks 1 (0 open — 1 closed)

Actions

Copy link

Updated by Vincent MEMBRÉ over 12 years ago

We should define roles/permissions for every users in webapp

Lift Sitemap Would provide us access control for every page in Rudder webapp. we could redirect some users if they don't have the permissions to see that page,
plus it would remove from menus every link to those page, hiding the page from them

we should check permissions for each button we want to hide, if the user have not the permissions then hide the button!

Actions

Copy link

Updated by Vincent MEMBRÉ over 12 years ago

Status changed from New to Discussion

I implemented those roles :

"admin" : access to everything
"user" : access to everything but administration
"administration" : only administration
"report" : everything, but can't do any modifications
"none" : nothing

I plan to add a "non editing" role. a user which can't edit rules.

Plus custom role are permitted, specifying the different permissions wanted

Do you have any ideas for more roles or specific authorizations ?

Actions

Copy link

Updated by Jonathan CLARKE over 12 years ago

Be careful "admin" and "administration" are too closely named to be clear. How about "Administrator" and "Administration only"?

"report" would be clearer as "read-only", since "report" has a different meaning in Rudder.

"inventory" could be a good role to have, which could only search nodes and see node details.
"configuration" could be another good role to have, which could not see node details, just edit techniques/directives/rules.

Actions

Copy link

Updated by Vincent MEMBRÉ over 12 years ago

Status changed from Discussion to Pending technical review
% Done changed from 0 to 100

Applied in changeset 29271c3baa27d706b05bb849c27f82b7af8353e7.

Actions

Copy link

Updated by François ARMAND over 12 years ago

Status changed from Pending technical review to Discussion
% Done changed from 100 to 80

That's a really good commit, thanks Vincent.

Some enhancement required:

the "regenerate now" button should only be available for some role, perhaps even a dedicated role (which could also view not yet applied configuration)
in node details, there is a "delete node" button that should not be available to read-only role (and perhaps other ?)
in techniques, there is a "reload" button that should not be available to read-only role (and perhaps other ?)
in administration, read-only should not be able to see anything else but EventLog submenu.

For the future, some remarks:

for now, we just have limited access to some UI things, and of course, that's not sufficient (user may want to forge HTTP request, for example). So the next step will be to add authorization business-logic wide, and that will be funny ;
I believe that in traditional RBAC, roles are in a lattice so that we can find the max lower bound and the min upper bound of several roles:
if we want to be serious about authorization, and clearly entreprise ready, we should use some XACML rule engine.

Actions

Copy link