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:
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).
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:
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.
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.
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.
To make things a bit more practical, let’s look at some use cases for personas.
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 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 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 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:
Engage in a chat with our product people to discuss IAM trends and challenges, and our solutions.
Take our Maturity Assessment to find out how you can accelerate your digital transformation.
Experience the power of TrustBuilder.io Suite through a demo, personalized to your challenges.
Visit our offices, send us a mail, call us, or simply fill out a contact form.