Understanding The Basics Of Security And User Scoping In The SCSM Console And The Cireson Portal

Best practice when using the Cireson Portal

• Add administrators to the default out of box Administrators User Role.
• Add workflow accounts to the default out of box Workflows User Role.
• Do not use any other out of box roles, always create new User Roles based on the out of box roles.
• Minimise the number of User Roles and Queues, reducing the number of roles will increase performance. More importantly a large number of roles can easily become hard to manage and contradictory resulting in unexpected and undesired behaviour.
• Only provide access to an object in one role at a time, this ensures that should you ever need to modify the access to the object you need only modify one role.
• Add Active Directory groups to User Roles instead of users, this again reduces management.
• We recommend the following:
  • Out of box Administrator role for administrators
  • Custom role based on Advanced Operator for analysts
  • Custom role based on End Users for end users

Important notes when using the Cireson Portal

• Currently the Cireson Portal can only restrict access to Catalog Items at a Service Offering level, any restrictions on individual Request Offerings will not take affect in the Cireson Portal.
• To grant a user access to anything in the Cireson Portal the user must have access to the parent Work Item. For example a Review Activity that is the child of a Service Request will not work without access being granted to the Service Request as well.

Understanding User Roles

To build a User Role in SCSM you have to understand that it is comprised of two components. The first of these is the User Role Profile, this grants the type of permission, e.g. read and/or write. The second is the scope, this dictates the objects a user has permission to. These are then combined to create a User Role, both of these elements are discussed in more detail below.

User Role Profiles

The following is a brief overview of each of the User Role Profiles in SCSM. All User Role Profiles grant read access.

• Read-Only Operators: Read access to everything.
• End User: Can create Work Items.
• Incident Resolvers: Can create and edit Incident Requests, Problems and Manual Activities.
• Change Initiator: Can create Change Requests.
• Activity Implementers: Can edit Manual Activities.
• Problem Analysts: Can create and edit Problems.
• Service Request Analysts: Can create and edit Service Requests and Activity Work Items, e.g. Review Activities and Manual Activities.
• Release Managers: Can create and edit Release Records and Activity Work Items, e.g. Review Activities and Manual Activities.
• Change Managers: Can create and edit Change Requests and Activity Work Items, e.g. Review Activities and Manual Activities.
• Advanced operator: Can create and edit any Work Item as well as creating, editing or deleting Announcements.
• Authors: Can create and edit any Work Item or Configuration Item, create, edit or delete Announcements and make basic changes to Management Packs.
• Administrators: Full access to everything.

Basic definitions of object types

• Work Items: The components of the SCSM service catalogue, Incident Requests and Service Requests are the most prominent of these.
• Configuration Items: Objects in SCSM, frequently brought in from outside SCSM, for example Active Directory users, groups and computers.
• Catalog Items: Service Offerings and Request Offerings, these are used to build the catalogue that Work Items are a component of.
• Templates: These control how the data returned from the database is organised when an object is opened.

Scopes

• Queues: Restrict access to Work Items, it is important to remember that each Work Item type requires a separate queue. For example Incident Requests cannot be in the same queue as Service Requests.
• Configuration Item Groups: Restrict access to Configuration Items, these can be configured as static or dynamic groups and can include any type of Configuration Item. For example you can group together users and computers.
• Catalog Item Groups: Restricts access to Catalog Items these can also be configured as static or dynamic groups. Please note that currently the Cireson Portal can only restrict at a Service Offering level, restricting at a Request Offering level is not currently supported.
• Form Templates: Restricts access to templates, this includes templates in the Portal (New->Work Items->Create from Template)
• Users: Specify the groups (as best practice) who will have access to this role. Please note that these must first exist in SCSM having been imported by the Active Directory Connector.

We also see confusion between queues and views, a queue is a security component granting permission to Work Items (whether to view or modify depends on the User Role Profile selected). A view on the other hand is just a way to split up Work Items into more easily managed collections, it has no affect on security.

Review Activities

As Review Activities are Child Items it can be easy to not know how to correctly configure security for them.

For a user to be able to approve a Review Activity the user must:

• Be able to see the parent Work Item that the Review Activity is a child of.
• Be in the Approve and/or Reject Review Activity AD group.
  • Alternatively if this setting is left blank all users can approve and/or reject activites.
  • This setting can be found under Admin Settings on the Portal.
• Have the Review Activity assigned to them.

If the user can see the parent Work Item but does not have the Review Activity assigned to them then they will still be able to see the Review Activity. However if they try to approve or reject it they will receive an error stating from SCSM stating that they do not have permission.

For additional assistance, please visit the Cireson Community or contact team@cireson.com.