Access control & Identity
Access control and identity management are the mechanisms that determine who can access your GLBNXT Platform environment, what they can do within it, and how those permissions are enforced consistently across every component. A well-configured access control model ensures that users, service accounts, and application workloads have exactly the access they need and nothing more, reducing the risk of both accidental misuse and deliberate exploitation of overprivileged accounts.
On GLBNXT Platform, access control is applied at every layer of the environment: the platform console, model endpoints, data services, application workloads, and administrative functions. Identity management integrates with your organisation's existing identity provider, so platform access aligns with the same policies and controls that govern the rest of your technology estate.
Identity and Authentication
Every user accessing GLBNXT Platform authenticates through a managed identity layer before reaching any platform resource. Authentication can be configured in two ways depending on your organisation's setup.
SSO Integration
For organisations using an enterprise identity provider, GLBNXT Platform supports single sign-on via SAML and OAuth 2.0. Supported identity providers include Azure Active Directory, Okta, and Google Workspace. When SSO is configured, users authenticate through their existing organisational identity and are granted platform access based on the roles assigned to their account. Password management, MFA enforcement, and session policies are handled by the identity provider and apply the same standards as the rest of your organisation's systems.
SSO integration is the recommended configuration for all enterprise deployments. It ensures that platform access is governed by your organisation's centralised identity and access management policies, that user accounts are automatically deprovisioned when an employee leaves, and that MFA and session controls are enforced consistently without requiring separate configuration in the platform.
Direct Login
For environments where SSO has not been configured, users log in using credentials issued directly by GLBNXT. Direct login credentials are managed through the platform console. Users should update their password on first login and enable multi-factor authentication immediately. Direct login is appropriate for initial onboarding and evaluation environments but should be replaced with SSO integration for production deployments.
Multi-Factor Authentication
Multi-factor authentication is enforced by default for all administrator accounts on GLBNXT Platform and strongly recommended for all user accounts. For environments using SSO, MFA is handled by the identity provider. For direct login accounts, MFA is configured through the account settings in the platform console.
MFA significantly reduces the risk of account compromise from credential theft. In regulated environments or environments processing sensitive data, MFA should be treated as a mandatory control for all accounts regardless of role.
Role-Based Access Control
Access to platform resources is governed by role-based access control. Roles define the combination of resources a user can access and the actions they can perform on those resources. Users are assigned one or more roles that reflect their responsibilities within the platform environment.
GLBNXT Platform provides a set of standard roles applicable to most development team configurations.
Administrator has full access to all platform components, user management, environment configuration, and administrative functions. Administrator access should be limited to the smallest number of individuals who genuinely require it. Administrative actions are logged in full as part of the platform audit trail.
Developer has access to applications, model endpoints, data services, workflow builders, and development tooling. Developers can build, configure, and test solutions within the platform but do not have access to user management or environment-level administrative controls.
Data Engineer has access to data services, ingestion pipelines, vector database configuration, and storage components relevant to data engineering work. Access to model endpoints and application frontends may be included depending on your environment configuration.
Viewer has read-only access to selected platform components and dashboards. This role is suited for stakeholders who need visibility into platform activity or application outputs without making changes to any configuration or workload.
Custom roles can be configured for organisations whose access requirements do not map to the standard role set. Contact your GLBNXT contact to discuss custom role configuration for your environment.
Principle of Least Privilege
All role assignments on GLBNXT Platform should follow the principle of least privilege. Every user account and service account should be granted access only to the resources it specifically requires to fulfil its defined purpose. Overprivileged accounts increase the potential impact of a compromised credential and create unnecessary risk from accidental misconfiguration or misuse.
Applying least privilege in practice means resisting the temptation to assign broad roles for convenience. A developer who needs access to a specific set of model endpoints and a specific database instance should be granted access to those specific resources, not given platform-wide developer access because it is easier to configure. The additional configuration effort is small. The reduction in risk is significant.
Service Account Access
Application workloads running on GLBNXT Platform authenticate to platform services using service accounts rather than user credentials. Service accounts are identities assigned to application workloads that grant them access to the specific platform resources they need to function, such as a model endpoint, a database connection, or a storage bucket.
Service account credentials are managed through the platform secrets vault and injected into workloads at runtime. Application code never handles service account credentials directly. This ensures that credentials cannot be accidentally exposed in source code or configuration files, and that credential rotation does not require changes to application logic.
Service accounts should follow the same least privilege principle as user accounts. Each application workload should have a dedicated service account with access scoped to exactly the resources that workload requires.
User Provisioning and Deprovisioning
User accounts on GLBNXT Platform are provisioned during onboarding based on the access list provided by your organisation. For environments using SSO, provisioning and deprovisioning can be automated through your identity provider's user lifecycle management capabilities, ensuring that platform access is granted and revoked in synchronisation with the rest of your organisation's systems.
For environments using direct login, user provisioning and deprovisioning is managed through the platform console by your platform administrator. Deprovisioning should be performed promptly when a team member leaves the organisation or changes role. Accounts that are no longer required but remain active represent an unnecessary security risk.
Conducting a periodic access review to verify that all active accounts have appropriate role assignments for their current responsibilities is recommended practice for any production platform environment.
Access Logs and Auditability
All access events on GLBNXT Platform are logged as part of the platform audit trail. This includes user login and logout events, failed authentication attempts, role assignment changes, access to model endpoints and data services, administrative actions, and service account authentication events.
Access logs are immutable, timestamped, and retained according to the compliance requirements of your environment. They are available through the Monitoring and Observability area of the platform console and can be exported for integration with your organisation's SIEM, compliance, or audit tooling.
For regulated environments, access logs form part of the evidence base that demonstrates compliance with data protection and information security obligations. Ensuring that logging is active and correctly configured for your environment should be verified as part of the onboarding process and reviewed periodically.
Configuring Access Controls for Your Environment
Access control configuration for your environment is established during onboarding in collaboration with your GLBNXT contact. The recommended steps for configuring access controls are:
Define the roles required for your team based on the responsibilities of each member and the access each role needs
Configure SSO integration with your identity provider before provisioning user accounts
Create user accounts and assign roles based on the access list agreed during onboarding
Configure service accounts for each application workload with access scoped to the specific resources that workload requires
Enable MFA for all accounts where it is not already enforced through your identity provider
Verify that access logs are active and capturing events correctly
Schedule a periodic access review to keep role assignments aligned with current team responsibilities
For guidance on the security architecture that access control operates within, see the Security Architecture section. For guidance on secrets management and service account credential handling, see the Secrets and Credential Management section.
Last updated
Was this helpful?