Authorization scope and definitions

[koonpeng]

Preface

This thread is for discussing the authorization strategy and apis that rmf should implement and how different components can make use of them.

Current State and Problems

The current authentication and authorization is done exclusively by rmf-web. Authorization for rmf resources is determined by the map region it is in, e.g. a door in CSSD will need a user with the "CSSD" permission in order to be listed or controlled.

The lack of any authorization checks at the rmf level is causing some architectural problems with the current design. Some examples of the problems it has:

• Querying rmf managed resources.
  • In order to query only resources that a user can see, rmf-web must be aware of all resources in the system. Without it, it cannot do queries like 'get first 10 scheduled task'. The result is that rmf-web must maintain a mirror of the database in rmf.
• Enforcing open/closing lanes.
  • Improper enforcing of lane states can block tasks from being able to complete or re-route robots to areas the user has no permission to access to.
• Enforcing paths a robot takes.
  • Since planning is done by rmf, rmf-web cannot enforce that a user does not cause a robot to go to areas they do not have access to.
• Preventing information leaks.
  • Some resources like lanes and navgraphs cannot be easily assigned permissions. Often, they are in multiple regions, in order to correctly enforce access to these resources, rmf-web must find a way to split them into multiple smaller parts and assign permissions to them.
  • rmf-web cannot filter a fleet that only works in e.g. CSSD. A user that only has permission is a small region will still be able to see the all fleets and robots in the system.

Many of the problems is also due to a lack of definition for the scope of the authorization should have, and a the definition of "region" and the constraints (or lack of) they must have.

Discussion

• Is there better alternatives to region based permissions?
• Part of the reason for the lack of authorization in rmf is because these are all internal apis. rmf has no public apis, should the public apis support authorization, and if so, what form of permissions should it use?
• How should complex scenarios like these be handled?
  • A robot plans or re-route a path to the destination that goes through a region which the user that creates the task does not have access to.
  • Revealing the layout of a region that a user does not have access to, indirectly through lanes, navgraphs, robot paths etc.
  • A robot going to charge as part of the task plan and the user does not have access to the region the charger is in.
  • A user blocks a lane, which causes a robot to re-route to another region which the user has access to, but the creator of the task the robot is executing does not have access to.
  • A user is removed access to a region while a task they create in the region is ongoing.
  • A user selective blocking certain lanes before creating tasks so that their task is assigned "fast" robots while a higher priority task in another region they don't have access to is assigned "slow" robots, interfering with the kpi and overall system efficiency.
  • In cases where a company is signed to a contract that requires certain level kpi in the clause. A user belonging to a competing company abuses the lane blocking to reduce the efficiency of the competitor fleet, causing them to fail to meet their kpi.
  • And many other scenarios which can cause a user to indirectly send a robot to a location which they have no access to.
• What rules should be put into the definition of a region to avoid some of the above problems?

While not technically impossible, it is very hard to implement correct enforcement of permissions exclusively in another application (e.g. rmf-web) without support from rmf. In order to make enforcement easier, I think rmf should be aware of authorization. Even non-functional requirements like not allowing a lane or navgraph edge to span multiple regions would help alot in enforcing permissions.