Definition
IAM (Identity and Access Management) is ICMP platform's identity authentication, authorization, and access control system, which works with RBAC role permissions, OAuth2, API Key, 2FA to ensure secure access to the platform Portal, RESTful API, and Partner Portal.
Core Functions
IAM includes: Identity Authentication—username and password, OAuth2, SSO, API Key, certificates; Authorization—RBAC role-based access control, with fine-grained permissions down to APIs, functions, and data scope; Multi-factor Authentication—2FA two-factor authentication to enhance security; Session Management—Token validity, refresh, and revocation; Auditing—login and permission change records in Audit Trail.
Multi-Tenancy and Roles
ICMP supports multi-tenancy: different roles such as customers, Reseller channels, and platform administrators, with permission isolation. Customers can create sub-accounts and assign roles (such as read-only, operations, finance); Partner Portal provides channels with a separate entry and permissions. API calls require authentication via API Key or OAuth2 Token, with API Gateway handling validation and rate limiting.
Practice in ICMP
SimtoLink ICMP's IAM supports multi-factor authentication, OAuth2, API Key; deeply integrated with RBAC; supports enterprise integrations such as SSO and LDAP; Audit Trail records all authentication and authorization events; compliant with PCI DSS, GDPR, and other regulatory requirements.
Subjects, Roles, and Resource Boundaries
Identity and access management answers who this subject is, and what that subject may do to which resources this time. A subject can be a portal user, a channel account, a service program, or a short-lived token. Resources are one tenant’s SIMs, orders, invoices, diagnostic records, and configuration. Authentication only establishes that the subject is genuine. Authorization decides whether the action is allowed. High-risk actions in connectivity management include bulk suspension, export of lists that contain device identities, tariff changes, and starting settlement. Being able to sign in should not open those actions automatically.
Use it when there is a stable directory of subjects first, and permissions are written as roles or scopes that can be reviewed, not when an administrator password is handed to every integrated system. A person account fits interactive work and should be able to require a second factor. A system call fits its own credential, scoped only to the interfaces it truly needs to read or write. The tenant boundary must apply before the role: a channel account with a “SIM management” role may see only the SIMs assigned to it. Sensitive confirmation outside sign-in can require a further one-time password, so a long-lived session is not used directly to change settlement details. The SMS channel only delivers a code to a phone. Whether the account may act is still decided by the identity system. Do not collapse the two into one send record on the SMS gateway.
What an Over-Broad Grant Does across Borders
The most common error is one “operations administrator” role that covers suspension, export, price changes, and payment. Cross-border teams are often split by region. A regional colleague should handle only this region’s SIMs and tickets. If the role is cut by function and not by data scope, one person can suspend devices in another region, or export usage that is not theirs. Another error is to give an integration script the key of a personal account. After the person leaves, the key still works, and the audit trail shows that person calling the API in bulk in the middle of the night.
Service accounts are also easy to leave without expiry, holding every menu on the portal. A script that only needs to query usage can then change roaming policy. If a permission change does not keep the before-and-after difference, nobody can later say who widened a channel’s visible scope. When configuring identity and access management, authorize people, services, tenants, and actions separately. Approve high-risk actions on their own, and withdraw credentials that are no longer used.
Review permissions subject by subject, not only by whether a role name still exists. Person accounts that have not signed in for a long time, channel accounts whose holders have changed jobs, and service credentials that remain valid after an integration was retired all need a clear disable date. On disable, also revoke sessions and tokens that have not yet expired. Otherwise the role is gone, but a credential already issued can still suspend SIMs or export lists. The review record itself stores who checked which subjects, and when. It does not store passwords or verification codes.
Separate duties. A person who can change tariffs should not confirm settlement alone. A person who can export a full identity list should not also hold bulk suspension. Emergency handling can use a separate break-glass account, disabled by default, and when enabled it should record the reason, the approver, and an automatic withdrawal time. If that account stays usable, it becomes another unconstrained administrator. On withdrawal, check which writes it actually performed during the window. Closing it later is not the whole record.
Issue service credentials per integrated system, one credential each, scoped only to the actions that system really calls. A shared credential cannot be stopped for one system after a leak, and the log cannot tell whether the ordering system or the reporting system made the call. Rotation needs an overlap: prove the new credential works, then revoke the old one, so every integration does not fail at the moment of rotation. After the overlap, calls with the old credential should be rejected and recorded.
The tenant boundary also covers export and subscription. A user interface that hides other customers’ SIMs does not mean the API and event push do the same. When a new query or push is added, try an identity that does not belong to that tenant, confirm it is rejected, and only then put it into production. The acceptance test for identity and access management is that an out-of-scope request fails, not that an administrator can open every menu.