Overview

TF Platform provides Identity as a Service (IDaaS), handling both authentication (confirming user identity) and authorization (managing access to resources) for your applications.

When to Consider the IDaas?

1. You Want to Secure User Authentication Enable multiple secure login options for users, including traditional usernames and passwords, passwordless methods like SMS, email, or passkeys, and Single Sign-On (SSO).

2. You Want to Implement Single Sign-On (SSO) Allow users to sign in once and access all applications without the need to remember separate credentials.

3. You Want to Enforce Multifactor Authentication (MFA) Enforce additional layers of authentication using methods such as passkeys, SMS, email, or biometric authentication to enhance security.

4. You Want Centralized Identity Management Manage all user identities from a single dashboard, streamlining administration and reducing complexity.

5. You Want to Secure Your APIs Protect your APIs with the OAuth 2.0 framework, ensuring that only authorized users can access your services.

6. You Want to Support Hybrid Environments Seamlessly manage identities across on-premises, cloud, and hybrid applications for a consistent user experience.

7. You Want Cross-Platform Security Ensure secure interactions between your web and mobile applications and APIs across various platforms.

8. You Want to Manage User Access Customize authorization policies based on user roles or relationships to control access effectively and ensure appropriate permissions.

9. You Want Compliance and Regulatory Support Automatically meet compliance requirements with built-in features for:

   • NIS2 (Network and Information Systems Directive)

   • ISO/IEC 27001 (Information Security Management)

   • SOC 2 (Service Organization Control 2)

   • GDPR (General Data Protection Regulation)

   • HIPAA (Health Insurance Portability and Accountability Act)

Digital resources are assets or data managed by an Application Developer and linked to Digital Identities. These resources are protected within the OAuth 2.0 framework through a Resource Server, which grants access only to authorized users with valid Access Tokens.

Examples of Digital Resources:

• Personal Data: Sensitive user information such as profiles, email addresses, phone numbers, or personal identifiers.

• Health Data: Protected health information (PHI), including diagnostic results, prescriptions, medical histories, and treatment plans.

• Financial Data: Sensitive financial information such as account details, transaction records, or credit scores.

• Company Data: Proprietary business information, including customer records, financial reports, and operational analytics.

• Application Data: Data generated or consumed by applications, such as user settings, transaction logs, or user-generated content.

• AI Applications: Machine learning models, decision-making algorithms, and AI-driven tools.

• Documents and Files: Confidential documents or proprietary files stored in cloud environments or enterprise systems.

• Mobile or Web Applications: Functionalities or data within web and mobile applications restricted to authenticated users.

• Systems and Devices: IoT devices, servers, or industrial control systems that require secure management and authentication.

Identity Providers (IdPs) are authorities responsible for managing and authenticating digital identities

Key Characteristics:

• Authentication: The core responsibility of an IdP is to authenticate users by verifying their authentication methods. This can involve traditional methods (e.g., username and password), two-factor authentication (2FA), or advanced methods like biometrics.

• Authorization: While the primary function is authentication, an IdP may also play a role in determining what resources or permissions a user is allowed to access once authenticated.

• Identity Federation: IdPs use protocols like SAML and OpenID Connect to securely transmit identity data to Relying Parties (RPs), enabling cross-platform authentication with a single identity.

• Single Sign-On (SSO): IdPs can allow users to authenticate once and access multiple services without re-entering credentials.

Types of Identity Providers:

• Internal IdPs: Managed within the same organization as the relying parties, providing full control over authentication and user identities.

  • Example: An organization using Microsoft Entra ID to manage employee authentication for internal services like email, collaboration tools, and HR systems.

• External IdPs: Managed by third-party organizations, authenticating users outside the relying party’s ecosystem.

  • Example: Services like Google, Facebook, or GitHub provide external identity verification for third-party applications, allowing users to log in with their existing credentials from these services.

A Relying Party (RP) is an application, service, or system that relies on an Identity Provider (IdP) to authenticate and verify digital identities. Relying parties can be classified into first-party or third-party categories.

First-Party RP

A first-party RP operates within the same ecosystem as its identity provider, with both managed by the same organization.

Key Characteristics:

• User consent may not always be explicitly required, as both the RP and IdP are controlled by the same organization. Consent is often implied through agreements such as employment contracts or terms of service.

Examples:

• The Future Platform Self-Service application (RP) authenticates users through an organization-managed Identity Provider.

• The HR application (RP) authenticates employees using corporate email accounts or badges via an identity provider managed by the organization (e.g., Microsoft Entra ID, Google Workspace).

• The university grading portal (RP) authenticates students and faculty using university-managed credentials (e.g., Microsoft Entra ID for Education, Google Workspace Education).

Third-Party Relying Party

A third-party RP depends on identity providers managed by a different organization, outside its own ecosystem.

Key Characteristics:

• Explicit user consent is always required, as the RP relies on an external service to authenticate users and access their data (e.g., email, profile).

• Consent is typically obtained through the external identity provider’s consent screen before any data is shared with the RP.

Examples:

• The customer facing application (RP) allows users to log in using credentials from services like GitHub or Facebook and access profile information.

• The e-commerce webshop (RP) lets users log in using Google or Apple ID credentials and retrieve profile data.

The authentication service is responsible for secure and reliable user authentication. And it is designed to support the following core features: 1. User Authentication Methods

The service supports various authentication methods that can be configured according to your application's security policies. These methods include:

• Password-based

• Passkeys

• Authenticator Apps

• Voice-based Authentication

• SMS-based Authentication

• Email-based Authentication

Each authentication method can be enabled or disabled based on the organization's security requirements.

Example: You might configure the system to require SMS-based authentication for all users, while enabling email-based authentication for password recovery.

User Authentication Sessions define the duration for which all activities within the session remain valid. Factors such as switching countries, changing networks, using a new device, altering geographic location, or prolonged inactivity can influence session validity. remains logged in without needing to authenticate again. Session length can be customized to enhance security and user convenience:

• Short-lived sessions (e.g., 1 day): Automatically log out users after a short period, ideal for high-security environments.

• Medium-lived sessions (e.g., 7 days): Retain sessions for a week, reducing the frequency of logins while maintaining security.

• Persistent sessions: Users remain logged in until they explicitly log out, ideal for environments where convenience is prioritized over strict security.

Example: For a banking app, you may choose to set short-lived sessions (1 day) for extra security, while for an internal company portal, 7-day sessions might be more appropriate.

Authentication Assurance Levels: MFA? Biometrics? what you want he? you want the user to login every time? or enable sso?

Step-Up Authentication: Triggerable on assertions per relying party application. Sometime u need mfa sometime not

Security: How often is the username allowed to be triggered? 5 time?

User Authentication Sessions

User Authentication Sessions define the duration of a user's login and how various factors, such as device changes or inactivity, affect session validity. Sessions are maintained using a cookie-based authentication mechanism, ensuring users remain authenticated across web requests.

Duration Policies Logs out users automatically after a set period of inactivity.

• Short-lived Sessions (e.g., 1 day): Logs out users out automatically after a set period, ideal for high-security environments.

• Medium-lived Sessions (e.g., 7 days): Retain sessions for a week, balancing convenience with security.

• Persistent Sessions: Keep users logged in until they explicitly log out, prioritizing convenience over strict security.

Example: For a banking app, use short-lived sessions (1 day), while for an internal portal, use 7-day sessions.

Session Validity Triggers

Define policies that influence session validity based on context:

• Geographic Location Changes: Require re-authentication if the user changes locations (e.g., switches countries).

• Device Changes: Trigger re-authentication when the user switches to a new device.

• Network Changes: Request re-authentication when switching networks (e.g., Wi-Fi to mobile data).

• Prolonged Inactivity: Automatically log out after a defined period of inactivity (e.g., 15 minutes)

Clients are authenticated through reliable and robust methods designed for security and authorization:

1. Client Secret: Clients can authenticate using a client secret to ensure secure and authorized interactions with the platform. For more details, refer to the relevant RFC. For more details, refer to OAuth 2.0 RFC 6749 Section 2.3.1.

2. Mutual TLS with x.509 Certificate: OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. This mechanism provides a secure method for client authentication and binding access tokens to a client's mutual-TLS certificate. For more details, refer to OAuth 2.0 RFC 8705.

These authentication methods, including mutual TLS with x.509 certificate, ensure a balanced approach to security, accessibility, and convenience for both users and clients within our platform.

The trust placed in IdPs can be measured through the following concepts:

1. Identity Assurance Levels (IALs): The degree of confidence in the accuracy and legitimacy of a user's identity during the identity proofing process with the following levels:

   • IAL1: Self-asserted identity with email/phone verification.

   • IAL2: Verified identity through methods like eKYC providers.

   • IAL3: High-confidence identity proofing through in-person verification.

2. Authentication Assurance Levels (AALs): The strength of the authentication process used by IdPs to verify the user’s identity.AALs are categorized into three levels:

   • AAL1: Single-factor authentication (e.g., password).

   • AAL2: Multi-factor authentication (e.g., password + one-time passcode).

   • AAL3: High-assurance multi-factor authentication (e.g., biometrics + hardware token).

3. Federation Assurance Levels (FALs): The trust and security levels between IdPs and applications or services when sharing digital identity information.

   • FAL1: Minimal verification, appropriate for low-risk services (e.g., basic login with username/password).

   • FAL2: Moderate verification, used for medium-risk transactions (e.g., eKYC, MFA).

   • FAL3: Rigorous verification is required for high-risk or sensitive data exchanges (e.g., biometrics, hardware tokens, encrypted communication).

Authentication (Authn) is the process of verifying the identity of users, devices, applications, or other entities, providing a level of assurance that they are who they claim to be. The result of an authentication process is an identifier that SHALL be used each time that subscriber authenticates to that RP. The identifier MAY be pseudonymous. Our system provides four levels of authentication assurance:

LoA 1 (Low Assurance)

At AAL1, authentication is typically performed using a single-factor authentication method, such as password or one-time passcodes (OTP) sent via SMS or Email. This level of assurance is suitable for environments with lower security requirements.

• Authentication Methods for AAL1:

  • Password

  • SMS OTP

  • Email OTP

  • TEL (Phone call verification)

LoA 2 (Moderate Assurance)

AAL2 requires multi-factor authentication (MFA), combining at least two independent factors to verify the identity of the user. This may include combinations of passwords, TOTP (Time-based One-Time Password), or Passkeys with methods like SMS OTP, Email OTP, or TEL. This level of assurance is appropriate for systems that require moderate security.

• Authentication Methods for AAL2:

  • Password + SMS OTP

  • Password + Email OTP

  • Password + TOTP

  • Passkeys + SMS OTP

  • Passkeys + Email OTP

  • TEL + Password

LoA 3 (High Assurance)

AAL3 involves strong multi-factor authentication to ensure high security, typically using biometrics or physical tokens like smartcards combined with TOTP, Passkeys, or SMS/Email OTP. This level is required for high-risk environments where robust identity verification is essential.

