Once a user has been identified and authenticated, this does not automatically grant the user unlimited access to resources or applications. Users can be authorized based on the role they have within an organization or on their attributes (for instance, location, device,…).
As the term Role-based Access Control suggests, users are authorized based on their role within an organization. A clerk will not be authorized to access all resources within an organization while, normally, a director will have access to more applications or sensitive data. RBAC is fine for organizations that have a rather static set of roles and applications, but has its limitations: roles can quickly become obsolete and change because of market conditions (e.g. mergers, acquisitions).
When too many roles are created to accommodate all use cases, organizations can end up with a hard-to-manage spaghetti of roles and exceptions to those roles. Moreover, RBAC modeling does not easily fit partner/customer use cases.
Again, the term explains the meaning: ABAC uses attributes rather than a specific role or function within an organization. The range of possible attributes is endless and can be based on subject (ID, job role, group membership,…), resource (file, application, server,…), action (read, write, edit,…) or context (time, location, device,…). Using TrustBuilder, system administrators can create their own set of attributes, fit for the any authorization purpose. For instance: retailers can use products as attributes, airlines can use flight numbers as an attribute.
TrustBuilder’s Authorization Server is based on the ABAC-model. It allows authorization rules by using a combination of regular expressions that can take any attribute into account. The rules engine is mainly used to provide access decisions to the TrustBuilder Gateway to monitor and control the access to web and API-based applications. For making the final access control decision, any information about the user, the session and the accessed resources are accessible to the Authorization Server. TrustBuilder allows organizations to create attributes on any item (like the amount of a transfer, or the number of contracts), thus allowing an even tighter fit for access management to an organization, and giving a better customer experience.
Any attributes that are used by the authorization engine can be gathered from the user identity data received for the IdP. Extra contextual data (IP address, device information, …) can be further enriched by feeding the data into TrustBuilder’s Workflow Engine. The Workflow Engine itself can also perform external call-outs to gather ‘derived attributes’ from external PIPs, for instance an employee/customer database but also more complex and dynamic systems such as a risk/transaction scoring engine. As an example, TrustBuilder can determine the amount of money that is wired (= a derived attribute) and activate a step-up policy based on this information.
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.
