In my (reactive) application, I have a basic logic to control access of the exposed/public Server Actions of my CS module. It is implemented using CheckRole() function.
For operations originated by a user in a front end module, it works fine. However, when these Actions are called by a Timer or a BPT Action, as the GetUserId() function returns null, I can't control access using CheckRole().
Does anyone knows how to do it? How can I detect in my action if it is being called by a Timer or BPT operation?
I understand I have ways to change the way access control is made (maybe receiving UserId as an input parameter), but this would be plan B.
Thanks,Ricardo.
Hi Ricardo,
You can check If(GetUserId() = NullIdentifier()) is true then method is called from timer or BPT. As it would return null in case it is called from BPT or timer .
Best Regards
Devendra
Thanks, Devendra. In this case, allowing access when GetUserId() returns null, I would allow unlogged access to my service, a security problem, also.
We have done this already, until we found another solution.
Yes may be you can implement plan B and can check if GetUserID is null then pass the input USERID as userid in CheckRole() action.
Hey Ricardo,The Timer and BPT are asynchronous process so it will run in different session. That's the reason, you're getting NULL value for GetUserID inside those actions.Please look into below thread. It might be helpful for you.Do Timers / BPT Process Automatic Actions pass User Roles checks? | OutSystems Thanks,Gnanavel Sivasankaran
Thanks for the answer, Sivasankaran!
I understand that the linked solution does not fix the security issue, which is allowing unchecked access to my public server action (the wrapped action would be controlled but the other action would still be public and not controlled).
I will answer that thread to continue this conversation, anyway!
Devendra, allowing access with null user is also a security flaw, agree with me? In that way, an anonymous user will be allowed to access my server action.
Yes that's a security flaw. but you can handle it in other way like sending a extra optional parameter like GUID from Timer (Create a GUID and insert in a Entity) and if GetUserId() returns null then you can validate the parameter GUID that is coming from Timer with the newly inserted GUID in database.
Hi Devendra. You mean implementing a parallel control like a token authorization?
The timer would retrieve this GUID from database and send it as a parameter so that the exposed Action would compare the input GUID with the one written in the database?
This discussion doesn't make a lot of sense to me.
If you want to secure the Launch of a BPT process or the Wake of a timer from your front end, then use a server action in which you either launch the BPT or wake the timer. In that server action you can use the check role function of the required role, and see if the current user is allowed to launch the BPT or wake the timer.
A BPT process or Timer cannot directly launched by a end users, so I don't see why there should be a security flaw.
Hi, Daniël.
That's not the point.
I have Service and public Server actions in my CS module used either by front end and other service modules.
Controlling acessess when the request is originated by the user in the front end module is OK.
The matter here is how to control access when the action is not originated by the user, as when it is originated by a Timer or a BPT process.
One example: the service action CS.InactivateCustomer is called both by front end when a manager manually disables a customer or automatically by a Timer, when the customer is away for a long period of time.
If I simply restrict access to this action requiring a user with a valid role, the Timer request will fail.
Best regards,
Ricardo.
there are all kinds of ways you could handle this.
Just one option :
Another option, but I'm not sure this is best pratice, is to give your timers their own persona in the system, keep the private timer action calling the CS action, and make them login and logout around the actual call of the CS server action. Just give the right timer persona the required roles, and you don't have to do anything special for this in your CS server action.
I personally like this second idea much better than the first, because it keeps your CS logic so much cleaner, but again : not sure if there could be objections against a timer doing a login.
Dorine
Hi, Dorine, thanks for the answer!
We had thought about the first solution, except for the token, as a weak one, also! The parameters could be deducted by an attacker and the security would fail.
About the second one, have you tried it?
I might try it in the next days and post the results here.
no, I haven't done this yet, let us know how it goes.
Regards,