• Authentication Methods for AAL3:

  • Password + Passkeys + TOTP

  • Passkeys + TOTP + SMS OTP

  • Passkeys + TOTP + Email OTP

  • Passkeys + SMS OTP + TEL

  • Passkeys + Email OTP + TEL

LoA 4 (Very High Assurance)

AAL4 represents the highest level of assurance, involving multiple independent factors, including biometrics, smartcards, Passkeys, TOTP, SMS OTP, Email OTP, and TEL. This level is designed for environments that require maximum security, ensuring a very high level of trust in the user or entity's identity.

• Authentication Methods for AAL4:

  • Passkeys + TOTP + SMS OTP + TEL

  • Passkeys + TOTP + Email OTP + TEL

  • Passkeys + TOTP + Biometric Authentication

Authentication Factors

Our system categorizes authentication Factors into three classes:

• Something you know: Knowledge-based methods (e.g., passwords, PINs).

• Something you have: Possession-based methods (e.g., email, phonenumber, sms, voice, app one-time password generators).

• Something you are: Inherence-based methods (e.g., fingerprint, voice recognition, facial recognition, iris scan).

A digital identity is a set of data, including attributes and identifiers, that uniquely represents a person, organization, application, or entity within a digital ecosystem.

How Do You Obtain a Digital Identity?

A digital identity typically starts when you register with an online service or organization. During registration, you provide the necessary information to establish your identity in their system. Afterward, the system uses a process of authentication and authorization to verify and manage your identity.

• Authentication: You prove that you are who you claim to be, usually by entering your username and password. To enhance security, many services also use multi-factor authentication (MFA), requiring additional verification steps like a fingerprint scan or a verification code sent to your phone.

• Authorization: After authentication, the system grants you access to certain resources or services based on your identity. For example, you might gain access to your purchase history on an e-commerce site or to shared files in a corporate network.

• Identifiers: Once authenticated, the system tracks your activity (e.g., purchases, file uploads) and associates it with your unique digital identity.

Signed Cookies

Authenticate a user and provide them with a time-limited token for accessing your protected content. 

The authentication service defines confidence in authentication using Authenticator Assurance Levels (AALs), ranging from level 1 to 3.

Authenticator Assurance level 1

AAL 1 provides some assurance that a person controls the authenticator linked to their user account. The user must at least identify themselves using at least one of the following authenticators :

• Passkey (SF Passkey device or MF Passkey Device (if protected by pin or bio ) , possession)

• Password (Memorized Secret, knowledge)

• Email ()

• SMS

• Email

• Voice

• Authenticator App (SF OTP device or MF OTP Device (if protected by pin or bio), possession)

A User Authentication session must not last longer than 30 days, regardless of activity, with session termination after this time limit and records of these sessions will be stored according to your retention policies.

Authenticator Assurance level 2

Authenticator Assurance level 3

Additional considerations

When handling personally identifiable information (PII), we strongly recommend using at least AAL2.

• AAL1: At this level, the system has some confidence that the person controls an authenticator linked to their user account. The person can use one or more methods to verify their identity. They need to prove they have control over the authenticator using a secure process.

• AAL2: This level is more secure and gives high confidence that the person controls their authenticator. To verify their identity, the person must provide two different types of authentication (like something they know, such as a password, and something they have, like a phone). The authentication must be secure and use trusted methods, including cryptographic techniques (complex security methods).

• AAL3: This is the highest level of security, offering very high confidence that the person controls their authenticator. To verify their identity, the person must use a physical device (like a security key) and prove they possess it using cryptographic protocols (methods to securely exchange information). At this level, the person must prove control of two different types of authentication factors, and all methods used must be highly secure and include cryptography.

AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.

AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance — the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.

The Authenticator Assurance Levels (AALs) define the required security and factors for user authentication.

Reauthentication

Periodic reauthentication of subscriber sessions SHALL be performed as described in Section 7.2. At AAL3, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity, as described in Section 7.2. Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 15 minutes or longer. Reauthentication SHALL use both authentication factors. The session SHALL be terminated (i.e., logged out) when either of these time limits is reached. The verifier MAY prompt the user to cause activity just before the inactivity timeout.

Man In the Middle Resistance

Table 4-1 AAL Summary of Requirements

SMS authentication sends a one-time passcode (TOTP) to the user’s registered mobile phone via SMS for verification. It is a possession-based authenticator, as the user must possess the mobile device to access the code. To ensure security, we have implemented the following controls:

• One-time codes expire after a short duration, typically within 5 minutes.

• Rate-limiting mechanisms are in place to prevent abuse of the SMS system.

• Mobile phone numbers are verified to ensure that the code is sent to the correct device.

Password-based Authentication

• Password: Traditional authentication using a secret password.

Passwordless Authentication

• SMS: Time-based One-Time Code sent via SMS.

• Tel: Time-based One-Time Code delivered via telephone voice call.

• Email: One-time code or link sent to email.

• Authenticator App: Time-based One-Time Password (TOTP) generated by an app (e.g., Google Authenticator, Microsoft Authenticator).

• Passkeys: Cryptographic keys stored on the device.

External Identity Providers

• OIDC (OpenID Connect): Authentication via trusted third-party identity providers (e.g., Google, Microsoft, or other OIDC-compatible services) for seamless login.

Single Sign-On (SSO): Users can streamline their authentication process and access multiple applications securely with single sign-on (SSO) functionality.

Authenticator App Authentication Authenticator app authentication generates time-based one-time passwords (TOTP) on a mobile app (e.g., Google Authenticator, Microsoft Authenticator). This is a possession-based authenticator, as the user must have the device with the authenticator app installed to generate the authentication code. To ensure security, we have implemented the following controls:

