Every Success Back Office's Base - IAM Service

The back office is a way for users to interact with microservices, and it could be done so through performing CRUD actions. IAM service is a very important core service because it ensures that the company’s data and information across all microservices are secured from unauthorized access.

Start Browsing 

Product Core Idea

SSO(Single Sign-On) for users to log into the system with their own accounts provided by their companies.
Auto-sync users with third-party admin directory (AD) to the back office.
The concept of “Fixed user groups” and “Customizable user group” to prevent the system from losing managers when users are automatically deleted.

User Research

Managing roles isn’t a daily task. We planned to build an IAM service for the new back office which is planned to replace the old system. At that time there were about 2300 users using 55 roles in that old system.

Before designing the role service, we interviewed colleagues who had experience of using the old system and other back offices’ role services.

Interview outline:

The interviewee’s basic information: position, past experience with back offices.
The features interviewee use and the procedure of managing roles.
Pain points which the interviewee faced.
Problems from the old system’s role service.

According to the interview, these were the points of improvement that could be done to the old system:

Auto-sync users with third-party admin directory (AD): managing new and former employees’ accounts is an easy but repetitive task.
Unassign users from a particular role in batch: it’s annoying to keep switching the menu between role and user management to unassign roles from users.
Able to deactivate roles: deactivating roles is a tedious job to do when it comes to a large number. The solution we came up with allows users to disable users based on various aspects such as users, mass users, roles, permissions, etc. This gives the admins greater flexibility in how they want to manage the users.

Design logic we got from the interviews:

Allow users to create roles with the same permission but with different names: users usually clone roles to create a new role that is highly similar to the existing ones.
Role hierarchy: companies tend to create roles within the roles to maintain the hierarchy within the organization. The IAM service easily allows the admins to create a hierarchy within and assign the roles.
Avoid loss of authorization: we made sure that users can only delete roles when there are no users belonging to that role. To delete the role, users need to first deactivate the soon-to-be-deleted role and migrate all accounts out from it.

Workshop

While designing, we found some logic-related problems. We invited the PO (product owner) and design team to brainstorm solutions based on different journeys.

These are the solutions to integrate most of them into:

SSO (Single Sign-On): by syncing user data from 3rd party AD, users can log into the system with their own accounts provided by their companies.
Superuser: flow related to the first set up of the system, superuser’s login process, password reset process, etc.
OTP: the process of email and phone OTP for password reset or identity verification.
Build-in batch selections instead of file upload: users can be batch-selected by pasting their email addresses into the system. The system can detect existing and non-existing emails, and will only let users login if their emails are found in the system.
The concept of “Fixed user groups” and “Customizable user group”: system-related permissions (user, role, and permission) are grouped into system roles to prevent the system from losing managers when users are automatically deleted after leaving the company or dispatched from the roles.
Notification system: a notification system to update the users if their roles have changed and if they are given more or deprived of certain permissions.

Final Outputs

Designed the wireframe and flow document for the team and users to review. Once the wireframe passed, I designed the mockups.

Here I present the main flows: SSO Connection, Superuser login, Role Management, Assign Users to Role, and User Login.

SSO Connection

This is the SSO connection flow. Our role service is not a data owner. The data owner is a 3rd party active directory. (Microsoft or Google would be examples of 3rd parties.) Here is the list of benefits of syncing data from 3rd party:

Users can log in to the back office with their company emails.
Users don’t need to manage accounts in the back office as the data is in sync with the 3rd party. If the account is removed from 3rd party, the account will also be removed from the back office.
Subsidiary companies can set up their connections to their parent companies’ back offices.
The back office provides a way to connect with multiple 3rd party connections at the same time, so people from different companies can log in if they are authorized by the system admins.

There are 2 ways of accounts synchronization for different scenarios: auto sync and semi-auto sync. The former syncs all the accounts to the back office and the latter allows users to select which accounts to sync with the back office.
‍

Superuser Login

The usage of superusers is for the system's first setup. Instead of logging in to the system by SSO, Superusers log in to the system via system-created accounts and passwords. Superusers will be asked to set up and verify phone numbers upon the initial login. Superusers can also reset the default account and password afterward.

Role Management

Role management is one of the functions of role service. Users can check roles in a list or a hierarchy view that shows the parent of each role. To prevent the system from losing the manager, we separate roles into two types: team role and system role. Team roles include customized roles and a default role, which is the admin. System roles include 4 default role service-related roles, which manage users, roles, and policies (role's permission group) of the back office. Users can customize team roles by copying permissions from existing roles or selecting policies manually.

‍

Assign Users to Role

Users can choose to assign users manually or batch assign users to specific roles. Apart from batch assigning, pasting the email address list in the build-in batch selections also allows the system to detect non-existent accounts.

‍

‍

User Login

Select orientation first, then log in to the back office with the company email. Here we take Microsoft as an example.

‍