Skip to main content

Single Sign-On (SSO) Authentication

Single Sign-On (SSO) is an authentication mechanism that allows users to authenticate once and securely access multiple connected applications or services without re-entering credentials. SSO improves user experience while centralizing authentication and access control across systems.

By consolidating authentication into a trusted identity platform, SSO reduces credential sprawl, simplifies access management, and supports enterprise security and compliance requirements.

SSO Key Concepts

  • Identity Provider (IdP): The IdP is responsible for authenticating the user and issuing an authentication token, which allows access to connected applications. The IdP stores the user's credentials and is the authoritative source of authentication.
  • Service Provider (SP): An SP is any application or service that relies on the IdP for user authentication. After the IdP authenticates a user, the SP grants access based on the authentication token.
  • Centralized Authentication: SSO streamlines user authentication by consolidating it into a single service. After successfully authenticating with the IdP, the user gains automatic access to other associated applications (SPs) without re-entering credentials.
  • Token-Based Authentication: SSO systems frequently use tokens to manage user sessions across multiple services, such as JSON Web Tokens (JWT), SAML assertions, or OAuth tokens. These tokens are exchanged between the IdP and the SPs to confirm the user's identity.
  • Single Sign-Off: Some SSO systems support the Single Sign-Off (SSO) feature, which allows users to log out of all connected applications at the same time when they log out of one.

SSO Protocols

  • Security Assertion Markup Language (SAML): SAML is an XML-based protocol for exchanging authentication and authorization data between an IdP and an SP. It is widely used in enterprise SSO implementations.
  • OAuth/OpenID Connect: OAuth is an authorization protocol that allows third-party applications limited access to a user's resources. OpenID Connect is a layer on top of OAuth 2.0 that adds authentication functionality, allowing it to function as an SSO solution.
  • Lightweight Directory Access Protocol (LDAP): LDAP is often used by identity providers to store and retrieve user credentials for authentication. It includes a directory service for user management and can be integrated with SSO systems.

Benefits of SSO

  • Improved User Experience: SSO eliminates the need for users to remember and manage multiple passwords, increasing overall usability and lowering sign-in fatigue.
  • Enhanced Security: By centralizing authentication, SSO reduces the risk of phishing and password attacks. It also makes security measures like Multi-Factor Authentication (MFA) easier to implement at the IdP level for all services.
  • Reduced Administrative Overhead: IT administrators can manage user access more efficiently with a single point of authentication, eliminating the need to maintain separate credentials for multiple applications.

Limitations and Considerations

  • Identity Provider Availability: If the identity provider becomes unavailable or compromised, access to all connected services may be affected. High availability, redundancy, and strong security controls are critical.
  • Integration Complexity: SSO requires careful configuration of trust relationships between identity providers and service providers. Misconfigured tokens, improper encryption, or incorrect redirect settings can introduce security risks.

SSO in BuildNinja

BuildNinja supports SSO using OAuth 2.0, allowing teams to authenticate using existing enterprise identity providers instead of managing separate BuildNinja credentials.

Supported Identity Providers

BuildNinja currently supports SSO integration with the following identity providers:

Identity ProviderProtocol
Microsoft (Azure AD)OAuth 2.0
GitHubOAuth 2.0
GitLabOAuth 2.0
GoogleOAuth 2.0
BitbucketOAuth 2.0
note

All identity providers require the BuildNinja instance to be accessible over HTTPS, with redirect URIs correctly registered in the provider’s application configuration.

How SSO Works in BuildNinja

When SSO is enabled and a user signs in to BuildNinja:

  1. The user is redirected to the configured identity provider authentication endpoint.
  2. The identity provider authenticates the user and redirects them back to BuildNinja with an authorization code.
  3. BuildNinja exchanges the authorization code for an access token using the provider’s token endpoint.
  4. The user session is established and access is granted based on assigned permissions.

SSO Configuration in BuildNinja

SSO is configured by a System Administrator from the SettingsSettings provides access to global configuration options that define how the platform behaves system-wide. It allows administrators to manage key settings such as SSO authentication, mail templates, notifier configuratio… tab. Each identity provider requires a Client ID, Client Secret, and Auth URL obtained from the provider's developer or app registration portal.

Multiple identity providers can be configured simultaneously. All enabled providers appear on the BuildNinja sign-in page, allowing users to select their preferred authentication method.

Administrators can enable or disable individual providers without impacting other configured providers or existing user sessions.

Relationship to User Management

SSO in BuildNinja works alongside the existing user management system. When a user signs in via SSO for the first time, BuildNinja requires administrator approvalAs an administrator, you can approve or reject registration requests new users submit. This ensures that only authorized individuals can join and access projects or builds. before granting access.

After approval, user permissions and access levels are governed by BuildNinja’s Role-Based Access Control (RBAC)BuildNinja provides Role-Based Access Control (RBAC) that allows you to control who can view, run, modify, and manage projects and build configurations. system and are managed independently of the identity provider.

Next Steps

  • Manage SSO AuthenticationAs an administrator, configuring Single Sign-On (SSO) authentication is an essential step toward streamlining user access and improving security across multiple applications in your organization.
  • Approve or Reject Registration RequestsAs an administrator, you can approve or reject registration requests new users submit. This ensures that only authorized individuals can join and access projects or builds.
  • System Administrator PermissionsThe System Admin (Super Admin) role provides unrestricted, system-wide access to BuildNinja. This role is intended for platform owners, DevOps administrators, and operations teams responsible for maintaining the overall …
  • Manage Project and Configuration Access (RBAC)BuildNinja provides Role-Based Access Control (RBAC) that allows you to control who can view, run, modify, and manage projects and build configurations.
  • Grant or Revoke Administrator AccessAdministrator access grants users system-wide permissions to manage global settings such as users, agents, authentication, integrations, and licensing.