Thanks for reporting.

Do you you have an idea of how this should be solved?

Hi Daniel,

I don't have an exact idea of how it can be solved as I cannot find where the auth checks are being done within the Camunda code. However basically the idea around the fix would be to ignore case of userid when comparison is being made.. something along the lines of using apache StringUtils.equalsIgnoreCase
StringUtils.equalsIgnoreCase(null, null) = true
StringUtils.equalsIgnoreCase(null, "abc") = false
StringUtils.equalsIgnoreCase("abc", null) = false
StringUtils.equalsIgnoreCase("abc", "abc") = true
StringUtils.equalsIgnoreCase("abc", "ABC") = true
https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringUtils.html#equalsIgnoreCase(java.lang.String, java.lang.String)

Might be worth linking this Jira with the changes being done in CAM-3515

Thanks
Melissa

Maybe we can provide a configuration option which allows users to enable the following behavior:
If the option is activated, the the usernames (and group names) will be set to lowercase before doing the authorization check.
When crating authorizations (through API or through Camunda Admin), you make sure that all user and groupnames are lowercase.

Would that work?

Hi Daniel,

Yes a config option would definitely help. However it's not acceptable to for lower/upper case entry for creations, as in production environment at times this will be business users/support users etc. will be creating these.

A better solution would be to ignore case completely.

Thanks
Melissa

That would mean that the auth checks need to do things like

lower(A.USER_ID_) = #

In places like [1]

However: I am not sure whether this can still use the index .

So it would probably be better to make sure the user ids and group ids end up there in lowercase in the first place.

[1] https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/main/resources/org/camunda/bpm/engine/impl/mapping/entity/Authorization.xml#L199

Hi Daniel

I've been doing some investigation on this and found that there is another place where such a case-insensitive query, against the logged in userId is causing issues. We have a TaskList filter with a criteria of "where assignee = ${currentUser()}". Again LDAP will allow MelissP and/or melissp to login as the same person however the query to get tasks for the assignee treats them as two different people. (filter query is similar to authorisations query we've already been discussing "and RES.ASSIGNEE_ = #

" [1])

Above means something as the follows happens: I login as MelissP create a task that gets assigned to me. Then login with melissp and you won't see these tasks as being assigned to me.

I do see in [1] there seems to be a 'taskNameCaseInsensitive' which starts to use config for "lower(RES.NAME_) LOWER_NAME_," we could implement the similar for assignee equals checks (but this does seem it could be allot of work)

Maybe there is a higher level solution or config setting within MyBartis to allow for case-insensitive queries.

Thanks
Melissa

[1] https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/main/resources/org/camunda/bpm/engine/impl/mapping/entity/Task.xml#L251

Issue fixed by pull request

Whats the status on this? The pull request linked above is for authentication, not authorization.

Task assignment and authorization  is still not case insensitive. Meaning, "MelissP" is a different user than "melissp" from authorizations point of view.

Hi worlvlhole,

As the issue is quite old, I would suggest you create another and report your scenario and what is not working there, just mention this ticket if you consider that it's related.
Another option is to ask for help in the forum.

Best regards,
Yana