This article presents an overview of the fundamental concepts that guide access control, covering authentication, authorization, and accounting (AAA) across our services.
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, or "AuthZ," is the process of granting access to resources based on various constraints, including actions, permissions, policies, and other attributes.
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.
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.
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.
Our service allows roles to be assigned to users, companies, and groups, creating a hierarchical structure for role assignments.
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.
By reading the role from introspection of the access token
By Using Policy Decision Point (Recommended)
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.
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:
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.
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.
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.
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 are permissions assigned to an individual or groups. Privileges can be inherited by an overlapping entity.
Groups refers to collections of users or other entities that share a common set of privileges.
Permissions refer to the declaration of actions that can be performed on a specific resource by a user or an application.
Scope refers to what an application can do on behalf of the user.
The Password Authentication Protocol (PAP) involves users providing their username and password, which the system then checks against a centralized database for verification.
Process:
User Input: Users start by entering their credentials, comprising a username and password.
Credential Verification: The system checks these credentials against a central database to confirm their accuracy.
Authentication: If the provided credentials match those in the database, the user is successfully authenticated, gaining access to the system
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:
Setup: Exchange of a shared secret key between the authentication server and the user's device.
Synchronization: Both server and device synchronize their clocks to a common time reference.
OTP Generation: TOTP algorithm generates a unique one-time password using the shared key and current time.
User Authentication: User enters the OTP generated by their device. If it matches the server's calculated OTP, authentication is successful.
OpenID, an open standard and decentralized authentication protocol, enables user authentication through a third-party identity provider (IdP) service.
Process:
User Authentication Request: Users can be authenticated on collaborating sites (relying parties) using a third-party identity provider (IdP) service.
IdP Verification: The third-party identity provider verifies the user using its authentication mechanism.
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.
The Universal Authentication Framework (UAF) is a protocol developed by the FIDO Alliance, providing a secure and passwordless authentication solution.
Process:
During registration, the user associates their device with the online service.
The user selects a local authentication mechanism, such as swiping a finger, using facial recognition, speaking into the microphone, or entering a PIN.
This mechanism generates a private key that is used to sign a challenge issued by the FIDO UAF Server.
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:
Client Certificate Presentation: The client presents its X.509 certificate to the server during the SSL/TLS handshake.
Server Verification: The server verifies the client's certificate, ensuring its validity and proper signing by a trusted Certificate Authority (CA).
Server Certificate Presentation: The server presents its X.509 certificate to the client during the SSL/TLS handshake.
Client Verification: The client verifies the server's certificate, ensuring its validity and appropriate signing by a trusted CA.
Successful Authentication: If both certificates pass verification, mutual authentication is achieved, and a secure communication channel is established.