Details

    • Type: Feature Part
    • Status: Done
    • Priority: L3 - Default
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.0-alpha2, 2.1.0
    • Component/s: backend
    • Labels:
      None

      Description

      AT:

      • a user has access to Optimize if one of the following authorization in the engine are defined (assume the user is called "Kermit" and is in the "Kermits-Gang" group):
        • Type: ALLOW, User: Kermit, Permissions: ALL/ACCESS, Resource ID: optimize
        • Type: ALLOW, User: Kermit, Permissions: ALL/ACCESS, Resource ID: *
        • Type: ALLOW, Group: Kermits-Gang, Permissions: ALL/ACCESS, Resource ID: optimize
        • Type: ALLOW, Group: Kermits-Gang, Permissions: ALL/ACCESS, Resource ID: *
        • Type: GLOBAL, User/Group: *, Permissions: ALL/ACCESS, Resource ID: optimize
        • Type: GLOBAL, User/Group: *, Permissions: ALL/ACCESS, Resource ID: *
      • if a user has explicitely been denied the access to Optimize, the previous defined authorizations do not apply and he cannot login to Optimize
      • it is documented in the user access management section in the technial guide how to define those authorizations

        Activity

        Hide
        sebastian.stamm Sebastian Stamm added a comment -

        We should only get the Application Authorizations from the engine instead of all Authorizations to speed things up a bit.

        The following scenario produces unexpected behavior:

        • User A is in group B
        • Group B has the following permissions:
          • ALLOW group b ACCESS to *
          • DENY group b ACCESS to tasklist
          • DENY group b ACCESS to optimize
        • Expected: User a does not have access to tasklist and optimize
        • Observed: User a does not have access to tasklist, but has access to optimize
        Show
        sebastian.stamm Sebastian Stamm added a comment - We should only get the Application Authorizations from the engine instead of all Authorizations to speed things up a bit. The following scenario produces unexpected behavior: User A is in group B Group B has the following permissions: ALLOW group b ACCESS to * DENY group b ACCESS to tasklist DENY group b ACCESS to optimize Expected: User a does not have access to tasklist and optimize Observed: User a does not have access to tasklist, but has access to optimize
        Hide
        johannes.heinemann Johannes Heinemann added a comment -

        Also we should throw a 401 only if the user is not authenticated. In case he does not have the authorization, throw a 403 so we can display a proper message for the user:

        • move the authorization part into a new class
        • call the authorization check in the authentication service class
        • move the authorization test from the AuthenticationServiceIT to a dedicated test class
        Show
        johannes.heinemann Johannes Heinemann added a comment - Also we should throw a 401 only if the user is not authenticated. In case he does not have the authorization, throw a 403 so we can display a proper message for the user: move the authorization part into a new class call the authorization check in the authentication service class move the authorization test from the AuthenticationServiceIT to a dedicated test class

          People

          • Assignee:
            Unassigned
            Reporter:
            johannes.heinemann Johannes Heinemann
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: