Reference: Cireson Portal and Service Manager Security Configuration

Introduction

The Cireson Portal security model is a combination of the SCSM user role security model and security settings in the Cireson Portal itself. In order to properly configure security, it is necessary to understand both. This article will first explain SCSM role based security as it relates to the portal and will then describe the security settings in the Cireson Portal.

Service Manager Role Based Security

Note: The Service Manager and Service Management services must be installed on the same server, otherwise they will not function correctly.

The SCSM role based security model is organized by three concepts:

User Role Profile – a set of permissions granted to certain classes of objects. Permission types can be read, edit, delete. Example – The Incident Resolver user role profile grants permission to view and edit incidents. It does not grant permission to delete them. Microsoft has detailed documentation about the user role profiles and their permissions which can be found here.
Scope – a selection of specific objects or a group of objects that the user has permission to apply granted permissions to. Groups can be queues of work items, groups of configuration items, or service catalog groups containing service offerings and request offerings. Example – A queue of incidents where the classification is ‘HR’ called ‘HR Incidents’.
User Role – a user role is simply the combination of a user role profile (permissions) granted to a particular scope and assigned to users or groups of users. Example – the ‘HR Incident Resolvers’ user role could be defined as the Incident Resolver user role profile granted on the ‘HR Incidents’ queue and then assigned to an Active Directory group containing all of the Active Directory users that work on HR incidents.

If a user is assigned to more than one user role, the user receives the union of all of the permissions and scopes.

When creating a user role, you can choose to make the user role unscoped by choosing ‘All work items/configuration items/catalog items can be accessed’ instead of choosing a queue(s), group(s), or catalog group(s) to scope by. Any user that is in an unscoped user role will have access to all objects of that type (work items, configuration items, or service catalog items). Scopes traverse containment relationships. For example, if a user is granted permission to a queue of service requests, the user receives the same permissions on all service requests in that queue, and all activities contained by those service requests. Similarly, for service catalog content if a user is granted permissions to a service offering the user also receives permissions to the contained request offerings. If a user is granted permissions to a configuration item group, the user is granted permissions to all contained configuration items and groups recursively. If a user is given permissions to a container configuration item such as a Windows computer, the user is also given the same permissions to all contained configuration items such as network adapters, logical drives, etc.

The contents of queues and configuration item groups are updated periodically by a background workflow process called “group calc” that runs once per minute on the SCSM workflow management server. When a work item is first created, users in work item-scoped user roles will not have access to that work item until the group calc process has run and added the work item to the queue(s).

Known Issue: A known issue can occur where a user that is in a work-item scoped user role opens a new work item form in the portal, fills out the form, clicks apply (or save), and then tries to immediately make more changes to the work item before the group calc process has had a chance to add the work item to a queue that the user has permissions on. In this case the user will receive an access denied message. The same can happen when a work item is created from a request offering form and the user immediately tries to update the work item before it has been added to the queue. Essentially this same problem can also occur when the workflow service is stopped or is behind in running workflows. In that situation, the newly created work item may not added to the queue right away and the user may not have permissions granted to the work item. Similarly, if an existing work item is updated by the user the work item may move in or out of a given queue that the user has permissions to.

More information about SCSM user roles on the Microsoft TechNet Library:

Cireson Portal Security Settings

The Cireson Portal reflects the permissions granted in SCSM. The ServiceManagement DB stores a cache of work item data which is used to provide results for the following views in the Portal:

My Work
Team Work
My Requests
Team Requests
Active Work
Search
Persisted Search Views

The Cireson Cache Builder service updates the permissions to work items shown in these views once per minute to reflect changes to user role assignment, user role scoping, and changes to work item queue containment. Promoted grid views (including all the asset management views) are populated by a query to the ServiceManager (SCSM) database and therefore SCSM user role permissions are directly applied to the query. Promoted grid views do not use the cached permissions to determine access. The configuration items that are cached in the ServiceManagement database and displayed in the Configuration Items view and the Configuration Items pickers on work item forms are also access controlled according to the SCSM user role scopes. The access is updated once every hour by the Cireson Cache Builder service.

