Project

General

Profile

Actions

User story #2595

closed

Managing user authorizations

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

Status:
Released
Priority:
N/A
Category:
Web - Maintenance
Target version:
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 open1 closed)

User story #2621: Documentation about user authorizationsReleasedVincent MEMBRÉ2012-07-02Actions
Actions #1

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 #2

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 #3

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 #4

Updated by Vincent MEMBRÉ over 12 years ago

  • Status changed from Discussion to Pending technical review
  • % Done changed from 0 to 100
Actions #5

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 #6

Updated by Vincent MEMBRÉ over 12 years ago

  • Status changed from Discussion to Pending technical review
  • % Done changed from 80 to 100
Actions #7

Updated by François ARMAND over 12 years ago

  • Status changed from Pending technical review to 10

That seems good, and the refactoring is quite pleasant, thanks.

Actions #8

Updated by Jonathan CLARKE over 12 years ago

  • Target version changed from 47 to 50
Actions #9

Updated by Jonathan CLARKE over 12 years ago

  • Target version changed from 50 to 2.4.0~beta3
Actions #10

Updated by Jonathan CLARKE over 12 years ago

  • Status changed from 10 to Released
Actions

Also available in: Atom PDF