• The TOTP expires after a short time, typically 30 seconds, to reduce the risk of interception.

• The app is set up securely, with secrets stored in encrypted form.

• The user has the flexibility to choose from a variety of supported authenticator apps.

Multifactor Authentication (MFA) is a security mechanism that requires two or more different types of authentication factors to verify a user’s identity.

Primary Types of Authentication Factors:

1. Something You Know: Information that only the user knows, such as a password or PIN.

2. Something You Have: A physical item the user possesses, such as a smartphone, security token, or smart card.

3. Something You Are: Biometric data unique to the user, such as a fingerprint, facial recognition, or voice recognition.

Additional Contextual Factors:

• Location: The user’s IP address or physical location.

• Time: The time of day or expected usage patterns.

Assurance Levels Supported by Our System

Our platform offers three levels of authentication, each designed to meet different security needs. Low, Medium, and High levels vary based on the number and type of factors used to verify a user’s identity.

1. Low:

   • Requires the user to authenticate with one factor from any of the following categories:

     • Something You Know (e.g., password, PIN)

     • Something You Have (e.g., security token, smartphone)

     • Something You Are (e.g., fingerprint, facial recognition)

   Note: Low mode is not recommended for critical or high-risk systems, as it provides only basic security. It is more suitable for low-risk environments or non-sensitive applications.

2. Medium:

   • Requires the user to authenticate with two factors from any of the following combinations:

     • Something You Know & Something You Have (e.g., password + OTP)

     • Something You Have & Something You Are (e.g., security token + fingerprint)

     • Something You Are & Something You Know (e.g., facial recognition + password)

   Medium mode provides an enhanced level of security, making it suitable for most general use cases where moderate security is necessary.

3. High:

   • Requires the user to authenticate with three factors from the following categories:

     • Something You Know (e.g., password)

     • Something You Have (e.g., smartphone, hardware token)

     • Something You Are (e.g., biometrics like fingerprint or facial recognition)

   High mode offers the strongest security and is ideal for high-assurance environments, where protecting sensitive or critical data is essential.

Assurance Levels Mapping Across Frameworks

Below is a table showing how the Low, Medium, and High modes map to the authentication requirements in different compliance and security frameworks:

Access Token

An access token refers to a token that a client can use to call endpoints.

Access tokens refer to tokens that enable clients to securely call protected endpoints. They contain information about the user and the resource for which it is intended.

ID tokens refer to tokens which clients can use to identify a user, they contain information based on the requested claims & scope.

Multi-factor software cryptographic authenticators encapsulate one or more secret keys unique to the authenticator and accessible only through the input of an additional factor, either a memorized secret or a biometric.

A passkey is a modern cryptographic credential that consists of a public key stored on the server and a private key stored on the user's device. It is a possession-based authenticator for a user to verify their identity. A passkey is a modern, cryptographic credential that replaces traditional passwords. It consists of a pair of keys: a public key stored on the server and a private key securely stored on the user’s device. Passkeys are possession-based authenticators because they rely on the user having a specific device (e.g., smartphone, laptop) that holds the private key. A password is a secret that only one person should memorize and know. It is a knowledge-based authenticator for a user to verify their identity. To ensure security, we have implemented the following Measures:

Controls in place for security:

• The private key never leaves the device, ensuring it’s never exposed. Each authentication operation using the authenticator SHALL require the input of both factors.

• Passkeys are stored in a secure hardware module or secure enclave on the device.

• The use of passkeys is tied to the device and cannot be shared or easily stolen by malicious actors.

• Passkeys are stored in a secure hardware module or secure enclave.

• The private key never leaves the device, preventing exposure during authentication.

• Passkeys are automatically managed by the device, reducing the risk of human error.

Overview

A password is a secret that only one person should memorize and know. It is a knowledge-based authenticator for a user to verify their identity. To ensure security, we have implemented the following Measures:

Password Authenticator Requirements

• Password Length: User-chosen passwords are required to be at least 8 characters long and may be up to 64 characters in length.

• Password Complexity and Blacklisting: We enforce checks to ensure that passwords are not commonly used or compromised. This includes cross-referencing with blacklists of known weak or breached passwords and rejecting passwords that match.

• Hashing and Salted Storage: We use industry-standard cryptographic techniques to securely store passwords, including salted hashing, to resist offline attacks. We also ensure that password storage is designed to be resistant to brute-force attacks through the use of key derivation functions (e.g., PBKDF2) and iterative hashing techniques.

• Secure Password Transmission: Passwords are transmitted over encrypted channels (e.g., TLS) to protect against man-in-the-middle (MitM) and eavesdropping attacks.

to 64 characters.

• Passwords must not be part of our compromised passwords list.

• Passwords

• If the password appears in a compromised list, the user must choose a new one.

• Complexity requirements (e.g., mix of character types) should not be enforced unless necessary. Detailed reasoning for this is provided in Appendix A.

5.1.1.2 Verifier Requirements

• Verifiers must accept ASCII and Unicode characters in memorized secrets.

• The minimum length for user-chosen secrets is 8 characters, with a maximum of 64 characters recommended.

• Verifiers must not allow insecure hints, such as personal questions, or encourage weak secrets.

• Blacklist check: Verifiers must ensure secrets are not part of known compromised passwords (e.g., from data breaches, dictionary words, or patterns).

• Verifiers should encourage strong passwords through tools like password strength meters.

• Rate limiting must be in place to prevent brute-force attacks.

Security Measures for Storing Passwords

• Encryption and a secure channel must be used when transmitting passwords to prevent eavesdropping.

