Backend Rolecheck Security

[tjwdev]

Front-end role checks are bypassable. Back-end must have mirroring security functions that the front-end intends. Rules, Queries, Watchlist, Flights, Passengers, Cases, Upload, Add/Manage Users, Audit/Error Log, Disposition Status Management all relate to services that either post or get (or both) to the database. These mappings must have the appropriate user role checks on them in order to properly reject/accept requests securely and some currently do not.

[jtangGitHub]

please describe types of front-end role checks already done?

[tjwdev]

front-end role checks are done through a directive 'hasRole' and a factory called 'checkUserRoleFactory'. The point being to restrict user vision of the available tabs based on the currentUser's role. You can observe this under 'main.html', look for the 'data-has-role' attributes on the elements in question. Issues arise when it is trivial to undermine the front-end data and establish that the currentUser can be any role. In the explicit issue I ran through earlier I made a new user with roleId = 3 (View flights/pax only) and managed to spoof his admin rights on the front-end, granting access to the views, but more importantly, the underlying services. I was, in this example, able to make a rule with the current user and have it be accepted by the back-end as legitimate though the database still held the user as a role 3.

[jtangGitHub]

Please indicate all roles with their responsibilities? how do you define/maintain roles? what role you have defined so far? (admin and current user)? the drawbacks of RBAC?

[jtangGitHub]

OKAY, i got the current roles definitions from db.

[tjwdev]

Yes, roles were defined long before by someone. As far as 'what is allowed by what' the only place it seems it is enforced is on the front-end loosely. That's the only place I can interpret what we've established as far as hard rules for the roles go. As far as a brief overview as I understand it:

-People can have multiple roles. -Admin has access to everything. -The others are named basically to their access scope, excepting that Flights and Passengers includes cases and case actions I'd think.

[jtangGitHub]

Yes. the front-end is the only place to enforce the current implementation, if buttons and other widgets have been guarded correctly. We can consider other mechanisms to implement authorization.

[tjwdev]

Yes. That's the core of the issue, we technically do properly restrict views according to given roles, but all of that's done through Angular, which is mostly client-side interpretation. We need the back-end to have an identical rule-system that we intend to have manifest on the front-end, else-wise it's only half a bridge.

[copenhafer]

@jtangGitHub , what's the status? Spring has mechanisms for securing the rest endpoints. have you looked into any of them?

[jtangGitHub]

working on it

[veotax]

jCasbin is an authorization library that supports models like ACL, RBAC, ABAC.

Related to RBAC, casbin has several advantages:

1. roles can be cascaded, aka roles can have roles.
2. support resource roles, so users have their roles and resource have their roles too. role = group here.
3. the permission assignments (or policy in casbin's language) can be persisted in files or database.
4. multiple models like ACL, BLP, RBAC, ABAC, RESTful are supported.

And you can even customize your own access control model, for example, mix RBAC and ABAC together by using roles and attributes at the same time. It's very flexible.

I saw there's a role check mechanism working on, but I think it can be extended to more powerful and flexible models like RBAC and ABAC through the integration of jCasbin. What do you think? Thanks.