Cannot connect ( login) to camunda having germancharactres ( öü) in username

Camunda 7 Topics Discussion & Questions
1

It is not possible to login to camunda from a java app when the username has
german umlauts ( öäü) in username!
Can anybody help???

SCENARIO:

We are working with camunda 7.6 and wildfly.
The authentication is done via our java application, so we only define a GROUP in camunda.
Every thing works fine but when we try to login with a user having german umlaut in his username
login fails.
The username is passed to camunda via rest as utf-8 string but the user name is passed to the
authentication methods with a different user name.

Example:
The username as utf-8 is “BÖ”
it is passed as “BÃ?” to the methods.

The parameters set in the rest request are set correctly. ( verified calling an other rest service)

The camunda login rest call is directed to the login form of camunda with form parameters:
like this:

Form formData = new Form();
formData.param(“username”, name);
formData.param(“password”, pwd);

		response = target.request(MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN, MediaType.WILDCARD).post(Entity.entity(formData, MediaType.APPLICATION_FORM_URLENCODED));
2

At a minimum, given the origin of Camunda, I’d say this is pretty ironic.

I’m a bit unclear on how you are authenticating. Are you using Camunda’s native authentication mechanism and authorization database, or are you using an external authentication mechanism (e.g. LDAP)?

If you’re using the native Camunda mechanism, and this is just a guess, you might check out the character encoding/collation of the database ACT_RU_USER table. It shouldn’t matter given the data type for ID_ is varchar.

You might also consider turning on trace level debugging in WildFly. It will spew incredible amounts of log entries, but it is incredibly detailed and might give you a clue as to what is going on.

3

we are using external authentication. When I debug the app i see that the username is passed to our auth. with the wrong encoding.
Camunda engine knows only the group of the user.
So, there are no users in the db tables.

4

Hi @Robert_Ottohall,

Could you please elaborate a bit more on the code flow?
My understanding is:

  1. Your application sends a REST request (POST, FORM) with the username and password to the Camunda WebApplication?
  2. Somewhere later the username has broken encoding.

To which methods is it passed?

Cheers,
Christian

5

Hi Christian,
the problem is that I do not exactly know the mechnism.
But some parts are implemented in our part. So I can see where Camunda authentication is “landing”, it is a method called getUserTo.
But before that, a lot of methods are called ( via interceptors) and I can set a breakpoint inside.
Now I can not tell you the method names, I am now not in the office.

But when the user name is without umlauts, the simplified way is like this.

  1. Engine calls our authentication, checking password.
  2. gets the user group from our db
  3. checks whether this group is defined in camunda
  4. ok

But if the username passed to 1. is wrong, all other checks fail.

I do not know which camunda method is called after the first rest call. I thing the wrong encoding must happen there.

6

Alright,
Maybe you could reference some code regarding to 1. when you are back in the office.
Do you use a custom identity provider inside the engine?

7

@all and @hawky4s

Here the call hierarchy :

Calls during Login

  1. RestCall doLogin POST mit 2 PathParams and 2 FormParams ( userName,password
    org.camunda.bpm.webapp.impl.security.auth.doLogin

  2. calls checkPassword !!! ??? Here the useName is not utf-8???
    calling IdentityServiceImpl.checkPassword:
    processEngine.getIdentityService().clearAuthentication();
    // check password / username
    boolean isPasswordValid = processEngine.getIdentityService().checkPassword(username, password);

called from org.camunda.bpm.engine.rest.security.auth.impl.HttpBasicAuthenticationProvider.isAuthenticated
called from org.camunda.bpm.engine.rest.sub.identity.impl.UserResourceImpl

Here the UserName ist already changed
3. calling checkPassword in our Custom Identit Provider Class

8

The Solution is simple:

add charset definiton to mediatype

The rest call must be
Response response = client.target(getRootContext().getRootWebTarget().getUriBuilder().path(URL_BASE).path(“api/admin/auth/user/default/login/tasklist”))
.request(MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN, MediaType.WILDCARD)
.post(Entity.entity(formData, MediaType.APPLICATION_FORM_URLENCODED+" ; charset=“utf-8"”));

9

Good that you found the solution. I thought in the same direction yesterday
evening. Probably it uses the client or server jvm charset when none is
specified explicitly.

10

@hawky4s

But there is still a little problem:

I can login when I do the rest call to the camunda restservice ( doLogin)
But when I try to login using the standard web form in a browser, login fails for
all users with “umlauts”.

But for me it is ok!

11