Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-3812

authorization checks need to be case-insensative

    Details

      Description

      The Authorization checks in Camunda are case-sensitive meaning that it treats MelissP and melissp as two different people.

      On windows logins via LDAP are case-insensitive meaning that a person can logins with MelissP or melissp and is the same single person.

      For full details please see:
      https://groups.google.com/forum/#!topic/camunda-bpm-users/Kg5x4PBMDOI

        Activity

        Hide
        meyer Daniel Meyer added a comment -

        Thanks for reporting.

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

        Show
        meyer Daniel Meyer added a comment - Thanks for reporting. Do you you have an idea of how this should be solved?
        Hide
        melissa.palmer Melissa Palmer added a comment -

        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

        Show
        melissa.palmer Melissa Palmer added a comment - 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
        Hide
        meyer Daniel Meyer added a comment -

        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?

        Show
        meyer Daniel Meyer added a comment - 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?
        Hide
        melissa.palmer Melissa Palmer added a comment -

        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

        Show
        melissa.palmer Melissa Palmer added a comment - 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
        Hide
        meyer Daniel Meyer added a comment -

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

        lower(A.USER_ID_) = #

        {authUserId, jdbcType=VARCHAR}

        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

        Show
        meyer Daniel Meyer added a comment - That would mean that the auth checks need to do things like lower(A.USER_ID_) = # {authUserId, jdbcType=VARCHAR} 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
        Hide
        melissa.palmer Melissa Palmer added a comment -

        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_ = #

        {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

        Show
        melissa.palmer Melissa Palmer added a comment - 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_ = # {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
        Hide
        nikola.koevski Nikola Koevski added a comment -

        Issue fixed by pull request

        Show
        nikola.koevski Nikola Koevski added a comment - Issue fixed by pull request

          People

          • Assignee:
            yana.vasileva Yana Vasileva
            Reporter:
            melissa.palmer Melissa Palmer
          • Votes:
            1 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development