No announcement yet.

Portal Admin & Security

  • Filter
  • Time
  • Show
Clear All
new posts

  • Portal Admin & Security

    When it comes to "Administration", we have different types of users, including Administrators, Developers and end-users. I can tell CNX has recognized the need to restrict access to certain admin functions. First line of defense: who even has access to the Portal Admin app to begin with. We have a variety of controls available for that. I am personally not a big fan of controlling access to apps at the User level because of the maintenance aspects of that approach. I prefer to use Groups (I call them App Groups) and that is what I did. To control access to the Portal Admin app, I created an App Group called Admin, very catchy name, stuck the Portal Admin app in it + a few other admin-type apps. I gave that group to 3 users; they are the portal administrators. But my developers have a need to see admin settings and also need to be able to create Environments (mostly for themselves), Groups, Categories and of course Apps. We can argue about developers being able to create groups and categories and why is that not an Admin-only activity. For now, I have chosen the approach of "overseeing" rather than "owning" that because that's too much admin work for me, turns me into a bottleneck and I don't want to be an admin control freak. In order for developers to fiddle with Group, Envs, Categories and Apps, they need to have access to the Portal Admin App. So I created another group called Development, and I stuck Portal Admin app in there as well, along with NAB and a few other Dev type goodies. I granted the group "Development" to all developers + the admins.
    But now they can do anything they want in Portal Admin and we don't want that either. Not to worry, there are ways in Portal Admin to restrict certain activities. Obviously I am restricting the "Allowed to edit settings" function to the Admin group, which equates to only the 3 administrators with the master key. Editing Apps, Groups, Environments, Categories, those activities are restricted to users that have group "Development" and now you know why the 3 admins also had to be given the Development group or they would not be able to perform those functions. The admin-function controls are all "group-based" and there's no hierarchy between groups.

    By and large this design of admin controls works reasonably well, but there are definitely cases where it's a little awkward. Environments is one such case. While I have granted my developers access to create/change/delete Environments, they cannot grant access to those Environments to users, including themselves. And that seems a little odd... I can create an environment but I can't do anything with it. Now I have to call the admin and have him modify my Valence user profile to give me access to the environment I just created. Naturally, I get this question a lot: "Why can't you give me access to Portal-Admin - Users?". Because then you can add group "Admin" to your own user profile and now you are a full blown Admin, that's why,..

    The enhancement request I submitted earlier this week for Environments was squarely intended to deal with that conundrum. Adding a checkbox to Edit-Users that, when checked, allows that user access to all Environments in existence (now or in the future). Arguably a better solution would be this: if I have the right to create environments, then I should also have rights to grant environments to users. At a minimum to myself. So, as opposed to assigning environments to users in Portal Admin-Users, why can't we assign users to Environments, in Portal Admin-Environments?

    I am curious why the mechanics of linking users to Environments is so different from linking users to Groups. If you have access to Edit Groups, you can create groups and assign groups to users. If you have access to Environments, all you can do is create them. From a security perspective, Group are far more powerful than Environments, yet they are far less secured. Environments are really just glorified library lists and I would hope nobody out there is securing his system at that level. Groups on the other hand directly control access to apps. Not only that, Groups also controls access to Portal Admin functions.

    It gets worse: given that group "Development" has the Portal Admin app in it and group "Development" is allowed to Edit Groups in Portal Admin - Settings - Groups Authorized to Administration Functions, I just handed them the keys to the kingdom... This is a loophole and I just proved that out. I signed in as a developer and this guy had no access to group Admin. He does have access to group "Development". Because the right to Edit Groups is granted to group "Development", he can do that. So he went there. He then clicked on group Admin, then Add Users and all he had to do was add himself and voila, he's a full-blown admin. ANYBODY with access to Edit Groups is 3 clicks away from being a full-blown admin, rendering all other portal admin controls completely useless.

    We need a different mechanism other than App Groups to control Administration functions. I think we should invent the concept of User Groups, or maybe Roles. I am not sure yet if you should be able to assign roles to users, users to roles or both. I don't want to create another situation where controls can easily be circumvented. Maybe it's not a Role, maybe it's just an attribute, Admin Authority True/False. Role would provide more granular control, whereas Admin Authority is just an On/Off switch. Maybe it's an "Admin Level" 0-9... Let's go with that thought for the moment...

    Where is that maintained? I think it can be under Portal Admin-Users. I think if the problem with Environments is fixed, then I can see no reason why anyone other than users with Admin Level 9 should be able to Edit Users in Portal Admin. Do we still allow people to define which Admin level is required to get Edit-Users capability in ‘Portal Admin-Settings/Portal Administration/ Administration Functions? I think so, to preserve the flexibility, but people should understand that’s where the master key is locked up. With this design, we can still allow lower level administrators (say, developers) access to Edit-Users. But only users with Admin level 9 can change the admin level of a user.
    Having Admin "levels" allows us to build an admin hierarchy, something that is currently lacking. Anyone with Admin level 9 on his user profile can do anything that requires an admin level of 9 or lower.

    Related to this topic of Admin Access... I am not sure that I like the fact that if you have access to Edit Groups that you also have access to give groups to users. I would like to see a separation of those duties, or at least the ability to separate them. Which is something that could be controlled with the New Valence Admin Level© feature. In portal Admin - Settings - Portal Administration - Maintain Admin Functions... that list of stuff that we have there now can easily be expanded:

    Function Admin Level
    Allowed to Edit groups 5
    Allowed to assign users to Groups 9
    Allowed to Edit Environments 5
    Allowed to assign users to Environments 9
    Allowed to assign admin levels to users 9

    A thought about access to functions (and with that I do not mean authority to functions). The Admin Level thing defines the authority level required to perform a given function. What I am talking about here is, if you can add users to groups in the Edit-Groups sub-app, then you should also be able to add group to users in the Edit-Users sub-app. And the same holds true for Edit-Apps and Edit-Environments. That makes it far more consistent and allows for a much more common look and feel in those sub-apps. In terms of what the sub-apps Edit-Groups and Edit-Environments are doing -- they do exactly the same thing. They let me create/delete/edit an entity (if I have the proper Admin Level) and they allow me (if again I have the appropriate Admin level) to assign that entity to users. Edit-Groups and Edit-Environments could be the exact same app. I think I would prefer that app to look more like the Edit Group app than the Edit Environments app.

    Edit Apps...
    We have (1) Basics, (2) Settings and (3) Groups.
    In Basics I do icons, colors, app name... stuff like that. That's totally a developer activity - Admin Level 3. Whether the App is Enabled or Disabled though, to me that requires a higher Admin level. That's much more of an Admin type activity than colors and icons. Admin level 5. What Group an app is in directly controls which users have access to that app. To me that's a higher level activity than picking an icon. Right now, if a developer has access to Edit Apps, they can go to any app and add it to any group, no questions asked. They could in theory assign the Payroll Inquiry app to the Shipping group and instantly all users in Shipping have the Payroll inquiry app on their portal. In the green screen menu world, maintenance of the menu system (which menus have which options and which options does what) is a restricted admin activity, as is assignment menus and options to users.

    Finally, I like how Edit-Groups shows the Group ID in the tiles. Edit-Apps shows the app ID in the grid. Edit-Users shows the user ID in grid. I find that very helpful as I often query the various VV files that use those ID numbers as their key. It would be great if we could also display the App ID, User ID, Group ID etc. on the various detail screens of their respective apps.

  • #2

    Thanks for this feedback on the functionality of Portal administration. We discussed this internally and have decided to also solicit some feedback from other customers before making any final decisions on enhancements. I think we understand what you're looking for, but we'll come back to you with any questions as we analyze this further.


    • #3
      Okay.... For a short term fix, can we at least restrict maintenance of group 2 Admin in Portal-Admin - Edit Groups to only those users that are already in that group?