• Password storage: Verifiers must hash and salt passwords with a key derivation function (e.g., PBKDF2), making them resistant to offline attacks.

  • Salt should be at least 32 bits in length.

  • A cost factor (e.g., iteration count) should be applied to increase the time it takes to compute the hash, typically requiring at least 10,000 iterations.

• If a secret salt is used, it must be stored securely and separately.

5.1.1.4 Password User Experience Enhancements

• Verifiers should allow paste functionality for users to input passwords, especially for users utilizing password managers.

• Optionally, verifiers should allow users to view their password temporarily while entering it (to avoid errors, especially on mobile devices).

• Passwords should be displayed in a masked format (dots or asterisks) with the option to unmask them for verification in private environments.

5.1.1.5 Password Updates

• Users should be able to change passwords freely without arbitrary requirements (e.g., periodic resets).

• If a password is compromised, the system should enforce a mandatory change.

Additional Considerations

User Education

Security Awareness: Users should be educated on the importance of using strong, unique passwords for each service and guided on creating secure passwords.

An authorization code is a one-time use token which is generated during the authorization request after authentication. The client can exchange this authorization code with the authorization server for an access_token.

Refresh Token

A refresh token refers to a one-time-use token that a client can use to exchange for a renewed access token and extend the duration of the privileged session. To obtain a refresh token, you need to include the ‘offline_access’ scope when you initiate an authorization request, and the user must authorize the ‘offline_access’ scope.

Authorization Protocols

Our platform utilizes the Open Authorization 2.1 (OAuth) standards to grant access to resources per the access control models outlined in the previous chapter. The OAuth standard defines four important roles:

The Resource Owner (RO)

• Definition: The Resource Owner is an entity with the authority to grant access to a protected resource. This entity may be an individual (end-user), or an organization.

• Sidenote: Delegated access happens when Resource Owners grant authorization to other entities, such as organizations, individual users, or applications, to perform actions on behalf of the Resource Owner.

The Resource Server (RS)

• Definition: The Resource Server is an application hosting the protected resources. It handles requests for these resources from the Client and makes them available via an API after access token validation.

Sidenote: The Resource Server responds to these requests by validating the provided access tokens through various methods to ensure they are valid and authorize the request.

The Client

• Definition: The Client is an application making requests for protected resources on behalf of the Resource Owner, with the Resource Owner's authorization obtained through the OAuth process.

Sidenote: The Client can be deployed on a variety of platforms, including but not limited to virtual machines, bare metal servers, desktops, edge devices, and IoT devices.

The Authorization Server (AS)

• Definition: The Authorization Server is an application responsible for issuing access tokens to the Client following successful authentication of the Resource Owner and obtaining authorization.

To authorize end-users, we utilize the Authorization Code Flow with Proof Key for Code Exchange (PKCE). This can be implemented using client libraries for the following use cases:

• Mobile Applications

• Native Applications

• SaaS Platforms

• Websites

• Desktop Applications

• Single Sign-On (SSO)

To authorize applications, we utilize the Client Credential Flow. Which can be implemented using client libraries for the following use cases:

• Scheduled Tasks and Cron Jobs

• Data Synchronization

• System-to-system integrations

• Inter-Microservice Communication

• Internet of Things (IoT) Device Communication

• Automated Testing Environment

Still pending…

The Application Programming Interface (API)

• The API acts as a communication channel between applications, enabling them to interact and exchange information with each other.

• Supported Protocols: HTTP APIs & RESTful APIs

• Protocols examples: HTTPS, RESTful APIs, SIP, SRTP, gRPC, AMQPS etc.

Privileges

Privileges are permissions assigned to an individual or groups. Privileges can be inherited by an overlapping entity.

Groups

Groups refers to collections of users or other entities that share a common set of privileges.

Permissions

Permissions refer to the declaration of actions that can be performed on a specific resource by a user or an application.

Scope

Scope refers to what an application can do on behalf of the user.

The Identity Hub is a centralized system that enables administrators to configure and manage all aspects of identity service.

Key Features for Hub Administrators

Entities

• User Management: Create, update, and deactivate user accounts from a centralized interface.

• Organization Management: Manage multiple organizations within the system, ensuring appropriate access and permissions for each.

• SCIM Management: Implement and manage System for Cross-domain Identity Management (SCIM) for user provisioning and management.

Security

Access Control

• OAuth Management: Configure and manage OAuth authorization settings for secure access to applications.

• JWKS Management: Handle JSON Web Key Sets (JWKS) for signing and encrypting tokens to enhance security.

• OAuth2 Metadata Management: Manage OAuth2 metadata for clients and authorization servers to streamline integration.

• OAuth Client Management: Configure and manage OAuth clients, controlling their permissions and settings.

• Protected Resource Management: Define and manage resources that require protection through access controls.

• Audit Log Management: Monitor user activities and changes with detailed audit logs for compliance and oversight.

• Account Recovery Management: Assist end-users in recovering their accounts if they forget their credentials or become locked out.

• Account Registration Management: Oversee the registration process, ensuring it meets organizational standards and compliance requirements.

• Application Access Control: Manage access to multiple applications and control which users can use single sign-on (SSO).

• Consent Management Administration: Configure and manage consent settings for data sharing and privacy preferences on behalf of end-users.

• Data Access Request Management: Handle user requests for accessing personal data, data exports, and account deletions to ensure compliance with data protection regulations.

• Identity Verification Configuration: Set parameters for identity verification processes, enhancing security during user access.

• Notifications and Alerts Setup: Configure notifications and alerts for important events, such as account lockouts or suspicious activities.

• Profile Management Control: Assist in managing end-user profiles, allowing for updates and changes to personal information.

