IBM QRadar SOAR

Hello,

We are having a particular requirement with which hopefully you can orient us: we have a Circuits function which uses an external resource. This external resource is an user account of password which is used to interact with an external system, but this password expires periodically and we have to renew it to get a new one using an automatic procedure through an API. The thing is that when we use this password and it's already expired, we get a specific exception that we are handling to then trigger the renewal logic but this process take an undefined time (usually a few seconds but it can take up to a minute. It's not under our control).

We need to trigger the password renewal procedure once, otherwise a second call to the Circuits function might trigger the function again or at the same time the other one is executing, which will potentially lead to a few problems (like an infinite loop due to a new failure by the first caller, as the password was changed again thus raising the invalid credentials exception).

To solve this situation, we were thinking to implement a lock and an event in the procedure that performs the password renewal. This way, the first one to detect that the password is no longer valid will acquire a lock, clear the event, renew the password, set the event and release the lock, whereas all other calls to this function will detect that they cannot acquire the lock and will lock waiting for the event to be set.

We would to know two things:

• Your opinion about the described approach. Have you tried something like this in the pass? Any issues? Do you think there is any better way to do this?
• We are assuming that Circuits does not fork, otherwise this approach is not feasible. I have connected to our Resilient integration server where Circuits is running and I see only one process, but I don't know if it can spawn more under heavily load or any other condition. Is this the case?

Thanks in advance for your feedback.

Best regards,

------------------------------
Carlos Ortigoza
------------------------------

Hi Carlos,

I think your approach should work. Each function when invoked, is the same in-memory instance, so your locking capability should work for other instances which may be running at the same time. The trick is to ensure that once the lock is released, that the second instance doesn't also renew the password. There should be well known patterns for solving this.  

Be aware that using self.variable within the ResilientComponent class is shared by all instances. If you create another class, then using self.variable is thread safe.

------------------------------
Mark Scherfling
------------------------------

Original Message:
Sent: Tue May 28, 2019 09:21 AM
From: Carlos Ortigoza
Subject: Circuits threads communication

Hello,

We are having a particular requirement with which hopefully you can orient us: we have a Circuits function which uses an external resource. This external resource is an user account of password which is used to interact with an external system, but this password expires periodically and we have to renew it to get a new one using an automatic procedure through an API. The thing is that when we use this password and it's already expired, we get a specific exception that we are handling to then trigger the renewal logic but this process take an undefined time (usually a few seconds but it can take up to a minute. It's not under our control).

We need to trigger the password renewal procedure once, otherwise a second call to the Circuits function might trigger the function again or at the same time the other one is executing, which will potentially lead to a few problems (like an infinite loop due to a new failure by the first caller, as the password was changed again thus raising the invalid credentials exception).

To solve this situation, we were thinking to implement a lock and an event in the procedure that performs the password renewal. This way, the first one to detect that the password is no longer valid will acquire a lock, clear the event, renew the password, set the event and release the lock, whereas all other calls to this function will detect that they cannot acquire the lock and will lock waiting for the event to be set.

We would to know two things:

• Your opinion about the described approach. Have you tried something like this in the pass? Any issues? Do you think there is any better way to do this?
• We are assuming that Circuits does not fork, otherwise this approach is not feasible. I have connected to our Resilient integration server where Circuits is running and I see only one process, but I don't know if it can spawn more under heavily load or any other condition. Is this the case?

Thanks in advance for your feedback.

Best regards,

------------------------------
Carlos Ortigoza
------------------------------

Hello Mark,

Thanks for your reply. Yes indeed, we implemented this already and worked perfectly.

If any member of the community has to go through the same situation, feel free to contact me directly in case you have any doubt or issue.

Regards,

------------------------------
Carlos Ortigoza
------------------------------

Original Message:
Sent: Tue June 04, 2019 05:51 PM
From: Mark Scherfling
Subject: Circuits threads communication

Hi Carlos,

I think your approach should work. Each function when invoked, is the same in-memory instance, so your locking capability should work for other instances which may be running at the same time. The trick is to ensure that once the lock is released, that the second instance doesn't also renew the password. There should be well known patterns for solving this.  

Be aware that using self.variable within the ResilientComponent class is shared by all instances. If you create another class, then using self.variable is thread safe.

------------------------------
Mark Scherfling

Original Message:
Sent: Tue May 28, 2019 09:21 AM
From: Carlos Ortigoza
Subject: Circuits threads communication

Hello,

We are having a particular requirement with which hopefully you can orient us: we have a Circuits function which uses an external resource. This external resource is an user account of password which is used to interact with an external system, but this password expires periodically and we have to renew it to get a new one using an automatic procedure through an API. The thing is that when we use this password and it's already expired, we get a specific exception that we are handling to then trigger the renewal logic but this process take an undefined time (usually a few seconds but it can take up to a minute. It's not under our control).

We need to trigger the password renewal procedure once, otherwise a second call to the Circuits function might trigger the function again or at the same time the other one is executing, which will potentially lead to a few problems (like an infinite loop due to a new failure by the first caller, as the password was changed again thus raising the invalid credentials exception).

To solve this situation, we were thinking to implement a lock and an event in the procedure that performs the password renewal. This way, the first one to detect that the password is no longer valid will acquire a lock, clear the event, renew the password, set the event and release the lock, whereas all other calls to this function will detect that they cannot acquire the lock and will lock waiting for the event to be set.

We would to know two things:

• Your opinion about the described approach. Have you tried something like this in the pass? Any issues? Do you think there is any better way to do this?
• We are assuming that Circuits does not fork, otherwise this approach is not feasible. I have connected to our Resilient integration server where Circuits is running and I see only one process, but I don't know if it can spawn more under heavily load or any other condition. Is this the case?

Thanks in advance for your feedback.

Best regards,

------------------------------
Carlos Ortigoza
------------------------------