Skip to main content

SKP Security - Divorce Profiles from Roles

Syniti Knowledge PlatformMigratePlatform

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!

Posted by Ben Bauer ·
3 comments

Log in to comment and vote

Comments3

  • John Munkberg

    Team•

    Oct 26

    @Ben Bauer Think of a Security Profile as a HARD OVERRIDE on security, specific to the asset to which the security profile is assigned. Both Roles and Groups are critical the design of this functionality.

    All developers can see all Datasets. All Validators can see all Datasets. This is by design.

    But, for an HR Dataset that contains sensitive information, we security the asset (The Dataset) with a Security Profile. Everyone immediately loses all access to that object.

    The Profile Manager now has to add back the correct users, including their Roles. HR_Developers to the Developer role, HR_Mappers to the Mapper Role, etc. Only the people in those groups are allowed access, and that access is strictly based on the Role assigned to the groups inside of that security group.

    So - Security Profile is a complete override of “Global Security”. it’s not additive or subtractive - it’s a replacement.

  • 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.