Skip to main content

SKP Security - Divorce Profiles from Roles

Please link Profiles only to User Groups, not to Roles.

The link from a Security Profile to a Security Role is enforced in a subtractive way that is very confusing and tedious to work around. The tagging of objects with Security Profiles should not require Role configuration, and those Roles certainly shouldn’t override a User’s other Roles.

Hypothetical:

  • If my User is a member of both a Read-Only Role and an Admin Role, but the Read-Only Role is linked to a Security Profile, then I can no longer maintain any objects tagged with that Security Profile.

  • If I then add the Admin Role to the Security Profile, then I now have to give Admin permission to any user that is to be able to see the objects tagged with that Security Profile.

  • Workaround is to create 2 Read-Only Roles and 2 Admin Roles, one set with the Security Profile and one set without it.

Real Example:

  • We have identified 19 different "Security Roles" at Eli Lilly (so far). These represent personas who have different page-level permissions throughout SKP.

  • And we have identified 4 different "Security Profiles" at Eli Lilly (so far). These represent data-level permissions for their 4 subject areas (or so we thought).

  • What we thought would be a security configuration of 19+4=23 roles, is now going to be 19*4=76 roles!

2 comments

Log in to comment and vote

Comments2

  • nikhileshshirsale

    Team•

    Jun 9

    Thanks Ben, for sharing feedback. We are currently reviewing it and will get back to you if we need more clarification.

  • Ben Bauer

    •

    Jun 8

    FYI - This entanglement between Profiles (data/row-level security) and Roles (page-level security) will not scale well and will likely be a showstopper in any future MDM product.