Disable or restrict operations in Cockpit?

[mar...@crimsoncricket.nl]

Hi,

We are looking into Camunda as a potential solution for managing long running processes in a financial application. So far, Camunda looks very promising in terms of flexibility and ease of integration with existing systems. Also the Cockpit turns out to have about all features required by our Operations team, and more.

However, there is one requirement which may be hard to fulfill: any modification to running process instances (adding / editing variables, suspension and cancellation) must adhere to the Four Eyes principle: the modification must be approved by a peer before it is applied to the process instance.

Is that something we could achieve by writing a Cockpit plugin? It might also be sufficient if we could just disable certain operations in the Cockpit, so we can provide similar functionality elsewhere.

[Sebastian Stamm]

Hi,

would the feature described in this ticket satisfy your needs [1]?

Cheers

Sebastian

[1]: https://app.camunda.com/jira/browse/CAM-3609

[webcyberrob]

Hi,

as a potential solution in the current environment. We configured a 'read only' cockpit such that we could give business users access to cockpit views without giving them access to the 'dangerous' functions.

If you wanted to give operations staff access to some of the cockpit functions, but you wanted a four eyes paradigm, then you could potentially implement your own management processes in the engine itself, include four eyes as part of the process - eg a user task to initiate, a user task to confirm, then a service task which calls the engine APIs to achieve what you want to achieve.

Personally, Id prefer to rely on an audit trail and limited privileged account access rather than go to the effort above. Perhaps you could have a single privileged user account which is disabled by default. Hence one party has access to unlock the account, but no access to cockpit. The second party has access to cockpit, but cant unlock the account. Not quite maker/checker, but at least there would need to be collusion for malicious activity to occur.

regards

Rob

[mar...@crimsoncricket.nl]

Op donderdag 12 maart 2015 09:59:21 UTC+1 schreef Sebastian Stamm:

Yes, definitely! Thanks for taking time to inform me of this feature request.

[mar...@crimsoncricket.nl]

Op donderdag 12 maart 2015 11:05:05 UTC+1 schreef webcyberrob:

Thanks Rob, that sounds like something that we could use. Is the "read-only" cockpit something that can be implemented with the standard configuration options of the cockpit? Disabling certain standard plugins? Or did you have to do something else? If I understand correctly, disabling plugins only removes the buttons client-side. That would not meet the security demands of our client.