The frequency at which the cache is updated for each type of data can be modified in the C:\inetpub\CiresonPortal\bin\Cireson.CacheBuilder.WindowsService.exe.config file:

Cached work item access permissions can be tested in the ServiceManagement database by executing the following stored procedure command in SQL Management Studio:

exec spCheck_UserWorkItemPermissions 'travis','SR110'

The first parameter is the username of the user to test access for.
The second parameter is the work item ID to test access for.

Results will look something like this:

Found 1 work item(s) matching id: SR110

Work Item: SR110

- Id: 025CFA54-86E3-7990-F185-A4386C4F4CF1

- DisplayName: SR110 - Ask HR a Question

- Title: Ask HR a Question

Found 1 user(s) matching user name: travis

User: CONTOSO\travis

- Id: DB6CCEE2-A5D1-40AF-1CE9-264B6997E7D7

- Domain\UserName: CONTOSO\travis

- DistinguishedName: CN=travis,CN=Users,DC=contoso,DC=com

- Is Analyst

- Is Knowledge Manager

- Is Asset Manager

- Has Permission to Access ALL Work Items in the System

If you receive a result like this then the work item does not exist in the ServiceManagement database:

Found 0 work item(s) matching id: SR11011

This is likely because the work item has a status of Closed or there is a problem with cache builder.

Similarly, access to a request offering can be checked using the following stored procedure command in the ServiceManagement database:

exec spCheck_UserRequestOfferingPermissions 'travis', '98B0478E-9545-0745-4B39-6C4F57A0A44F'

The first parameter is the username of the user to test access for.
The second parameter is the request offering ID to test access for.
If you don’t know the ID of the request offering you can run this query in the ServiceManagement database:

SELECT ID,Title FROM RequestOffering.

Analysts, Knowledge Managers, and Asset Managers Groups

At install time of the Cireson Portal, the installer prompts for three Active Directory groups: Analysts, Knowledge Managers, and Asset Managers. After installation is complete, the Cache Builder enumerates the membership of these groups in Active Directory and flags each user in those groups as being an analyst, knowledge manager, or asset manager, or some combination of those or none of those. Members of these groups have special permissions in the Cireson Portal:

Analysts - Users in this group can see the following views (depending on which product keys are installed) by default: Home, My Requests, Team Requests, My Work, Team Work, Search, Dashboards, Knowledge Base, and Configuration Items. They can also see the New menu and the Work Item menu on that menu to be able to create new work items. Analysts can also see the quick search bar in the header area to find a work item by ID quickly. Analysts can also use Advanced search in the knowledge base.
Knowledge Managers - Users in this group can see the New menu option for creating knowledge articles. On the knowledge article search page and the knowledge article view page they also get the option to edit the knowledge article.
Asset Managers - Users in this group can see all of the asset management views out of the box and can view/edit assets and create new assets from the New menu.

Note: these AD groups should belong to the same domain as the service account, but may contain users from another domain.

After Cache Builder has populated the initial permissions you can run this query in the ServiceManagement DB to see which permissions a given user has. Change the username from 'Travis' to whatever user you want to query permissions for.

SELECT UserName,Analyst,KnowledgeManager,AssetManagerFROMCI$UserWHEREUserName='Travis'

Any user that is a System Center Service Manager administrator (i.e. a member of the SCSM Administrators user role) is also an administrator of the Cireson Portal. Make sure that your Administrators are in the Knowledge Base, Analyst and Asset Manager role to allow them to see all options available in the portal. In addition, they have access to additional administrative menu options: Admin Settings, Navigation Settings, Enumeration Settings, Manage Announcements, and API Documentation. Administrators can also create new announcements.

Troubleshooting Common Security Configuration Issues

Here are several guides on troubleshooting common security configuration issues:

Additional Related Reading

Scenario Q&A

End User Access to Manual Activities and Review Activities

Scenario: In my lab I have a user who is just in an End User use role. This user can view review activities and manual activities that are assigned to himself in the My Work view, but if the user clicks on one of them and tries to access a manual activity or review activity in the context of a change request or service request form the user gets a permissions denied error message.

Answer: This is happening because according to SCSM the user has permission to view/edit the Manual Activity and/or Review Activity according to "implied permissions" which basically says that if a user is related to a certain object by a certain relationship type then the user gets certain permissions on that work item. For example, any manual activity that a user is assigned to, the user has permission to edit. Any reviewer object that a user is assigned to the user has permission to edit. The problem here happens because the user does not have access to read the parent service request, change request, or other type of top level work item. The Cireson Portal tries to display the manual activity or review activity in the context of the parent work item - service request, change request, etc. - to provide the activity implementer or reviewer some context on what he is working on/voting on. Therefore the end users that are working on these kinds of things also need at least read access to the parent work items. An administrator should create a user role based on at a minimum the read only operator user role profile or end user user role profile that has a scope of work items that is appropriate to groups of users depending on what they would typically be working on.

The data model for work items looks like this:

Some kind of parent work item (service request, change request, release record, or incident typically) CONTAINS activities (manual activity, review activity, parallel/sequential activity, runbook activity). In some cases activities can CONTAIN other activities in a hierarchy (parallel and sequential activities). A review activity CONTAINS reviewer objects which are related to users by the ReviewerIsUser relationship. Keep in mind that when a user has certain permissions on a container object those permissions also are applied to the contained objects. For example, if a user has permission to read a service request the user can read all of the activities contained by that service request.

Let's say for example that Joe is a user that is responsible for reviewing service requests in the networking department. If Joe is a reviewer on a review activity he already has permission to change the Decision (approve/reject), Comments, and DecisionDate properties of the Reviewer object because Joe is related to the Reviewer object by the ReviewerIsUser relationship type. Joe can also set the ReviewerVotedByUser relationship between the Reviewer object and any other user that Joe has scope on. More information on the ImpliedReviewer user role profile can be found on the TechNet Library SCSM Administration Guide - Appendix A.

Note: the solution below requires version 3.6 + hotfixes or higher.

However, in order for Joe to be able to at least read the parent review activity and service request he needs to get scoped access on the service requests that he will be approving. The first step in this process is to create a queue that defines the scope of service requests that Joe should have access to. That scope could be as broad as *all* service requests or it could be more narrow by using property criteria such as Area = Networking. Find information on creating a queue on the Microsoft TechNet Library. Once the queue has been defined, then it can be assigned to a user role. Find information on creating a user role on the TechNet Library. In this case, a new End User user role could be created, scoped to the networking service requests queue and Joe can be added as a user to that user role. This will give Joe read only rights on the service request and everything that it contains including the review activity and the reviewers. He can only edit the reviewer object that is associated to himself though - i.e. he can change the Decision, DecisionDate, and Comments properties and set the ReviewerVotedByUser relationship to himself. Joe will see the review activities that he is a reviewer on in his My Work view (if the 'Show Activities' checkbox is checked). Clicking on a review activity will display the parent service request work item and it's child activities with the review activity that was clicked on being expanded by default and the focus put on it. Although the form will appear that Joe can change anything on it, in fact Joe can only change the reviewer object that is related to him. Any other change will be rejected by SCSM.

A similar approach can be used for any other type of top level parent work items such as change requests, release records, etc. Just create a queue scope of the work items you want to grant to the approvers and add that queue to the custom end user user role.

The same type of use role configuration is required for manual activities. Any user that is assigned to a manual activity (or any activity for that matter) has permission to edit any property of that activity and anything that it contains via the ImpliedActivityEditor implied user role profile. More information on that implied user role profile can be found in the TechNet Library SCSM Administration Guide - Appendix A. For example, any user that is assigned a manual activity will see that activity in his My Work view as long as the 'Show Activities' checkbox is checked. Clicking on that manual activity will open the top-level parent work item form and automatically expand the manual activity form for that manual activity and set focus on it provided that the user has queue scope on the top level parent work item as described above. Because the user is assigned to that manual activity, the user can change any property of that manual activity and save it, but doesn't necessarily have edit permissions on the top level parent work item or the other activities.

