Server Action access control for Timer and BPT.
Question
Platform Version
11.14.1 (Build 34445)

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.

Best Regards

Devendra

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.


Thanks,
Ricardo.

Hi Ricardo,

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.

Best Regards

Devendra



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?


mvp_badge
MVP

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.


Hi Ricardo,

there are all kinds of ways you could handle this.

Just one option :

  • add extra input to the CS server action, making it recognisable as being called by a timer or BPT proces 
    • could be as simple as a IsTimer boolean
    • could be a string describing the timer or BPT by name
    • could be a token managed by your CS to make sure it is an allowed call
  • let timer not call the CS server action directly, but a private server action inside it's own module
  • let that private action call the public CS server action, passing the extra info that only timers and BPT send
  • in your CS server action, check for either a user with the required role, or for a correct value in that extra input


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.


Ricardo.

Hi Ricardo,

no, I haven't done this yet, let us know how it goes.

Regards,

Dorine

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.