Skip to content

Identity & Intelligence

i2i Identity & Access

Control who can sign in, what they can do and who touched production

At a glance

  • One-time-code sign-in hand-off between i2i consoles
  • Roles and permissions grouped by application and module
  • Time-boxed and emergency access with mandatory review
  • Passwordless production launches, every one audited

Overview

i2i Identity & Access is the central identity service for i2iCore. It holds organisations, users, roles and permissions, issues the signed tokens that the other services verify, and keeps an audit trail of sign-ins and administrative actions. Staff, partner staff and machine accounts are all managed in one console.

Alongside it, a separate production access service lets support staff launch a production application without ever seeing its password and open a browser-based SSH terminal to a server. Grants have a time window, administrators can watch and end live sessions, and every launch is audited, whether it was allowed or denied.

What is identity and access management?

Identity and access management, often shortened to IAM, is the set of controls that decide who a person or system is, and what they are allowed to do. It covers sign-in, second factors, roles and permissions, and the records that show who did what and when.

Single sign-on lets a person authenticate once and move between applications without signing in again. Multi-factor authentication asks for a second proof, such as a one-time code, in addition to the password. Privileged access management adds tighter control over high-risk access, such as administrator rights or a production server: access is granted for a limited time, launched without exposing the credential, and audited.

In a telecom operator these controls matter because staff, partners and automated systems all reach billing, subscriber and network data. i2i Identity & Access applies them to the i2iCore platform: one place to define roles, review who holds them, limit what partners can grant their own staff and see the audit trail.

Capabilities

What i2i Identity & Access does

Sign-in and sessions

  • Sign-in by organisation, with usernames unique within each
  • One-time-code hand-off between registered i2i consoles
  • Password expiry, history and minimum length policy
  • Idle timeout, absolute session limit and concurrent-session limit
  • Per-user allow-list of source IP ranges

Multi-factor codes

  • Second factor is a six-digit code by SMS or email
  • Set per user, with organisation defaults for staff and partners
  • Wrong guesses lock the code and requests are rate limited
  • Forgotten password and username flows that do not reveal accounts

Roles and permissions

  • Permissions catalogued by application, module and action
  • Built-in roles plus custom roles per organisation
  • Organisation entitlements cap what any role can grant
  • Risk tier on every permission
  • Partner staff capped by an access profile

Governance

  • Time-bound access requests with approval
  • Break-glass emergency access reviewed by another person
  • Access certification campaigns to keep or revoke
  • Segregation-of-duties rules and a policy simulator
  • Job profiles that bundle roles for a position

Audit and reports

  • Audit log of user, module, action, status and IP address
  • Search the log and download it as CSV
  • Privileged-activity view and risk observations
  • Five compliance reports, including user access and emergency access

Production access

  • Launch a production app with a one-time handle, not a password
  • Browser SSH terminal to registered servers
  • Grants with a time window that can be revoked
  • Administrators watch and end live sessions

Use cases

Where i2i Identity & Access is used

  • Give a support engineer time-boxed elevated access

    An engineer needs a higher-risk permission for one maintenance window. They raise an access request, an approver grants it for a set period, and it expires by itself. If it is an emergency, break-glass access is available and another person must review it afterwards.

  • Limit what a partner's staff can do

    A distributor creates accounts for its own staff. Each partner account is capped by an access profile set by the operator, so the distributor can pass on only permissions inside that ceiling and cannot pass on more than the operator allows.

  • Review access every quarter

    A security officer starts an access certification campaign. Reviewers keep or revoke each grant, segregation-of-duties rules flag conflicting roles, and the compliance reports list user access and emergency access for the auditors.

  • Reach a customer's production server without a password

    A support engineer with a valid grant opens the browser terminal to a server. The secret is stored encrypted and is never shown to them. An administrator can watch the live session and end it, and the launch is recorded in the audit log.

FAQ

i2i Identity & Access: frequently asked questions

How does single sign-on work?

It is an i2i hand-off. A signed-in user opens another registered i2i console, the identity service issues a short-lived one-time code, and the console redeems it for a session that shares the same session identity, so signing out ends both. The console must be registered for the organisation. Production access has its own sign-in and is not part of this hand-off.

Can it federate with an external identity provider or directory?

Not today. There is no connector to external identity providers or corporate directories, and single sign-on is limited to the i2i consoles. If your organisation needs federation, tell us before you plan around it.

What second factors are supported?

A one-time code sent by SMS to the user's phone or by email. It is configurable per user and as an organisation default for staff and partners. Other second factors are not offered. SMS and email delivery depend on the sender you connect.

Is the content of production sessions recorded?

No. Administrators can watch a live session and end it, and each launch is written to the audit log with its outcome, but keystrokes and screens are not recorded for playback.

Does the policy engine block access?

Decisions are recorded and shown in the Access Decisions view. Enforcement is an organisation setting, so you choose when to switch it on. Risk observations are for review and never block a user on their own.

Can we export the audit trail?

Yes. The identity audit log can be searched and downloaded as CSV, and five compliance reports download the same way. Production access has its own audit log with CSV download and a configurable retention period.