Idea - Actions with permissions

Actions with permissions

On our Radar

Backend

Hi,

As a secutiry increase to our applications it would be nice if we could assign roles (former permission areas) to screen actions and user actions.

This way users that didn't have permission to run them, would never be able to use firebug and other tools in order to activate buttons that trigger the action and we wouldn't need to always be "asking" in every action, if the user has permission to run it.

Another benefit would be, by unchecking the anonymous role, we could also automatically know if a session timed out, without having to "ask" that also in every action.

What do you guys think?

18 Dec 2012

Evert van der Zalm

MVP

Well do like the option to have it, but still as an developer you must be aware of which items can be 'discoverd' by the developer tools (like firebug).

In mine opion an user musn't be able to 'find' or enable stuff that's on his screen what he shouldn't be seeing.

The session time-out part -> don't really understand that, why should you check that in every action?

Kind regards,
Evert

21 Dec 2012

Kilian Hekhuis

MVP

"In my opion a user musn't be able to 'find' or enable stuff that's on his screen what he shouldn't be seeing." - Though I agree with this, when e.g. using an IF on the screen, the part not shown is, iirc, merely hidden, so with F12/Firebug it's easy to enable it.

27 Dec 2012

Gonçalo Almeida

Hi Evert,

The session thing is because in some actions we need to save data and need to check if the user is still in session for him to be able to save that data (because we also use some session variables like the userId).

07 Jan 2013

Evert van der Zalm

MVP

Hello Goncalo,

Why don't you use the OnSessionStart action for that (as a general action)? Then you can make the user login again (or do something else).

Kind regards,
Evert

09 Jan 2013

Daniel Lourenço

Staff

The ability to the indicate at the action level that it can only be execute if a specific Role is granted to the user in session.

This would make it easier to extend the OutSystems security model to the business logic layer (without having to "program" the rules with validations in the business flow).

Kind Regards,

Daniel Lourenço

Merged from 'Role-based security for Actions' (idea created on 2012-10-22 10:30:44 by Daniel Lourenço), on 2014-01-24 12:21:10 by Gonçalo Borrêga

22 Oct 2012

Shraim

Interesting idea but how will the logic behave if a user/role are not authorized for a certain action? Should it through a runtime exception with a custome message? With Ui we can choose to disable a widget but with an action what should happen? If we decide to disable widgets from Actions would this violate seperation o logic and UI?

Merged from 'Role-based security for Actions' (idea created on 2012-10-22 10:30:44 by Daniel Lourenço), on 2014-01-24 12:21:10 by Gonçalo Borrêga

05 Nov 2012

Daniel Lourenço

Staff

Shraim, thank you for your comment.

My view would be for the platform to simply generate an exception. What happens is that many times you want to make sure that only one specific profile can execute an action. Normally this results in a button being hidden and, for the most cautious, to put a business validation in the action logic itself (so that, even if the button is open, the user cannot execute the action if he does not have the appropriate role). This would avoid needing the second step and having the security model helping us the control at the action level.

Kind Regards,

Daniel

Merged from 'Role-based security for Actions' (idea created on 2012-10-22 10:30:44 by Daniel Lourenço), on 2014-01-24 12:21:10 by Gonçalo Borrêga

08 Nov 2012

Gonçalo Borrêga

Merged this idea with 'Role-based security for Actions' (created on 2012-10-22 10:30:44 by Daniel Lourenço)

24 Jan 2014

Leandro Oliveira

Champion

This is the scaffolded server action to sync data to a local entity:

It would be nice to have it in the checkboxes instead in IF, throwing exceptions "Not {role type}" when the user don't have the role.

It would also be nice if checking the Anonymous role resolves the following warning when calling a server action on a Anonymous screen:

13 Jun 2020

Nordin Ahdi

MVP

Merged this idea with 'Add Role Based Access to Actions just like screens have' (created on 06 Oct 2023 07:58:00 by Vincent Koning)

09 Oct 2023

Vincent Koning

Currently you must configure the Roles that can access a screen. OutSystems will take care of the security aspect and a person gets access or not. I would like to suggest the same RBA mechanic for all Actions.

Why

If you want that a certain action is only usable by people with a certain role then you need to code this in the action itself. This will take at least 2 action steps (the check and the resolution). This check will be repeated on each affected action making a lot of duplicate code. Code that does not assist in the primary goal of the action and are therefor nothing more than screen space waste and a distraction.

It would make actions more readable and better manageable if we can enable RBA for actions and then specify the allowed roles inside the properties of the action, just like we do with screens.

An other nice perk by doing it this way is that we, the developers, can always be sure that the security is implemented correctly. This will free up testing resources.

On What

RBA on Actions should be available on;

All public actions.
All actions that are referenced from screens or blocks as these are called from an unsafe (web / mobile) environment.

RBA on Actions could be available on;

Any other action where the developer deems in necessary to configure this.

The transition

This does not have to be a breaking change. If you implement is just like screens than the default access would be "registered" and that will allow all logged in users to call the action. Only for apps that have anonymous access you will need to take action by enabling anonymous access for the affected actions. An environment toggle (in Lifetime for example) could enforce to default enablement or the Anonymous role as well.

You can then migrate from the code-based RBA to the now native RBA in upcoming refactors or maintenances.

Does this mean that I never have to check for roles again?

No, It will still be needed to check for roles in actions that, for example, manage a flow (orchestration). It could be that if the user has a certain role that we need to make some audit logging or enable other features. This will require us to still be able to perform manual checks of roles.

06 Oct 2023

William Vermeulen

Champion

Love this idea, it makes it also very explicit on how the action can be used. A good way to mitigate security violations.

06 Oct 2023