Working with Personas

TrustBuilder fundamentally implements the model of “every user has one and only one profile” even if the person has different subscription accounts and even when the person works with different mandates or in different capacities. To enable this, TrustBuilder introduced its persona-model. A user profile in TrustBuilder can embody one or more “personas”.

What is a persona?

A persona in TrustBuilder reflects the type of activities a users wants to undertake and allows these activities to be clearly segregated, for reasons of user convenience and/or for reasons of security. TrustBuilder policies use the selected persona to decide whether certain activities can be granted or not.

For example, a person can be a retail customer or be mandated for administrative tasks on behalf of her company. Depending on the relationship with the enterprise, a user has more or less privileges. More privileges typically represent more authority but also more risk. To reflect the fact there are different types of users, TrustBuilder introduces the “persona” concept. The TrustBuilder identity and access management model is based on personas. This means that depending on your persona, different rules may apply, different workflows may apply, different ways of orchestrating delegation may apply and different levels of identity proofing may apply.

The TrustBuilder persona models goes even one step further. Imagine she is both a retail customer and representing her company. In that case, TrustBuilder still recognizes her as the same individual with only one profile but with two ‘personas’ in her user profile. Each persona in her user profile corresponds to one of the roles she can assume. This way a user in TrustBuilder can belong to more than one user segment: an individual can assume of the role of retail customer and of corporate customer

Another example is a person who is a health care professional, but who can at one point also be a patient herself. Or a professor at a university who can also become a student for particular post-university courses. Or a staff member can equally be a retail customer of the same company. Or a person may be part time in one team and part time working for another company. Or a person may be a software developer who, in times of emergency, needs to help out in operations.

Using TrustBuilder, a user logs in with a single user profile - there is only one, even if the person can act in different capacities or needs different accounts in different systems. At login, the user selects a specific persona or uses their preferred persona by default. Afterwards, and without a new login, the user can switch to a different persona when relevant or required. Even though this happens within the same session of the user, an authorization policy may state that switching to a privileged persona requires additional authentication (step up authentication).

Why using personas?

By introducing the concept ‘persona’, authorization policies can rely on attributes that reflect a mandate or capacity that a person plays at that time. A TrustBuilder ‘persona’ embodies attributes that are specific for that mandate or capacity and can be self-declared.

The “persona” model enables the user base to be segmented (but without hard borders because users may belong to more than one segment, i.e. have more than one persona). The “persona” model enables differential lifecycles, provisioning workflows, authentication and authorization policies (depending on selected persona). The “persona” model also enables delegated administration to be scoped to th attributes of a specific persona only, without affecting other parts of the user profile. The top-level user profile thus stays under control of the enterprise

Additionally, TrustBuilder offers a full approval mechanism for self-declared attributes to delegate administration to the end users.

With its persona-driven authorization policies, TrustBuilder:

Enables Delegated Security Administration whereby security admin (indeed!) is moved to people close to the end user. This is in contrast to having a sysadmin assign permissions, roles and groups. Delegating security administration to the people themselves, fosters timeliness, accuracy, appropriateness, and freshness.
Enables User Lifecycle Management to be done at the persona level rather than traditionally at the ‘user account per application’ level. This means that when a person leaves a function, her accounts do not need to be deactivated: only the associated persona needs to be deactivated. It also allows people to already start using their account, even before their persona ‘employee’ has been activated.
Enables effortless implementation of Segregation of Duties, by having different personas corresponding to different duties.
Enables straight-forward implementation of Privileged Access Management. For example controlled ‘privilege elevation’ during emergencies is easily implemented by using different personas and have the authorization policy take care of additional authentication and the logging of activities.
Enables a policy-driven implementation of User Managed Access. For example, a person may grant access to her diploma details by stating what persona is required for getting access, typically the persona ‘hr-manager’.

TrustBuilder personas bring the management of access control to a new level: it easily combines the benefits of RBAC and ABAC while simplifying its administration. In fact, delegating persona administration using TrustBuilder allows access to be controlled at massive scales: no longer is a central sysadmin group needed to assign permissions, access rights, roles, and groups to end users. Instead, delegated persona administration puts people in the center of their own administration: they manage their own attributes and personas and therefor their own access.

Guidelines: types and scopes of personas

When to create separate persona-types? As a general rule of thumb, a persona-type denotes a user segment in business terms. You may have a user segment of employees, one of consumers and one of corporate customers, one for suppliers, another for distributors and resellers, etc. Since a person may be assigned one or more persona-types, that person can belong to one or more user segments. For example, an employee can also act as a consumer at times.

A persona inside a user profile is uniquely identified with the persona-type in addition to the persona-scope. The persona-type indicates the category, the type of relationship, the business role (e.g. “employee”, “consumer”). The persona-scope refines this to say for which company, region or other characteristics this applies. For example, the scope for an “employee” persona will contain the name of the employer. The scope for a “service-desk-operator” may refer to the region they are responsible for.

How granular should the persona type be? In the design of persona types, it is important to keep in mind that TrustBuilder gears identification and access control, which implies policies, workflows, and lifecycle management. For example:

While an office employee may need access to enterprise applications, non-office employees may only need access to the payslip and holiday request aspects of the HR service. In this case, it makes sense to have two different personas: “office employee” and “non-office employee.” Additionally, you may have employees on the payroll and contractors. But from an access point of view, their may be no difference between the two categories. In that case, it does not makes sense to differentiate between an employee and a contractor and to generalize the personas to co-worker: “office-co-worker” and “non-office-co-worker” rather than “employee” versus “contractor.”
While a consumer can enroll on their own initiative, a customer could also be enrolled by their company in a form of delegated administration (see below). In that case, it may make sense to a differentiate between “retail customer” and “company customer”. The reason being that the lifecycle of a “retail customer” is managed by the customer themselves, while the lifecycle of a “company customer” is managed by their company. On the other hand, a consumer who has bought two categories of products does not need a persona for each product: this is dealt with in the scope attribute. Additionally, individual subscriptions can be dealt with by the entitlements attributes.

In the design of the User Profile, you have the choice of putting attributes at top level or at the persona level. What rules of thumb to apply?

A top-level attribute says something about the individual, independent of the type of role that individual can assume. Example top-level attributes are name, title and preferences such as preferred language, preferred communications channel.
Persona-related attributes refer to attributes that are specific to the business role it represents. For example, a supplier persona may include the supplier-id in the ERP, while a consumer persona may include the customer-id in a CRM. An employee persona may also include the AD account(s) for accessing enterprise applications.

Guidelines: using personas for delegated administration

The “persona” concept is also a key ingredient for Delegated Administration in TrustBuilder. Delegated Administration means that user profiles are not only created and maintained by a Service Desk, but can also be managed by end users. For example:

Self-service: an individual may create create a profile and add information themselves (delegation the profile owner)
Team leaders: a team leader may create and update the user profile of a team member
Partners: a supplier, a dealer, a distributor, a reseller or an installer may create and update the user profile of their employees themselves
Branches: a branch, a shop or a region may create and update the user profile of the people in scope on behalf of the user
Organization: a company, organization or association may create and update the user profile of their members
Family: a household or private club may create and update the user profile of their family members

In all these cases, it is not the Service Desk but one of the end users who does (some part of) the user administration in a delegated way. Because it is much closer to the profile owner, Delegated Administration offers some key advantages:

less work or the Service Desk since they will onyl need to deal with exceptions
less delays since it is not driven by anonymous service tickets but by human interaction
more accurate because the administrator knows the profile owner’s context much better.

TrustBuilder, however, adds a unique feature to Delegated Administration. Thanks to the “persona” concept:

because every individual has only a single user profile, they own it: they can create it or activate it and they set their preferred username, their full name, their title, and their preferred language.
a delegated person can only create or update persona-related attributes: the user profile remains owned by the holder and the delegated person can only add or change one of the personas. For example an indivual may have a user profile for e-commerce, and thus have a “consumer” persona. Their employer can add a “co-worker” persona with its specific company-related attributes.
a delegated person can only create or update a persona with the same scope. For example, a HR manager can add a “co-worker” persona only for the brach or region they are responsible for. An indidual can thus have a persona “co-worker” with scope “West” and another persona “co-worker” with scope “East” that is managed by a different HR.

What if an individual does not have a user profile yet? The action of “adding” a persona will then typically first implicitly create a user profile to which the first persona will be added. The fresh user profile then needs to be ‘activated’ by the owner during which the owner can add their consent, can enter or correct their full name and can add an authentication factor.

Guidelines: relating personas to role and group provisioning

Many enterprise applications today are controlling access using permissions. Permissions may be grouped into “roles” or “groups”. For example SAP has roles and compositie roles. Also Salesforce uses roles to specify the levels of access of a user can. Microsoft applications use Activate Directory groups. So, how does this relate to personas?

In contrast to such technical roles, a ‘persona’ refers the real-life function, capacity or mandate of a person. It is an attribute that people can easily relate to in real-life: “yes, I’m a consumer buying products” or “yes, I’m an employee at this company.” As such, personas are business and person-centric.

Roles used in the context of Role-Based Access Control (RABC), on the other hand, represent permissions relative to an application. RBAC roles are application-centric. Roles are then assigned to users.

Since many enterprise applications need roles, how does TrustBuilder bridge personas with roles? TrustBuilder allows the roles to be registered inside a persona of a user profile, using the entitlements attribute. This attribute is used to provide service providers and applications with the roles they need, either during the provisioning flow, or as custom claims in the access token. This means that TrustBuilder maps a persona onto permission-roles using the entitlements attribute to enable it to feed RBAC systems when needed. TrustBuilder implements a Policy-Based Access Control (PABC) model, which does not need roles. A customer, however, can take the entitlements attribute into account when designing rules for an Authorization Policy.

The next section shows some use cases of multiple personas for individual users. Of course, many users will only have a single persona, e.g. 'staff member' or 'consumer'. The examples show how authorization decisions can be influenced by selecting the right persona when a user has more than one persona.

Use cases

Use case 1. Privileged Access

If an IT-er is doing only office work, she can use the persona ‘staff’ and when she manages the settings in a software platform, she can switch to her ‘operator' persona. When using the latter persona, she will be able to conduct sensitive operations on a production system. The authorization policy may also forbid her to use read her email using this persona, to be shielded from phishing attacks.

JSON

"personas": [
{
   "persona_name": "staff",
   "scope": [ "chemco" ],
   "entitlements": [ "office365", "sharepoint_team_A" ],
   "email": "an.janssen@chemco.com"
},
{
   "persona_name": "operator",
   "scope": [ "chemco" ],
   "entitlements": [ "office365", "windows_servers" ],
   "email": "an.janssen@chemco.com"
}
]

Another example is a person who performs office work and from time to time helps out in the customer services team.

JSON

"personas": [
{
   "persona_name": "staff",
   "scope": [ "chemco" ],
   "entitlements": [ "office365" ],
   "email": "jan.janssen@chemco.com"
},
{
   "persona_name": "user-admin",
   "scope": "chemco-region-west",
   "entitlements": [ "office365", "sharepoint_helpdesk" ],
   "email": "jan.janssen@chemco.com"
]

Another example is an HR manager who can do administration in an HR platform, but who is also employee using the HR platform for her own pay slips and holiday requests, for which Segregation Of Duties is required.

JSON

"personas": [
{
   "persona_name": "customer_hr_manager",
   "scope": [ "chemco-region-west" ],
   "email": "hr_management@chemco.com"
 },
{
   "persona_name": "customer_employee",
   "scope": [ "chemco" ],
   "email": "an.janssen@chemco.com"
}
]

Use case 2. Job Cumulation

A person may be part time working for one team and be part time working for another team. To implement Segregation Of Duties for certain activities (or to simply avoid that documents are misplaced in the wrong team folder on Sharepoint), the person may be given 2 personas, one for each team. The authorization policy may state that for a number of activities it does not matter which persona is selected, and that for specific sensitive activities the selected persona does matter.

JSON

"personas": [
{
   "persona_name": "staff",
   "scope": [ "team-A" ],
   "entitlements": [ "office365", "sharepoint_team_A" ],
   "email": "jan.janssen@chemco.com"
},
{
   "persona_name": "staff",
   "scope": [ "team-B" ],
   "entitlements": [ "office365", "sharepoint_team_B" ],
   "email": "jan.janssen@chemco.com"
}
]

Another example is a person who is the supervisor of a team and who may also be delegated the supervisor role of a seocnd team during the absence of their supervisor.

JSON

"personas": [
{
   "persona_name": "staff",
   "scope": [ "team-A" ],
   "entitlements": [ "office365", "sharepoint_team_A" ],
   "email": "jan.janssen@chemco.com"
},
{
   "persona_name": "supervisor",
   "scope": [ "team-A" ],
   "entitlements": [ "office365", "sharepoint_team_A", "officient_hr" ],
   "email": "jan.janssen@chemco.com"
},
{
   "persona_name": "delegated-supervisor",
   "scope": [ "team-B" ],
   "entitlements": [ "office365", "officient_hr" ],
   "email": "jan.janssen@chemco.com"
}
]

A healthcare professional may be working in a private practice (identified with e.g. a custom attribute hcp_registration_number) as well as in a hospital. The authorization policy may decide to grant different types of access to different medical records, depending on the selected persona.

JSON

"personas": [
{
   "persona_name": "health_care_professional",
   "scope": [ "My Private Practice" ],
   "hcp_registration_number": "BE 4-15136-31-522",
   "email": "jan.janssen@gmail.com"
},
{
   "persona_name": "health_care_professional",
   "scope": [ "UZLeuven" ],
   "email": "jan.janssen@uzleuven.be"
}
]

People at an accountancy office may be working for different customers. In order not to confuse the administration between their customers, they may decide to explicitly ask their staff to choose the company they are working for at that moment using persona selection.

JSON

"personas": [
{
   "persona_name": "accountant_at_customer",
   "scope": [ "chemco" ]
},
{
   "persona_name": "accountant_at_customer",
   "scope": [ "ibm" ]
}
]

Use case 3. Consumers and Professionals

A person may be a retail customer as well as being a staff member of the company. When acting as an employee, identified with the custom attribute employee_number, the person can use all internal applications. When acting as a consumer, the person can order products and gets a totally different user experience.

JSON

"personas": [
{
   "persona_name": "consumer",
   "email": "jan.janssen@gmail.com"
},
{
   "persona_name": "employee",
   "scope": [ "chemco" ],
   "employee_number": "P036652",
   "email": "jan.janssen@chemco.com"
} 
]

Or a person may be a retail customer as well as representing a company for the B2B business.

JSON

"personas": [
{
   "persona_name": "consumer",
   "email": "an.janssen@gmail.com"
},
{
   "persona_name": "customer_employee",
   "scope": [ "chemco" ],
   "email": "an.janssen@chemco.com"
} 
]

Another example is a healthcare professional may be a patient herself at times, identified e.g. a custom attribute patient_number = National Register Number.

JSON

"personas": [
{
   "persona_name": "heart_surgeon",
   "scope": [ "UZLeuven" ],
   "email": "an.janssen@uzleuven.be"
},
{
   "persona_name": "patient",
   "patient_number": "73.07.11-149.62",
   "email": "an.janssen@gmail.com"
}
]

Use case 4. Households and Associations

A person may be a retail customer as well as being the pater familias paying the bills of a family subscription. Using the latter persona, the user can administer subscriptions and share the subscriptions with his family members. The subscriptions being managed are listed in the custom attribute subscriptions and the family is identified with scope = e.g. family name in a village. This truly implements Delegated Administration for households.

JSON

"personas": [
{
   "persona_name": "consumer",
   "email": "jan.janssen@gmail.com",
   "entitlements": [ "tv-channels", "streamz", "my-personal-vault"]
},
{
   "persona_name": "family-administrator",
   "scope": [ "janssen_wilrijk" ],
   "email": "jan.janssen@gmail.com",
   "entitlements": [ "tv-channels", "streamz"],
   "status": { "current": "pending", "set_at": "2022-07-22T13:29:01Z" }
} 
]

A person may be a retail customer as well as representing a company and their employees. Using the latter persona, the user can administer digital services on behalf of the company (identified e.g. with its registered company name in scope and the custom attribute tva containing the verified company registration number) and share access with his team members. This truly implements Delegated Administration for companies.

JSON

"personas": [
{
   "persona_name": "customer",
   "scope": [ "MyBakery SA" ],
   "email": "jan.janssen@gmail.com"
},
{
   "persona_name": "team-administrator",
   "scope": [ "MyBakery SA" ],
   "tva": [ "BE 0812.087.341" ]
} 
]

A person may be a member of an association as well as representing the association. Using the latter persona, the user can administer access for the other members. This truly implements Delegated Administration for associations, communities and even friendships and temporary groups.

JSON

"personas": [
{
   "persona_name": "alumni",
   "scope": [ "alumni-association-abc" ]
},
{
   "persona_name": "alumni-administrator",
   "scope": [ "alumni-association-abc" ],
   "email": "jan.janssen@gmail.com"
} 
]

Create a custom Persona

Creating a persona is a step before associating it with a user profile.

To create a persona from TrustBuilder admin portal:

Go to User Management > Personas
Click on + Add Persona
Enter a name (lowercase and numbers only) and a description (optional) for the new persona.
The name cannot be edited after the persona has been created. The name will be visible to users to which this persona is linked.
Define whether this persona will be the default persona.
The default persona will be automatically selected for users if they don’t choose another one.
Link attributes to this persona. See Manage Attributes to know more
You can search for attributes or select them from the list.
Drag and drop the attributes to re-order the list.
Click on Save.

The Persona is successfully created. You can now associate it to a User Profile.

Edit a custom Persona

To edit a Persona from the admin portal:

Go to User Management > Personas
Click on the edit button for the relevant persona.
Edit the parameters. The persona name cannot be edited.
Click on Save.

The Persona is successfully updated.

Any change to a persona is immediately applied to the user profiles associated with it.

Delete a custom Persona

To delete a Persona:

Go to User Management > Personas
Click on Delete for the relevant Persona.
In the pop-up, click on Yes to confirm the action.

The Persona is successfully deleted.

Users will still be able to log in with their user profile, but they will no longer be able to select the persona. This action cannot be undone.