• Session Management Oversight: Monitor and manage user sessions to ensure account security and mitigate potential security risks.

• Reporting and Analytics Tools: Generate reports on user activity, access patterns, and system performance for informed decision-making.

• Integration Management: Manage integrations with third-party applications and services to ensure seamless connectivity and data flow.

• Authentication Management: Set and manage authentication methods, including multi-factor authentication (MFA) and passwordless options.

• Authentication Policies Configuration: Enforce authentication methods for end-users, such as passkeys, biometrics, and passwords.

Authentication

Authentication, or "AuthN," is the process of proving identity with sufficient confidence and establishing a secure connection between the end-user and the service.

Authorization

Authorization, or "AuthZ," is the process of granting access to resources based on various constraints, including actions, permissions, policies, and other attributes.

Accounting

Accounting, or "Auditing," refers to the process of monitoring events and logging records of who accessed what resources, when, and the actions taken within an audit trail.

Identity Mapping

The branding configuration for the Identity Self-Service Portal enables administrators to customize the portal's visual identity to align with their brand. This includes modifying logos, theme colors, fonts, and favicons.

Accessibility Compliance Our accessibility checker ensures that dark and light modes comply with Web Content Accessibility Guidelines (WCAG). This tool helps maintain sufficient contrast between text and background, enhancing readability and accessibility for all users.

Password Authentication Protocol (PAP)

The Password Authentication Protocol (PAP) involves users providing their username and password, which the system then checks against a centralized database for verification.

Process:

1. User Input: Users start by entering their credentials, comprising a username and password.

2. Credential Verification: The system checks these credentials against a central database to confirm their accuracy.

3. Authentication: If the provided credentials match those in the database, the user is successfully authenticated, gaining access to the system

Time-based One-Time Passwords (TOTP) Protocol

TOTP Protocol is a time-sensitive method for generating one-time passwords. It can be deployed through channels such as email, SMS, and authenticator applications.

Process:

1. Setup: Exchange of a shared secret key between the authentication server and the user's device.

2. Synchronization: Both server and device synchronize their clocks to a common time reference.

3. OTP Generation: TOTP algorithm generates a unique one-time password using the shared key and current time.

4. User Authentication: User enters the OTP generated by their device. If it matches the server's calculated OTP, authentication is successful.

Open Identity Protocol (OpenID)

OpenID, an open standard and decentralized authentication protocol, enables user authentication through a third-party identity provider (IdP) service.

Process:

1. User Authentication Request: Users can be authenticated on collaborating sites (relying parties) using a third-party identity provider (IdP) service.

2. IdP Verification: The third-party identity provider verifies the user using its authentication mechanism.

3. Successful Authentication: If the user is successfully authenticated at the IdP, access is granted at the relying party's site, ensuring a secure and streamlined authentication process.

Universal Authentication Framework (UAF)

The Universal Authentication Framework (UAF) is a protocol developed by the FIDO Alliance, providing a secure and passwordless authentication solution.

Process:

1. During registration, the user associates their device with the online service.

2. The user selects a local authentication mechanism, such as swiping a finger, using facial recognition, speaking into the microphone, or entering a PIN.

3. This mechanism generates a private key that is used to sign a challenge issued by the FIDO UAF Server.

Mutual TLS (mTLS)

Mutual TLS extends the TLS protocol to achieve mutual authentication between the client and server by requiring both parties to present valid X.509 certificates.

Process:

1. Client Certificate Presentation: The client presents its X.509 certificate to the server during the SSL/TLS handshake.

2. Server Verification: The server verifies the client's certificate, ensuring its validity and proper signing by a trusted Certificate Authority (CA).

3. Server Certificate Presentation: The server presents its X.509 certificate to the client during the SSL/TLS handshake.

4. Client Verification: The client verifies the server's certificate, ensuring its validity and appropriate signing by a trusted CA.

5. Successful Authentication: If both certificates pass verification, mutual authentication is achieved, and a secure communication channel is established.

To govern access to services our platform supports two types of access control models: RBAC (Role-based Access Control) and ABAC (Attribute-based Access Control) through Open Policy Agent using REGO language.

Understanding RBAC

RBAC is an access control model that restricts access to resources based on predefined roles. Each role is associated with a distinct name and has a predefined set of permissions and policies.

Hierarchical Role Assignment

Our service allows roles to be assigned to users, companies, and groups, creating a hierarchical structure for role assignments.

Practical Approach

Our recommendation is to establish and assign roles to groups instead of individual users. By utilizing groups, it facilitates the easy addition or removal of users and ensures consistent permissions for all group members.

How do we recommend using roles within your services?

By reading the role from introspection of the access token

allow if {

user_is_manager

}


user_is_owner if data.user_attributes\[input.user\].title == "manager"

By Using Policy Decision Point (Recommended)

if (response.allow) {

   // Allow access to the resource

} else {

  res.status(403).send('Unauthorized');

}

ABAC

ABAC is an access control model that restricts access to resources based on attributes. These attributes may include permissions, policies, departments, locations, IP addresses, and time conditions. These attributes can be assigned to users, groups, applications, or other entities.

if (

   attributes.includes("role:manager") &&

   attributes.includes("permission:read:document") &&

   attributes.includes("department:marketing") &&

   attributes.includes("location:office") &&

   attributes.includes("origin: 192.168.0.1") &&

) {

   // Allow access to the resource

} else {

   // Deny access

}

The Identity Self Service Portal Builder enables you to customize Identity Self Service Portal User Self-Service Portal

