The REST API ships with an implementation of HTTP Basic Authentication. By default it is switched off, but can be activated by adding a servlet filter as follows:

  1. <filter>
  2.   <filter-name>camunda-auth</filter-name>
  3.   <filter-class>
  4.     org.camunda.bpm.engine.rest.security.auth.ProcessEngineAuthenticationFilter
  5.   </filter-class>
  6.   <async-supported>true</async-supported>
  7.   <init-param>
  8.     <param-name>authentication-provider</param-name>
  9.     <param-value>org.camunda.bpm.engine.rest.security.auth.impl.HttpBasicAuthenticationProvider</param-value>
  10.   </init-param>
  11. </filter>
  12. <filter-mapping>
  13.   <filter-name>camunda-auth</filter-name>
  14.   <url-pattern>/*</url-pattern>
  15. </filter-mapping>

Any engine-specific request will then be authenticated against that engine’s identity service. The GET /engine request that supplies a list of all available process engines is the only request that does not require authentication. Any request that does not address a specific engine (i.e., it is not of the form /engine/{name}/…) will be authenticated against the default engine.

In the pre-built distributions, the engine authentication is switched off by default. You may have a look at the distribution’s web.xml file and remove the comment markers from the above mentioned filter declaration to activate authentication.

Note that HTTP Basic Authentication does not provide encryption and should be secured by an SSL connection.

The authentication provider is exchangeable. You can implement the interface org.camunda.bpm.engine.rest.security.auth.AuthenticationProvider to provide another authentication method and change the filter’s initialization parameter accordingly.

RESTEasy Specifics

The authentication filter works fine whenever the JAX-RS application containing the REST API is deployed as a servlet. This is not necessarily the case. One such case we are aware of is with some types of RESTEasy deployments:

RESTEasy allows deployment of a JAX-RS application as a servlet filter (see the RESTEasy docs). If you choose this method to deploy the REST API application, which we also do in the Tomcat distribution, the authentication filter requires an extra init-param named rest-url-pattern-prefix. The value has to correspond to the servlet path (see HttpServletRequest#getServletPath()) as in the case that the JAX-RS application is deployed as a servlet.

Example: If the RESTEasy configuration is

  1. <filter>
  2.   <filter-name>Resteasy</filter-name>
  3.   <filter-class>
  4.       org.jboss.resteasy.plugins.server.servlet.FilterDispatcher
  5.   </filter-class>
  6.   <init-param>
  7.       <param-name>javax.ws.rs.Application</param-name>
  8.       <param-value>org.camunda.bpm.engine.rest.impl.application.DefaultApplication</param-value>
  9.   </init-param>
  10. </filter>
  11. <filter-mapping>
  12.   <filter-name>Resteasy</filter-name>
  13.   <url-pattern>/*</url-pattern>
  14. </filter-mapping>

the following init-param has to be set:

  1. <init-param>
  2.   <param-name>rest-url-pattern-prefix</param-name>
  3.   <param-value></param-value>
  4. </init-param>

In the example above the value is empty because the RESTEasy filter mapping is /* and a servlet with that mapping would have an empty servlet path. Similarly, the filter mapping url /rest/* maps to the init-param /rest and so on.

原文: https://docs.camunda.org/manual/7.9/reference/rest/overview/authentication/