Identification is where it all starts in Identity and Access Management (IAM) systems. Before you grant access to a resource or an application, you will need to establish the user identity.
It is easy to mistake identification for authentication, especially as Identity Providers (IdPs) often use the same mechanisms to authenticate their users. And then there is also Authorization. So let’s start by showing the difference.
Identification is meant to uniquely identify a user. In some cases, the user is a human being, in other cases it can be a computing device (another computer, a firewall, a printer, …) or an application. The key challenge in IAM is to uniquely identify the user or device, as each IdP/SP usually has its own way to define uniquely the user identity.
TrustBuilder comes with built-in support for all authentication types, factors (knowledge factors, possession factors, inherence factors) and authentication mechanisms such as Single Sign-on, Federated authentication, Multi-Factor authentication and adaptive authentication. With TrustBuilder Mobile Authenticator, we have our own product for mobile MFA.
Authorization deals with validating whether an identified and authenticated user is allowed access to the application or service he’s requesting. In Role-based access control (RBAC), this decision will be taken based on a role of an individual. Usually, this is not enough, and we use attributes to make the validation. This is called Attribute-based access control (ABAC). Examples of an attribute: age, IP-source, geolocation, device identity
Although each human is unique, when using different systems or applications, a user may authenticate himself with a different user identity. Not every application requires the same identifier. Some applications are only interested in username/password, other in a unique first name/last name combination. Identity mapping is the process of mapping one user identity to another, related user identity. Identity mapping is key in enabling Single Sign-on (SSO).
An IAM system can call upon different sources to identify users. Indeed, it is quite classical that a single person has multiple different identities, depending on usage. The ID information required can be stored in the TrustBuilder Repository, or any other internal or external source. Thanks to our virtual directory technology, organizations can keep using their own repository and don’t need to synchronize any existing identity data/attributes with the TrustBuilder Repository.
TrustBuilder Repository contains all information that is required to run TrustBuilder Identity Hub. Besides holding end-user information, it also stores information related to both internal and external protected applications and APIs (Service Providers) and information about registered internal and external authentication services (Identity Providers). Most importantly, it stores the links between the different identities, to achieve SSO no matter what IdP he is using and no matter what SP he is accessing.
Most organizations manage their own repository with identities, either stored locally, or in the cloud. Just think of Active Directory or LDAP (Lightweight Directory Access Protocol), in use in many organizations for storing records of their own employees, or even customer databases, which are used by core business applications. Some level of replication of these stores is usual (i.e. authoritative employee data originates from a particular HR database; whereas authoritative customer data may originate from a CRO database). TrustBuilder allows you to connect to any of these identity stores, and does not mandate to replicate data any further….
A third way of establishing identities is through federated authentication. With Federated Identity Management (FIM) a user or a device is identified by using the identity from a different domain, for instance the domain of a partner organization. Think for example of the employees of a broker who can log in to the applications of an insurance company using the identification from their employer.
The drive towards digital identities has prompted governments and industry federations to develop identification sources that help customers identify themselves towards institutions or banks. Well-known examples of these are eHerkenning, Itsme, IDIN, DigiD,… These identities also allow of passwordless authentication.
Ever more organizations allow users to identify through their social identity, for instance their credentials from social media such as Facebook, Google or LinkedIn. This allows users to choose what identity to use when accessing a web resource. Social identities are usually used for low-sensitivity scenarios (i.e. the first few steps in customer onboarding). Whenever sensitive information is accessed, step-up authentication is required.
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.