Disable camunda provided Rest api

Hi ,
We have a use case scenario where we have to disable few of the camunda provided rest api for security considerations. Also in some other cases we need to override the inbuilt logic for the rest apis. Any suggestions on this will be very helpful.

TIA,
sandeep

Have a look at properly configuring authorization. That may be a better route to ensure you have the appropriate restrictions throughout Camunda, as opposed to just the REST API.

This should help you with overriding.

Authorization service of camunda doesn’t seem to help in our case as we have a completely detached identity managed system with oauth mechanism. Every camunda rest api call will receive a token in header and the token has to validated by making another call to the ims system before going ahead.

We have achieved overriding of Camunda provided api by follwoing this example in a non spring boot project using jersey as Jax-rs provider.
https://github.com/camunda-consulting/code/tree/master/snippets/custom-rest-api.
How to achevie the same in spring boot project

I have a use case where we want the Camunda REST API to be enabled in lower environments (DEV,STG) but disabled in PROD. I can use Spring boot profile based configurations to control it but is it possible to disable the REST API through configuration? If yes can someone help me with the configuration to do so.

Hi @shreza

You can use maven for creating profile based dependencies. So you can configure dependencies conditionally based on environment.

<profile>
	<id>active-on-property-environment</id>
	<activation>
		<property>
			<name>environment</name>
			<value>!prod</value>
		</property>
	</activation>
	<dependencies>
		<dependency>
			<groupId>org.camunda.bpm.springboot</groupId>
			<artifactId>camunda-bpm-spring-boot-starter-rest</artifactId>
			<version>7.13.0</version>
		</dependency>
	</dependencies>		
</profile>

Run the profile with mvn package -Denvironment=prod, it will exclude the camunda rest dependency from application packaging.

1 Like

Thanks this should work. Although i was looking for some configuration based approach so that if required we can enable it by changing the configuration and wont have to re build and re deploy as that will be a hassle for us. I understand we might have to restart the app in case if there is a configuration based approach but that will be totally operational side stuff and nothing to do with rebuilding it and re deploying it.