The User Self-Service Portal gives you full control over your account management. Whether you need to log in, register, recover your account, or manage your privacy settings, this portal offers all the essential features. Below are the main functionalities, each with links to more detailed instructions for ease of use.

Choose Your Onboarding Configuration

TF Platform-hosted Self Service Portal

This option offers a fully managed solution where users can authenticate, authorize, and manage their profiles through a TF Platform-hosted web form, customized with your brand’s name, colors, and icon. The form is generated using the Identity Hub API, ensuring robust data validation, compliance with global regulations, and seamless localization. TF Platform handles the complete identity lifecycle, including authentication, authorization, consent management, session management, and profile management.

Recommended for: Teams that want an out-of-the-box solution with minimal integration effort, where TF Platform manages all aspects of identity and access management (IAM).

API-Driven Self Service Portal

With this approach, you use the Identity Self Service API to build and maintain a fully customized identity management experience. Your application manages all key components—authentication, authorization, consent, session, and profile management—tailored to your specific business needs. You’ll have full control over the integration of various authentication methods (e.g., multi-factor authentication, biometrics), localization, and compliance requirements. Regular updates are required to meet evolving security and regulatory standards.

Recommended for: Organizations with the technical capacity to manage the complexities of a custom IAM solution, offering full control over authentication, authorization, and user experience. This is ideal for teams that require greater flexibility and customization for security and identity management processes.

1. Overview and Dashboard

• System Overview

• User Statistics

• Security Alerts

• Compliance Status

• Performance Metrics

The SEO settings feature in the Identity Self-Service Portal Builder allows administrators to control how the portal appears in browsers & search engine results.

It enables you to such as page titles, descriptions & keywords.

Steps to Configure SEO Settings for the Identity Self-Service Portal

1. Go to SEO Settings: From the Identity Self-Service Portal Builder page, navigate to the SEO settings section.

2. Update Metadata: Enter the page title, meta description, and up to 10 relevant meta keywords.

3. Set Search Visibility: Enable or disable the portal’s visibility on search engines as needed.

Steps to Enable User Self-Registration:

1. Navigate to the Identity Hub.

2. Access the Identity Self-Service Portal Builder:

   • Select Identity Self-Service Portal Builder from the main menu.

3. Open the Registration Tab:

   • Click on the Registration tab.

4. Enable User Registration:

   • Toggle the User Registration option to the preferred state.

Once you enable this setting, a Register link will appear on the login page of the selected Identity Self-Service Portal, allowing users to create their accounts.

Enable Self-Registration

You can Enable/disable registration for your users using the TF Platform. When enabled, this feature adds a registration link to the login page, allowing end-users to register their own accounts.

Configurable States for Workflow Components

Each component of the registration workflow can be assigned one of three states:

• Required: The end-user must complete this step to proceed with registration.

• Optional: The end-user can choose to skip this step.

• Hidden: This step will not be visible to the end-user.

Self-Registration Process Overview

The self-registration process involves five steps designed to enhance security and personalize account setup. Each step can be assigned one of the three states mentioned above.

Step 1: Email Verification

End-users must verify their email addresses using a Time-Based One-Time Password (TOTP) sent to their registered email. This step is required by default.

Step 2: Terms of Service Agreement

After verifying their email, end-users can review and accept the Terms of Service. This step can be marked as required, optional, or hidden.

Step 3: Profile Completion

End-users can provide additional information for their profiles, such as their name, gender, date of birth, and address details. This step can be assigned as required, optional, or hidden.

Step 4: Phone Number Verification

For added security, end-users can verify their phone numbers using TOTP. This step can be set as required, optional, or hidden.

Step 5: Username and Password Creation

End-users can create a unique username and a strong password that meets specified security criteria. This step can also be marked as required, optional, or hidden.

Steps to configure the Registration Workflow Editor:

1. Navigate to the Identity Hub.

2. Access the Identity Self-Service Portal Builder:

   • Select Identity Self-Service Portal Builder from the main menu.

3. Open the Registration settings:

   • Click on the Workflow Editor tab.

4. Configure Registration Steps:

   • Add, edit, or remove registration steps in the workflow.

5. Set Step Properties:

   • For each step, specify the following:

     • Component Type: Choose from available registration components (e.g., Email, Phone Number, Terms and Conditions).

     • Display Mode: Set visibility options for each step (e.g., required, optional, hidden).

6. Save Configuration:

   • Click the Save button to apply changes to the registration workflow.

Post-Registration Configuration Options:

1. Access the Identity Self-Service Portal: Navigate to the Identity Self Service Portal through the Access Manager.

2. Single Sign-On (SSO) into the Application: Use SSO to sign into the application where the user will continue their onboarding process.

In the platform, we categorize OAuth clients into two types: public and confidential. Here's a breakdown of the core functionality for both client types and how to manage them.

1. Public Clients

Public clients are used in applications where the code runs on the user's device, making it impossible to store secrets securely. We use Authorization Code Flow with PKCE (Proof of Key Code Exchange) to protect against token theft without needing client secrets.

Using Public clients is recommended for the following application types:

• Browser-based applications (SPAs & Multi-Page Applications)

• Mobile native apps

• Progressive Web Apps (PWAs)

• Desktop applications

Key Configurations for Public Clients:

• Redirect URIs: The allowed URIs for redirecting after authentication.

• Allowed Grant Types: For public clients, typically authorization_code and refresh_token grant types are used.

• Scopes: Permissions requested by the client, such as openid, profile, and email.

2. Confidential Clients

Confidential clients are used in server-based applications, where the client secret can be stored securely. These clients:

• Require secure storage of the client secret.

• Can use advanced authentication methods like private key JWT.

Key Configurations for Confidential Clients:

• Client Secret: A securely stored secret for authenticating with the OAuth server.

• Token Endpoint Authentication Method: Methods such as client_secret_basic or private_key_jwt for securely authenticating to the token endpoint.

• Additional Security Settings: Settings for stronger authentication flows, such as JWT signing.

Creating a Client

Steps to Create a Client

1. Navigate to Client Management Page: Access the admin interface and locate the client management section.

2. Select Client Type: Choose between creating a Public or Confidential client.

3. Configure Settings:

   • Public Clients: Configure settings like redirect URIs, allowed scopes, and grant types.

   • Confidential Clients: Securely store client secrets, configure redirect URIs, and apply advanced security settings such as token endpoint authentication.

4. Save and Register: Once all configurations are made, save the settings and confirm client registration.

Managing Client Settings

Public Client Settings:

• Redirect URIs: List of authorized URLs for redirecting after authentication.

• Allowed Grant Types: Grant types like authorization_code and refresh_token.

• Scopes: Permissions such as openid, email, and profile that the client can request.

Confidential Client Settings:

• Client Secret: Securely stored secret for authenticating the client.

• Token Endpoint Authentication Method: Secure authentication methods such as client_secret_post or private_key_jwt.

• Advanced Security: Additional security configurations for confidential client

Steps to Configure Branding in the Identity Self-Service Portal Builder

1. Open the Identity Self-Service Portal Builder Navigate to the Identity Self-Service Portal Builder page within the platform.

2. Access Branding Configuration Locate and click on the branding configuration section.

3. Upload Logos

   • Light Theme Logo: Click on the option to upload an image for the light theme logo. Ensure the image is in either PNG or SVG format.

4. Set Theme Colors

   • Enter the primary color using a valid hexadecimal code (e.g., #ff5733). Ensure the color falls within the specified range.

5. Upload Favicon

   • Click to upload a favicon in ICO, PNG, or SVG format. This favicon will appear in the browser tab.

6. Configure Fonts

   • Select a font family from the dropdown menu, which includes the top 15 supported UI fonts for use throughout the portal.

7. Run Accessibility Checker

   • After making your changes, use the accessibility checker to verify compliance with Web Content Accessibility Guidelines (WCAG) for both dark and light modes.

8. Save Changes

   • Once you have completed all branding configurations, click Save to apply the new settings to the portal.

Manual Process

The manual identity verification process involves several steps:

1. Data Collection:

   • Collect the user's personal data, including name, address, date of birth, etc.

   • Obtain a copy of a government-issued ID (passport, driver's license, etc.).

2. **

Search Functionality

• Quickly locate specific users by entering keywords such as usernames, emails, or IDs, with instant results for efficient navigation.

Filtering Options

• Narrow down the user list based on criteria like roles (admin, viewer), status (active, inactive), or registration date, allowing for customized views and precise selection.

Pagination

• View users in manageable chunks, making navigation easier with options to jump between pages or select how many users to display at once.

Bulk Actions (Optional)

• Perform mass updates on selected users, such as role changes or status updates, streamlining administrative tasks for larger user bases.

This feature gives administrators a streamlined tool to manage Data Subject Access Requests, ensuring full compliance with data privacy regulations directly from the Identity Platform.

Steps to Manage Data Subject Requests

1. Access the Identity Hub:

   • Navigate to the Identity Hub within the platform.

2. Select the Relevant User:

   • Locate and select the user who submitted the DSAR.

3. Navigate to the User Profile:

   • Open the selected user’s profile page for detailed information.

4. Process the Request:

   • Choose the “Data Subject Requests” option to view and handle specific requests:

     • Access Request: Retrieve the user’s personal data.

     • Correction Request: Update or correct inaccurate or incomplete data.

     • Deletion Request: Permanently erase personal data from the system.

     • Export Request: Generate and provide personal data in a structured, machine-readable format.

.

The account recovery request functionality is available for users of the Identity Hub with available authentication methods of If a user would If your user is connected to an external identity provider, account recovery must be done from the external identity provider.

Steps to Create a Client

1. Navigate to Client Management Page: Access the admin interface and locate the client management section.

2. Select Client Type: Choose between creating a Public or Confidential client.

3. Configure Settings:

   • Public Clients: Configure settings like redirect URIs, allowed scopes, and grant types.

   • Confidential Clients: Securely store client secrets, configure redirect URIs, and apply advanced security settings such as token endpoint authentication.

4. Save and Register: Once all configurations are made, save the settings and confirm client registration.

Communications Feature Documentation

Overview

The Communications feature is an integral part of the platform, offering seamless integration with the IAM (Identity and Access Management) system. This allows for effective communication with your users across various channels such as email, SMS, push notifications, and social media messaging.

Key Features

Analytics: Gain insights into message delivery status and user engagement.

Customization: Tailor messages to fit the specific needs and preferences of your users.

User Management: View and manage user interactions across different channels from a unified interface.

Multi-Channel Messaging: Seamlessly send messages via email, SMS, push notifications, and more.

Sending Messages

Configure additional channels such as SMS, push notifications, and social media messaging. This flexibility ensures that you can reach users through their preferred communication method.

View History

This tab enables you to manage messages sent through the platform using the Omnichannel Dispatcher. Track and review the history of all communications for improved user

Sending Messages

1. Go to the Messages tab.

2. Select the user(s) you wish to contact.

3. Choose the channel and compose your message.

4. Click Send to dispatch the message.

This integrated approach ensures effective communication, enhancing user engagement and satisfaction. To configure communication channels, refer to ...

Account recovery management is enables hub administrators to assist end-users in regaining access to their accounts.