Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-13909

Advanced Authorization based on Privileges

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.5.0
    • Fix Version/s: 7.0.0
    • Component/s: Module - Authorization
    • Labels:

      Description

      Currently privileges applied to an internal role can only be limited to a subset of objects through a static query filter (see: https://backstage.forgerock.com/docs/idm/6.5/integrators-guide/#creating-privileges 20.4.2) like "/name eq 'Peter'".

      It would be very helpful it was possible to at least access information from the security context of the user currently trying the operation f.e. /owner eq ''${context.security.authenticationId}", so the subset of available objects can be dynamically controlled according to the current user. Alternatively, an option to provide a script that takes care of the filtering and returns the matching subset of objects would be even better (if that script has access to the security context).

      Currently, this can only be achieved by shifting the logic from the privilege to an access.js directive with a script that manually checks if the operation is allowed. But that just means that a lot of the convenience offered by privileges is lost, as permissions and access to all properties have to be checked through source code, instead of configuration.

      Use-case:
      A defined new managed object that can to some extent be controlled by users themselves via the REST-API. Some of its properties are:

      owner: relationship to one managed user
      admins: relationships to multiple managed users

      and generic stuff like name, description, and similar. The scenario we want to achieve is the following:

      Any authenticated user can read all of the objects (as in which properties exactly is currently under debate) and create new ones. A user who is the owner of that object (created it) is allowed to do anything with it (including deleting it and assigning a new owner) while the users who are stored in "admins" have more limited access (cannot delete it/change the owner). So, in the end, what's needed is a sort of access control list depending on the authenticated user, so each user can just do the operations and access the properties they have the permission to.

      Originally it's hoped to use the privileges system for a good part of the job, as that already covers the property-level access to the resources. But without the ability to limit the access in response to the authenticated users relating to the resource, that didn't seem feasible. So the current approach is to just handle the authorization via new entries in the access.js and according to scripts (inspecting the request and deciding if it is okay), completely ignoring the permission system.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                katie.gonzalez Katie Gonzalez
                Reporter:
                jamal.yafai Jamal Yafai
                QA Assignee:
                Alexander Dracka
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: