Personas and Roles - Bringing order to access chaos

[SaschaWildgrube]

Managing access to specific users or groups of users can be confusing. It is helpful to agree on terminology in the first place:

A role (in the ServiceNow context) is a type of configuration that links users or groups to specific access rights (like the write access on record of a specific table, a UI Action, or access to a specific REST API endpoint). A role is a technical asset – a record stored in the sys_user_role table.

A persona is a description of a group of human beings (or an individual). This description is provided from a business perspective. A persona is agnostic to any technical implementation. Some personas may not even interact directly with a system (specifically with a ServiceNow instance) and yet be very relevant to a business process.

The tricky part is to transform requirements which usually contain references to personas into technical configuration and logic.

As a “Help Desk Agent” (the persona) I want to be able to see all open incidents.

The OOTB role “sn_incident_read” provides read access to incidents, so assigning the role to whatever group constitutes the “Help Desk Agents” sounds like a good solution.

It is generally accepted good practice NOT to assign roles to users directly but to groups instead.

Let’s assume there is one (or more) groups that contain “Help Desk Agents” so assigning the sn_incident_read role to these groups appears reasonable.

This approach raises several questions:

1. Is the fulfillment of the above requirement targeted at the development team or at the operations team? Assigning roles to groups is a data change, not a code change.
2. How can the fulfillment of this requirement be tested?
3. What if “Help Desk Agents” are not only supposed to read incidents, but also to modify them – and do many more things: shall all the different roles that are required then be added to these groups?

If the answer to the first question is: the requirement is targeted to the development team and hence the implementation should materialize as some form of code (in a wider sense) then the approach to assign the specific role to the group cannot be the solution.

After all, code must not depend on data. But what is the alternative?

Introducing the concept of the persona role. A persona role is a role that represents a persona. Such persona roles are named after the persona and contain whatever specific other roles required to allow (and deny) access to the users that belong to that persona.

As every other role it should not be assigned to individual users but to groups.

In the example the “Help Desk Agents” would be represented by a “persona_helpdesk_agent” persona role (which is part of an application) and the persona_helpdesk_agent role would then contain sn_incident_read role (and probably also sn_incident_write and many other roles).

Persona roles should be prefixed by the application scope name followed by “.persona_” – e.g., “x_yourprefix_platform.persona_helpdesk_agent”.

The implementation of personas (as an expression of business requirements) is now represented as a code asset which is fully testable with no dependency to production data.

If there is no documentation or concept of personas available yet, here is a list of usual suspects to start with:

• Business User
• Business User Team Manager
• ServiceNow Administrators
• Service Desk Agents
• Service Desk Supervisors
• IT Service managers
• CIO
• CIO Staff
• IT Expert (Fulfiller)
• IT Expert Team Manager
• HR Business Partner
• HR Business Partner Team Manager

Note that personas should be designed with the production environment in mind. A group of users might have different access rights in different environments. E.g. developers might have admin access on the development instance, but not on test or production. Instead, they might “only” have access to a backlog management tool in production and read-only access on the test environment. The developer persona in that scenario should be designed to reflect developer access in production and only allow access to the backlog management tool.

Persona roles may contain roles defined in other applications and OOTB roles – which implies a dependency from the application that contains the persona role to those applications which define other, more specific roles.

As a result, the best place to define the persona roles is the Platform application (as described in chapter “Application Architecture and Dependency Management” in the whitepaper). The Platform application is the root of the dependency tree – nothing depends on it, but it depends on every other application. This makes the Platform application the natural place for persona role definitions.

It should even be avoided to establish any logical dependency to a persona role. No ACL, no business rule, no UI Action, nor any other application file should depend on (i.e. reference) a persona role. This is not only to avoid circular dependencies, but also to make a clear distinction between a regular role, which allows access to specific capabilities and data, and a persona role that should act as an umbrella for the access. Ideally any custom defined role is part of a re-usable application that may provide value to multiple production instances within the same organization or that may even be re-used across organizations. Persona roles are typically specific to the instance and its use case and tightly coupled with the demands (and naming conventions) of the organization.

When implementing persona roles, it should be considered to

• Validate that only persona roles are assigned to groups directly
• Roles are never assigned to users directly
• Ensure that persona roles are defined in a specific application

The open-source application “DataSanity” contains all technical capabilities to

• Validate that only persona roles are assigned to groups directly
• Roles are never assigned to users directly (except to technical users)

The open-source application “CodeSanity” contains all technical capabilities to

• Validate that an application does not depend on another application that contains persona roles – and as a result, persona roles are defined only in platform applications that do not have any upstream dependencies

Persona Access Matrix

Security starts with a proper definition of who should be able to access what. Any requirement should contain such statements. But making these statements in a meaningful way is difficult without the necessary pre-work.

The Persona Access Matrix is one (out of many) way(s) to develop and document access and security requirements.

As the name suggests it is a matrix with personas on one dimension and the allowed access on the other dimension.

A “persona” refers to a group of users with identical access to a system. This does not mean that each member of that group sees the exact same data.

For example. the persona “End User” may see tickets that they opened by themselves. This statement is applicable to every single user of that persona, but each user sees different tickets.

The following example matrix can serve as a starting point – it is in no way complete:

	Employee	Service Desk Agent	IT Team Member	IT Manager
Access to Employee Center Service Portal	YES	YES	YES	YES
Can see and edit incidents opened by themselves	YES	YES	YES	YES
Can see and edit all active incidents currently assigned to their team		YES	YES	YES
Can see and edit all active incidents		YES		YES
Can create reports on all incidents				YES

The persona Access Matrix defines both accesses controlled by roles and access that is controlled by filters on data – i.e. data segregation requirements.

Read the full story here:

https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf