Turn On Basic HTTP Authentication for REST API in WildFly

Camunda 7 Topics Discussion & Questions
1

I’ve read the “Configuring Authentication” documentation that states:

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.

However, WildFly doesn’t have a web.xml file that I can find. I want to turn on basic HTTP authentication for the REST API (Camunda 7.5/7.6 and WildFly 10), but can’t figure out where to put the servlet filters mentioned in the documentation. WildFly is typically “configured” in the standalone.xml file, but the only reference to “servlet” in their doesn’t permit the use of those filters.

Please help. Thanks!

Michael

2

The web.xml file you ´have to change for REST API Authentication resides in camunda-engine-rest-$VERSION.war which is located in the deployments folder in case of Wildfly as the AS.

1 Like
3

Hi @mppfor_manu,

as @langfr correctly pointed, web.xml is part of web application, which is usually packaged in a .war file. On Wildfly distributions, they are usually located in server/wildfly-10.1.0.Final/standalone/deployments/

Hope that helps,
Askar

4

Are you saying that I need to rebuild the distributed Camunda Engine war file versus simply changing an external WildFly file?

In other words, I cannot use the pre-packaged distribution for WildFly 10, I have to rebuild the camunda-engine-rest war file from source code. Is that correct?

This seems like an awful lot of work to enable something that I would think is a common mode of operation. I mean, if you’re not authenticating, how are you controlling access to processes? But, to each their own.

Thanks for the help.

Michael

5

Hi @mppfor_manu,

I am not a wildfly expert, but i assume you should be able to extract war file, do changes in web.xml so that your wildfly server redeploys automatically.

I think referring to something like that http://developer-should-know.com/post/112234159962/exploded-deployment-to-jboss-and-wildfly could help you.

Cheers,
Askar

6

I think that WildFly only requires some adjustments to the “standalone.xml” file (or other - depending on requirements: clustering, HA, etc.)

Though I haven’t reviewed the details… Doesn’t Camunda come pre-configured with authentication “on”?

For example, I checked the WildFly “standalone.xml” document and found:

See “autorizationEnabled”

NOTE: Just realized this is the “datasource” (DB) configuration… never mind. (more coffee required - Mondays…)

                    <datasource>java:jboss/datasources/ProcessEngine</datasource>
                    <history-level>full</history-level>
                    <properties>
                        <property name="jobExecutorAcquisitionName">
                            default
                        </property>
                        <property name="isAutoSchemaUpdate">
                            true
                        </property>
                        <property name="authorizationEnabled">
                            true
                        </property>
                        <property name="jobExecutorDeploymentAware">
                            true
                        </property>
                    </properties>
7

In order to enable authentication you will need to update the web.xml as others have noted.
This does not mean you have to rebuild the distribution (although that is an option), rather simply extract the war, update the web.xml and repackage using the “jar” command from your Java SDK.

Cheers,
Greg

8

It’s true that you can extract the engine-rest war file, modify web.xml, and then archive it again (it’s just a ZIP file).

I’ve done this before, but it just seems a bit crude, but if this is the way it has to be, then so be it.

I’m trying that now.

9

I think authorizationEnabled is for the Camunda GUI (WebApps), not the REST API.

10

I made it work and it wasn’t that hard. Here’s the process:

  • Unzip the camunda-engine-rest-X.X.X.war file. This will produce two directories META-INF and WEB-INF

  • Change directories to WEB-INF

  • Using an appropriate text editor, open the web.xml file and uncomment the basic HTTP section you will find there. Save the file.

  • Using a zip utility, zip the META-INF and WEB-INF directories back into an archive with the same filename a the original. You may have to manually change the extension to “war” as many utilities will save it with a “zip” extension.

  • Examine the archive to ensure that the two directories are in the root, not in a subdirectory.

  • Shut down WildFly

  • Move the original war file from its location in deployments and place the modified file in the deployments directory

  • Restart WildFly and check the REST API. It should now require authentication.

I’ll be honest that I don’t know where to go from there as the user database and authorization can vary depending upon your implementation.

2 Likes
11

One more thing: If you’re using the http-connector to make a REST call to the now authentication enabled REST API, then here’s how you encode credentials.

  • Get your user name and password.
  • Concatenate them into a string separated by a “:”. Example: myuser:mypassword
  • Base64 encode the string. In Linux, this command would do that: echo “myuser:mypassword” | base64
  • In the http-connector Input Parameters, the headers variable (map type) should have an entry that looks like this:
    KEY value
    ============ ==========================================
    Authorization Basic bXl1c2VyOm15cGFzc3dvcmQK

Here’s the XML of such a header in a process:

      <camunda:map>
        <camunda:entry key="Accept">application/json</camunda:entry>
        <camunda:entry key="Content-Type">application/json</camunda:entry>
        <camunda:entry key="Authorization">Basic VGVzdENhbXVuZGE6VGVzdENhbXVuZGE=</camunda:entry>
      </camunda:map>
12

User/Password of TestCamunda:TestCamunda.
Boring, you could have made it something cooler like : Camunda:Rocks

:slight_smile: