Everything you always wanted to know about personas* (*but were afraid to ask)
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’. In this long read, TrustBuilder CTO Carlo Schüpp explains the ins and outs of personas.
Read on to learn:
- What is a persona
- Why you should use personas
- How personas relate to roles
- How personas trigger policies
- What use cases warrant using personas
What is a persona?
A persona in TrustBuilder reflects the type of activities a user 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 as well as being mandated for administrative tasks on behalf of her company. With TrustBuilder, the person only needs one profile. She receives two ‘personas’ in her user profile corresponding to the two roles she can play.
Another example is a person who is a healthcare 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 post-university courses. Or a staff member; she can equally be a retail customer of the same company. Or a person may be working part-time in one team and part-time too for another company. Or a person may be a software developer who, in emergencies, needs to help 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 should you use 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.
Additionally, TrustBuilder offers a full approval mechanism for self-declared attributes in order to delegate administration to the end-users.
With its persona-driven authorization policies, TrustBuilder:
- Enables Delegated Security Administration whereby security administration is moved to people close to the end-user. This contrasts with 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 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 ‘employee’ persona has been activated.
- Enables effortless implementation of Segregation of Duties, by having different personas corresponding to different duties – see below for some examples.
- Enables straightforward 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 – see below for some examples.
- 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 gaining access, which would typically be the ‘HR manager’ persona.
TrustBuilder personas bring the management of access control to a whole new level: it easily combines the benefits of Role-based access control (RBAC) and Attribute-based access control (ABAC) while simplifying administration. In fact, delegating persona administration using TrustBuilder allows access to be controlled at great scale: you no longer need a central sysadmin group 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 therefore their own access.
How do personas relate to roles?
Many enterprise applications today are controlling access using permissions. Permissions may be grouped into ‘roles’ or ‘groups’. For example, SAP has roles and composite roles. Salesforce also uses roles to specify the levels of user access. 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 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 ‘member_of’ 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 ‘member_of’ attribute to enable it to feed RBAC systems, as and when needed. TrustBuilder implements a Policy-Based Access Control (PABC) model, which does not need roles. A customer, however, can take the ‘member_of’ attribute into account when designing rules for an Authorization Policy.
Below, we discuss 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.
How personas trigger policies
Personas are not only used in Authentication and Authorization Policies. They are also used to steer the provisioning to applications that perform their own access control using pre-assigned access rights, in the form of accounts, permissions, privileges, and roles. Such access rights are provisioned using TrustBuilder’s policy-driven model.
Whenever a persona is added or removed, or whenever a critical attribute is changed, the policy is executed. In fact, the policy is executed as soon as the status of a persona becomes ‘accepted’ or ‘deactivated’ and the corresponding provisioning (or deprovisioning) is executed. To avoid double provisioning and to avoid taking away rightful access rights, provisioning and deprovisioning is done by first calculating the net effect of the prior situation and the new situation.
Some use cases for personas
Use case 1: Privileged Access
If an IT person 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 read her email using this persona, so as to be shielded from phishing attacks. Some other examples:- a person who performs office work and, from time to time, helps in the customer services team.
- a developer who may help in operations from time to time, in a case of privilege elevation.
- a HR manager who can do administration in a 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.
Use case 2: Job Cumulation
A person may be working part-time for one team and the rest of the time for another team. To implement Segregation of Duties for certain activities (or simply to avoid that documents are misplaced in the wrong team folder at SharePoint), the person may be given two 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. Other examples of job cumulation:- a person who is the supervisor of a team and who may also be delegated to the supervisor role of a second team during the absence of their supervisor
- a healthcare professional may be working in a private practice 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
- 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.
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. Other examples for customers and professionals:- a person may be a retail customer as well as representing a company for the B2B business
- a healthcare professional may be a patient herself at times.
Use case 4: Households and Organizations
A person may be a retail customer as well as being the paterfamilias paying the bills of a family subscription. Using the latter persona, the user can administer subscriptions and share the subscriptions with his/her family members. This truly implements Delegated Administration for households. Other examples for households and organizations:- 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 and share access with his team members. This truly implements Delegated Administration for companies.
- 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.
