Skip to main content

Overview

The following picture shows an overview of the main components and features of mID Provider(IAM).

Architecture

prerequisite​

There are some key terms you should be aware of before attempting to use mID provider to secure your web applications and REST services.

Users​

Users are entities that can login to your systems. They can have attributes associated with themselves like email, username, address, phone number, and birth date. They can be grouped and can have specific roles assigned to them.

Authentication​

The process of identifying and validating a user.

Authorization​

The process of granting access to a user.

Credentials​

Credentials are chunks of data that mID Provider(IAM) uses to verify the identity of a user. Some examples are passwords, OTPs, digital certificates, or even fingerprints.

Roles​

Roles define a user. User, admin, operator, manager or employee are all typical roles that can exist in an organization. Privileged roles (admin role) can be assigned to a user who wanted to manage a group of users because dealing with individual users can be hard to manage.

User role mapping​

A role-to-user mapping is defined. A user could have zero or more roles associated with them. This role mapping data can be covered in assertions and tokens, allowing applications to control access to the various resources they manage.

Composite roles​

A role that can be associated with other roles. For example, a super-admin composite role contains admin and reviewer roles. If a user is mapped to super-admin role then they also get admin and reviewer roles.

Groups​

Users are managed by groups. A group can also have several roles assigned to it. Individual users in the group gets role mappings and attributes that are defined to that group.

Realms​

In mID provider, a realm is a workspace that manages a set of users, their credentials, roles, and groups. A user in mID provider can only belong to one realm, and when they log in, they will be logged into that particular realm.

Clients​

Clients are entities that can request a user's authentication through the mID Provider. Clients are applications and services that want to utilize the mID Provider to protect themselves and provide a single sign-on (SSO) solution. Clients can also request a access token or identity information so that they can use mID Provider's secured network service.

Client adapters​

Client adapters are libraries which are used to provide a strong integration with the underlying platform and framework.

Consent is used when an admin wants a user to grant permission to a client before that client can engage in an authentication logic. After a user provides their credentials, mID provider will pop up a screen identifying the client requesting a login and what identity information is requested of the user. User can determine whether or not to approve the request.

Client scopes​

When a client is created, you must specify the protocol mappers and role scopes for that client. It is better to store the client scope and make the creation of new clients, requesting claims, or roles much easier through sharing the common settings.

Client role​

Clients can specify roles that are unique to them. This is essentially a role namespace committed to the client.

Identity token​

A token that holds identity information of a user such as username, email, and other profile information.

Access token​

The access token is digitally signed by the realm and contains access information (such as user role mappings) that the application could use to identify which resources the user is permitted to access.

Assertion​

Information about a certain user. This generally refers to an XML blob that is included in a SAML authentication response and contains identity metadata about a user who has been authenticated.

Service account​

Each client comes with a built-in service account that allows it to request an access token.

Direct grant​

A REST invocation can be used by a client to request an access token on behalf of a user.

Protocol mappers​

You can customize which claims and assertions needs to be stored in the OIDC token or SAML assertion for each client. You do this to a client by creating and configuring your protocol mappers.

Session​

A session is created when a user logs in. A session consist of information like when did the user logged in and what applications are participated in SSO during that session. Session information can be viewed by both admins and users.

User federation provider​

mID provider will store and manage users. Most workspaces already have Directory services that store users and credentials information. You can point mID provider to validate credentials from those external stores and pull in identity information.

Identity provider​

An Identity Provider (mID Provider) is a service where it can authenticate a user.

Identity provider federation​

The mID provider can be set to assign authentication to one or more IDP. Social logins via Facebook or Google are good examples of identity provider federation. You can also use the mID provider to assign authentication to any other OpenID Connect 1.0 or SAML identity provider.

Identity provider mappers​

You can map incoming tokens and assertions to user and session attributes, while performing IDP federation. This enables you to send identity information from an external IDP to a client requesting authentication.

Required actions​

Required actions are those that a user must complete during the authentication process. The authentication phase will not be completed until these required actions are completed. For example, an administrator can set up a monthly password reset for users. All of these users would be asked to update their passwords.

Authentication flows​

The first step in securing an application or a web service with a mID provider is to identify and authenticate the user. In a mID provider, authentication flow refers to the series of steps that a user or service must do in order to be authenticated. For example, a login work flow can define what type of credentials are required. A registration work flow can define what type of profile information a user should enter.

Events​

The mID provider offers a comprehensive set of auditing features. Every single login activity can be logged, saved, and examined in the Admin Console. All admin actions can be documented and evaluated as well. There is also a Listener SPI that plugins can use to listen for these events and take action. Listeners with built-in functionality include a simple log file and the option to send an email whenever an event happens.

Themes​

The mID provider offers theme support for web pages and emails. This allows you to customize the style and feel of end-user facing pages so that they can be connected with your applications. Themes represent HTML templates and stylesheets which can be used when required.