• State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 95 subscribers
  • Views 1264 views
  • Users 0 members are here
Options
Related

How to prevent edit, or create regardless of application used

Mikko Majander
over 3 years ago

Hi,

We have a case where by default we would like to prevent supervisors (manager) of employee from editing the records of their subordinates (in person-table). This can be prevented from the Web Designer (support.oneidentity.com/.../how-to-grant-access-to-edit-or-add-employees-in-it-shop), but the supervisor can still edit the attributes from Manager (or even from API if they know how).

It seems that there are various ways which can be applied, but perhaps most secure way would be to do this on the level of permissions so that regardless of the tool used, they cannot find a loophole. Perhaps the script called on saving could be used, but that would in this case require identifying the logged in user and their person-object.

Is there already a KB-article, that describes how to implement this in the most practical way or do you (or anyone else) has recommendation of best practices when it comes to requirements like this?

Thanks!

Br,

Mikko

Parents
  • 0 over 3 years ago

    Hi Mikko,

    i assume you have a role-based authentification process, i would try making a copy on the VI_4_ALLMANAGER PermissionGroup where you change their editing and creation rights on table.Person to your requirements. (Picture related:)

    This changed PermissionGroup should then be applied to your Employee Manager AERole (or whereever your managergroup is used)

    Having replaced VI_Groups would mean then to check those permissions whenever you install new moduls or have a version upgrade to give perticiular rights to added new columns and tables.

    Hope that helped.

    PS: This should be the part of the doku which would be of interest support.oneidentity.com/.../8

    Best regards,

    Thorsten

Reply
  • 0 over 3 years ago

    Hi Mikko,

    i assume you have a role-based authentification process, i would try making a copy on the VI_4_ALLMANAGER PermissionGroup where you change their editing and creation rights on table.Person to your requirements. (Picture related:)

    This changed PermissionGroup should then be applied to your Employee Manager AERole (or whereever your managergroup is used)

    Having replaced VI_Groups would mean then to check those permissions whenever you install new moduls or have a version upgrade to give perticiular rights to added new columns and tables.

    Hope that helped.

    PS: This should be the part of the doku which would be of interest support.oneidentity.com/.../8

    Best regards,

    Thorsten

Children