Organizations are living organisms. People are promoted, people switch jobs internally, external people come into the organization for specific projects, open collaboration extends the enterprise to customer and partner companies,… Managing identity and access management (IAM), and the access privileges different people have, is not made easier by this evolution. Working with personas rather than roles, and to facilitate delegated administration enables greater customer centricity, while unburdening administrators.
Read on to learn how:
Access management stands or falls by its administration. This is where traditional role-based access control (RBAC) fails. Take permissions and sets of permissions in the form of access-roles and access-groups, as the basis. These are statically pre-assigned. Hence RBAC is fairly static. To evolve with a person’s function in an organization, for example promoting from trainee to employee and from junior employee to team leader, RBAC requires the assignment of new permissions, access-roles, and access-groups. When a person mutates from one business unit to another, RBAC not only requires assignment of new permissions, but also would require taking away prior permissions. The latter is often not executed because of fear that the person can no longer perform essential tasks.
In principle, pre-assigning permissions to a person should be subject to a policy. This policy, however, is often only implicit. Such implicit policy may be “this person should have the same rights as her most immediate colleague”. The execution of an implicit policy is at the discretion of sysadmin staff that assign the permissions. And while it is a challenge to do this manual administration within a company, it becomes a nightmare when it needs to scale to employees of business partners and customer companies.
Given these limitations, why are organizations still relying on RABC? For a start, access to applications is often controlled through Active Directory (AD). AD uses the concept of access-groups assigned to AD accounts. Secondly, once a person gains access to an application, the application itself applies fine-grained access to determine what the person may do within the application. This complicates access control since permissions not only need to be administered at the AD level, but also at the application level. Furthermore, this model is clearly application-centric and does not foster customer centricity.
Rather than taking permissions as the basis, a person’s characteristics relevant to the organization are used as the basis, so-called attributes hence the name attribute-based access control, ABAC for short. To decide whether a person should be authorized to do something, a policy is evaluated using the person’s attributes (possibly in addition to contextual attributes).
Whereas RBAC has an implicit policy that is only executed during the assignment of permissions, roles, and groups, ABAC has an explicit policy that is executed every time a person requires authorization to execute something.
Compared to permissions, which are in essence application characteristics, attributes characterize a person and a person’s function relative to the organization. As such, it makes sense to leave the administration of attributes to the people themselves. This is, in fact, what Customer Identity and Access Management (CIAM) introduced: self-service for profile registration.
Can a policy rely on self-declared attributes, you may ask? Well, CIAM does that to a limited extent: “did the person accept the terms & conditions?,” “did the person confirm her email address?,” or “did the person declare to live in Belgium?”
But relying on “does this person have a valid employment contract?” or “does this person belong to this business unit” or “does this person have a valid and paid subscription?” would be difficult if the attributes are simply self-declared. It should clearly not be left to employees alone to set these attributes for themselves.
In order to properly delegate attribute administration to the people themselves, some level of assurance must be obtained. This can be done by validating self-declared attributes against an authoritative source, such as a national registry. For example, somebody’s age and official domicile can be checked against a national citizen registry. Also, whether somebody is a certified healthcare professional can be checked against a national registry. The authoritative source can also be a CRM system, to check whether somebody is a registered customer with a loyalty card. To allow organizations to fetch and process internal and external data – for instance from authoritative sources – and use that data to enrich the intelligence used in the organizations’ policies, TrustBuilder introduced the Policy Information Broker, a unique feature in our IAM architecture.
Confirming attributes can also be achieved using an approval flow, whereby a mandated person may confirm self-declared attributes. For example, “I confirm that this person belongs to my team.”
If mandated people, however, need to confirm attributes one by one, they will quickly get bored and careless. That’s why TrustBuilder introduced the concept of ‘persona’.
A TrustBuilder persona is designed to group attributes to actually reflect someone’s function relative to an organization. For example: in the context of a media company a person may simply be a visitor and evolve to a paying subscriber. Using the persona ‘visitor,’ the person will be limited to browsing and placing an order. When using the persona ‘subscriber’ the person can enjoy one-click purchases and consume premium digital content. In a corporate context, using an ‘employee’ persona, a person can enter holiday requests, while using the ‘HR-manager’ persona, the person can approve someone’s self-declared attributes and can adapt their salary.
What did we learn so far? By introducing the concept ‘persona’, TrustBuilder enables ABAC policies to rely on attributes that are self-declared and independently confirmed. This means that TrustBuilder enables delegated administration for access control. And by delegating persona administration to the people themselves, TrustBuilder fosters accuracy, appropriateness, and freshness of attributes.
Additionally, the ‘persona’ concept allows lifecycle management to be done at the persona level. This means that when a person leaves a function, the entire account need not be deactivated. Only the associated persona needs to be deactivated. It also allows a person to already start using his account, even before the persona ‘employee’ becomes active.
Delegating persona administration allows access to be controlled on a great scale: you no longer need a central sysadmin group to assign permissions, people roles, and permission groups. Best of all, however, delegated persona administration puts people at the center: they manage their own attributes and personas. And putting people at the center is what customer centricity is all about.
Interested in exploring how you can become more customer centric?
Subscribe
Register for our newsletter and stay updated on IAM and TrustBuilder.
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.
