Roles and Permissions Beyond IT

Document created by Chad Brown on Aug 5, 2016Last modified by Chad Brown on Aug 5, 2016
Version 2Show Document
  • View in full screen mode

In our environment we were barely a month into the use of Samanage for IT when it was deployed Beyond IT, so we quickly encountered issues with Permissions. This got more complicated when Human Resources was added to the application for HR Answers (Catalog items where employees could submit questions to HR, from general to extremely specific and personal).


We approached the Roles and permissions to handle this inclusion from a Windows-centric standpoint, and it caused us problems for nearly a year. After working with the application and Brendan Cooper (@ samanage), we found the application uses permissions more akin to an ACL. I am sharing this in hopes of helping other people that might be struggling with the permissions, or are in the process of trying to integrate Non-IT departments into the application.


How We Failed?

As mentioned previously, we approached the permissions in the application from a Microsoft standpoint. We are a Microsoft shop, so it was just habit. In the Microsoft world of permissions, the MOST restrictive is almost always applied, regardless of exceptions.

Example: I have a folder and I want to restrict permissions. If I default the Everyone group to Denied, regardless of what specific permissions I scope out, by security group or individual user, they will always be overridden by the most restrictive permission of Denied.


After adding the Category of Human Resources to the Incident Module, we thought we had to remove the [Manage | All] and [Manage | Incidents | "All"] permissions from our Roles. After all, that would grant someone the ability to read ALL Human Resource incidents, including PII and HIPAA material.


We did initially keep the  [Manage | All] and [Manage | Incidents | "All"] , but added the [Restriction | Manage | Incidents | Category: Human Resources] and thought we were good to go. This proved false about two weeks later, when no in IT could Submit questions to Human Resources for their own issues (the application would deny the person the ability to "create" the Incident as the Catalog Items for HR questions default category was Human Resources).


This meant we had to grant each Category of access and each Module of access needed by IT and each other Beyond IT department in the application (which now included Facilities and Real Estate, Corporate Communications, Core Operations, and Human Resources). Of course, we were wrong - but we just didn't know it yet.


Below is the Role we had to assemble for our Service Desk personnel (I apologize in advance for its length).



As additional Categories were added to the application, we had to add lines for those. To keep the Role "easy to read" we would have to re-create it so all the permissions were grouped together (otherwise you get five or six [Manage | Incidents | Category: Blah] at the bottom of the permission listing.


How We Eventually Succeeded?

That was our failure, get locked into the Windows permissions mindset. After speaking with Brendan Cooper (Brendan Cooper) and running through some tests we were able to confirm the following.


The application reads permissions and restrictions line-by-lined; modifying the previous permission/restriction with the next line. Here is our new Service Desk Role, and the line-by-line explanation of the permissions/restrictions.



Permission | Manage | All : this grants full access to the application; all modules, the setup, everything. On its own, Full Admin.

Restriction | Read | Incidents | Category: Human Resources : this appends the "Full Admin" by stating this person can no long READ any incidents where the Category is Human Resources.

  • This does not negate the ability to CREATE or UPDATE these.
  • This is particularly useful when someone submits an incident that should have gone through the HR Answers Service Catalog.
    • The Analyst can change the Assignee and re-categorize the Incident to "Human Resources" and click "Update Incident"
    • The Incident is now Assigned to HR, and the categorization is correct
    • As the Analyst does not have READ permissions, they can no longer see the Incident on the Incident Index screen, they are also unable to find it in a Search, and even if they have a URL to the Incident, they get a permissions error trying to get to it

Restriction | Manage | Setup : this removes all Access to the Setup (administrative section) of the application. Makes sense, except for the USER creation part - but Samanage is addressing that.

Restriction | Manage | Benchmarks : this removes all Access to the Benchmark module of the application. The Benchmark is beyond the scope of Service Desk analysts. Additionally it contains compensation information, benefits, and the like that should be used by IT Management only.

Permission | Manage | Incidents | Requester: -- Requester -- : this is the first "Permission" granted after the Restrictions, so the application will "carve" this permission out of the restriction block as an "except" style statement.

  • This builds a complex statement when combined with [Permission | Manage | All] and [Restriction | Read | Incidents | Category: Human Resources]
    • Manage All Incidents, except no READ access when Category = Human Resources
    • No READ Access when Category = Human Resources, except when Requester = Requester

Permission | Manage | Incidents | CC'd on: -- Requester -- : this is the second "Permission" that carves out against the Human Resources restriction.

  • Again this builds a complex permission statement of:
    • Manage All Incidents, except no READ access when Category = Human Resources
    • No READ Access when Category = Human Resources, except when a CC: of the Requester is added
  • This was added so an Analyst could ask a question of HR and CC their Manager, and their Manager would be able to see the Request

Restriction | Delete | All : Pretty clear, you cannot delete anything. As the last line of the Role, there are no exclusions cut out from this.



I hope this information is useful to anyone else looking to integrate Non-IT groups into the Application (especially ones involving sensitive information); or maybe you are just looking for a more simplified set of permissions.


Brendan Cooper

11 people found this helpful