Cireson Portal User Types

The Cireson Portal contains several user types whose permissions are a combination of rights granted from System Center Service Manager (SCSM) and rights granted inside the Cireson Portal.

Administrator

The Administrator user types has rights to:

All portal views (See below note)
Create/modify/delete announcements
Change localization strings
Admin settings
Navigation settings
API documentation

Additionally, the Administrator has full access to all work items and configuration items.

Note: An administrator will still only see those views which are either public or which are granted to a group which he/she is a member of. Of course, administrators has access to Navigation Settings and so can therefore grant themselves permission to whatever view they want.

SCSM Configuration: The Administrator user accounts must be included in the SCSM Administrator User Role

Portal Configuration: The Administrator should be included in the Analysts, Knowledge Base Managers, and Asset Managers groups for access to those specific role rights in the Cireson Portal.

Analyst

The Analyst user type has rights to:

The +New “drawer” menu and is able to create work items from work item templates, , and has rights to the following portal views:
Team Work
Active Work
Search
Knowledge
My Work

Additionally, Analysts have rights to the following Work Item Tasks:

Change Status (Complete/Resolve)
Link to/Convert to Parent
Copy to New
Assign to Analyst by Group
Assign to Me
Acknowledge
Send Email

Portal Configuration: The Analyst group is chosen during the portal Installation process. The AD group can later be updated through the SettingsItems UI. Analyst access to create specific types of work items or take specific actions such as reviewing review activities or completing manual activities can be further scoped down to specific groups within the Admin Settings page of the portal. If the group is changed the cache builder service should be restarted.

SCSM Configuration: Analyst accounts must be imported into SCSM through an Active Directory (AD) Connector. They must also be a member of at least one of the following user roles within SCSM: Incident Resolvers, Service Request Analysts, Change Managers, Problem Analysts, Advanced Operators, or Authors User Roles. Analysts require access to the work item queues, configuration item groups, catalog item groups, and forms templates, that they require. . Finally, the incident and service request support groups enumerations the analysts are associated with should all be mapped within SCSM to the appropriate AD groups within the Portal Group Mappings Setting (Administration --> Settings --> Portal Group Mappings).

KB Manager

The KB Managers are able to create, edit, and delete KB articles as well as change the KB enumeration settings.

SCSM Configuration: The KB Managers group and members must be imported into SCSM through an AD connector. They must also be a member of at least one user role within SCSM.

Portal Configuration: The KB Managers group is named during the portal Installation process. The AD group can later be updated through the SettingsItems UI. If the group is changed the cache builder service should be restarted.

Asset Manager

The Asset Managers have permission to create/edit/view asset related data in the Cireson Portal.

SCSM Configuration: The Asset Managers group and members must be imported into SCSM through anAD connector. They must also be a member of the Advanced Operators user role within SCSM. Further, they need access to Cireson Asset Management within the console and should have had the Cireson permissions tool run against them to grant access to asset management

Portal Configuration: The Asset Managers group is named during the portal Installation process. The AD group can later be updated through the SettingsItems UI. If the group is changed the cache builder service should be restarted.

End User

Portal end user have scoped access to the service catalog and are able to use it to create incidents and service requests. They have access to the following portal views:

Home
My Requests
Team Requests – if configured
Knowledge - end user content only
My Work

End Users also have access to the following Tasks:

Reactivate
Cancel

End Users can also be granted rights to approve or reject review activities, or to complete or cancel manual activities.

SCSM Configuration: End users must be imported into SCSM through an AD Connector. They must also be included (usually as a member of the Domain Users AD group) within a custom end user SCSM role. Cireson recommends removing all users from the default SCSM End Users role and creating a new End User user role specifically for the Cireson Portal. The End User role must have appropriate access to the required queues and service catalog groups for the portal end users.

Portal Configuration: Within Admin Settings, end user rights can be scoped down to specific groups within the Admin Settings page of the portal. After making this change the web site should be restarted.