This manual is intended for administrators, system integrators, and support personnel who plan, configure, or maintain authentication for the platform. It provides an overview of the authentication methods supported by the platform. It is intended for administrators, system integrators, and support personnel who are planning an authentication strategy, evaluating available authentication options, or supporting existing authentication implementations.
This chapter explains how authentication works at a high level, introduces the core authentication concepts and components used by , and describes each authentication method, including when it is typically used and how it integrates with the platform. This chapter does not include configuration or setup instructions. Detailed architecture, configuration, and setup guidance for all authentication methods is provided in the following chapter.
This manual assumes that you are familiar with basic authentication and identity concepts, such as usernames and passwords, directory services, and single sign‑on. Familiarity with Active Directory, LDAP, and common identity provider workflows is recommended.
If you are not familiar with these technologies, you might need to work with your organization’s directory services, identity management, or security administrators to complete the tasks described in this manual.
Overview and Core Concepts
Authentication controls how users and systems prove their identity before gaining access to the platform. It is a foundational security capability that ensures access is granted only to verified identities and that authentication decisions can be consistently enforced across different access methods and integrations.
This guide describes the authentication mechanisms supported by the platform, how authentication decisions are evaluated, and how different authentication methods can be combined to meet organizational security and operational requirements. It is intended for administrators, architects, and support personnel who are responsible for planning, implementing, or maintaining authentication.
How Authentication Is Used In Skylar One
In Skylar One, authentication is the process of validating a user’s or system’s credentials against a defined authentication source. Authentication may be performed locally or delegated to an external identity provider, depending on how the environment is configured.
Authentication determines whether an identity is valid. Once authenticated, access is governed by authorization and policy controls, which are addressed separately from authentication.
Authentication vs. Authorization
Authentication and authorization are related but distinct aspects of access control. Understanding the difference between them is essential when designing, configuring, or troubleshooting access to the platform.
Authentication is the process of verifying the identity of a user or system. It answers the question: Who is attempting to access the system? Authentication validates credentials such as a username and password, a smart card certificate, or a token issued by an external identity provider. If authentication succeeds, the identity is considered trusted; if it fails, access is denied immediately.
Authorization determines what an authenticated identity is allowed to do. It answers the question: What actions is this authenticated user or system permitted to perform? Authorization controls access to features, resources, and data based on roles, policies, or permissions associated with the authenticated identity.
In practice, authentication always occurs before authorization. A user or system must first successfully authenticate before any authorization rules are evaluated. While authentication establishes identity, authorization governs access.
How Authentication Works
Authentication follows a consistent evaluation model regardless of the specific method being used. Understanding this high‑level flow helps administrators design authentication configurations and diagnose authentication failures.
High‑Level Authentication Flow
At a high level, authentication proceeds through the following stages:
- A user or system presents credentials.
- The platform evaluates the credentials using one or more configured authentication mechanisms.
- If authentication succeeds, the identity is established and access proceeds.
- If authentication fails, access is denied and the authentication attempt ends.
The exact steps involved depend on how authentication is configured, but the overall decision flow remains consistent.
Local Authentication vs. External Identity Providers (IdP)
Skylar One supports both local authentication and authentication through external identity providers.
Local authentication validates credentials that are managed directly within the platform. This approach is often used in small or isolated environments, for initial access, or for service and emergency accounts.
External identity provider (IdP) authentication delegates credential validation to systems such as directory services or single sign‑on providers. This approach allows organizations to centralize identity management, enforce consistent security policies, and integrate authentication with existing enterprise systems.
Organizations commonly use a combination of local and external authentication depending on operational and security requirements.
Authentication Decision Points
Authentication decisions are made by evaluating configured authentication components in a defined order. These components determine which authentication methods are attempted and how credential validation is performed. While the specific configuration is addressed later in this guide, understanding that authentication is evaluated through ordered decision points is key to understanding authentication behavior.
Authentication Building Blocks
Authentication behavior is defined using a small set of core components. These components work together to determine how authentication attempts are processed.
Authentication Profiles Overview
Authentication profiles define how authentication attempts are evaluated. A profile determines which authentication mechanisms are attempted and the order in which they are applied. Profiles allow authentication behavior to be tailored for different users, access paths, or integration scenarios.
Authentication Resources Overview
Authentication resources define how the platform communicates with a specific authentication source, such as a directory service or external identity provider. A resource contains the connection and integration details required to validate credentials against that source.
Relationship Between Profiles and Resources
Authentication profiles reference one or more authentication resources. During authentication, the platform evaluates the resources associated with a profile in sequence until authentication succeeds or all options are exhausted. This separation allows authentication behavior to be reused, extended, and modified without redefining individual integrations.
For more information, see the
Authentication Methods at a Glance
Skylar One supports multiple authentication methods to address a wide range of deployment models and security requirements. Each method differs in how credentials are validated, how identity is managed, and how access is enforced.
The following sections provide a high‑level overview of each supported authentication method. Detailed configuration, troubleshooting, and escalation guidance is provided in later chapters.
Local Authentication
Local authentication validates credentials that are created and managed directly within Skylar One. User accounts and credentials are stored locally and authenticated without relying on external identity systems.
Local authentication is typically used for initial system access, service accounts, or environments where external identity integration is not required. It is also commonly retained as a fallback authentication method for administrative or recovery purposes.
Directory‑Based Authentication (Active Directory and LDAP)
Directory‑based authentication allows users to authenticate using credentials managed in an external directory service, such as Microsoft Active Directory or an LDAP‑compliant directory.
In this model, Skylar One delegates credential validation to the directory service while maintaining control over user accounts, policies, and access within the platform. Directory‑based authentication is widely used in enterprise environments to centralize identity management and enforce consistent authentication policies.
Active Directory is Microsoft's implementation of LDAP. Although Active Directory includes some platform-specific features that differ from a standard LDAP implementation, the terminology used in Skylar One is also used by LDAP and Active Directory.
LDAP (Lightweight Directory Access Protocol) is an application protocol for directory services that runs over TCP/IP. An LDAP directory server provides system administrators with a centralized tool for authenticating users and managing user access on a network and the devices in the network.
For more information, see the
Single Sign‑On (SSO)
SSO (Single Sign-On) allows a user to provide credentials only once and then be authenticated on multiple (or all, depending on configuration) applications. Skylar One uses SAML (Security Assertion Markup Language) version 2.0 to exchange information with an IdP (identity provider). An IdP stores information about users in a database, frequently LDAP or Active Directory. In the SAML model, Skylar One is considered a service provider.
SSO is commonly used in environments that require centralized authentication, improved user experience, and integration with corporate identity platforms. SSO can also be combined with additional authentication controls, such as multi‑factor authentication, depending on the IdP configuration.
For more information, see the
SAML Authentication
SAML authentication is a standards‑based form of single sign‑on that uses Security Assertion Markup Language (SAML) to exchange authentication information between an identity provider and Skylar One.
In a SAML‑based integration, the identity provider authenticates the user and issues a signed assertion that Skylar One uses to establish the user’s identity. SAML authentication is typically used in enterprise or regulated environments where standards‑based federation is required or where an existing SAML‑enabled identity provider is already in place.
Multi‑Factor Authentication (MFA)
Multi-factor authentication adds an additional step to authentication. Users still must provide a user name and password, but multi-factor authentication requires an additional piece of information from the user.
Currently, Skylar One supports multi-factor authentication from RSA SecurID. RSA SecurID generates a unique token delivered to a key fob or to an email address or mobile phone.
If you configure Skylar One to use multi-factor authentication, after the user provides a user name and password, Skylar One prompts the user to enter the token from RSA SecurID.
In Skylar One, MFA is commonly used to protect privileged access, administrative accounts, or externally accessible login paths. MFA can be used alongside other authentication methods, such as local authentication, directory‑based authentication, or SSO.
For more information, see the
CAC Authentication
CAC authentication uses smart cards and certificate‑based credentials to authenticate users. This method relies on physical authentication factors and cryptographic certificates to establish identity.
CAC authentication is typically used in high‑security or regulated environments where strong, hardware‑based authentication is required. It is often deployed alongside directory or identity management systems to meet compliance and security standards.
For more information, see the
API Authentication (REST and Token‑Based Access)
API authentication allows systems, scripts, and integrations to authenticate programmatically when interacting with ScienceLogic through RESTful APIs.
Rather than authenticating as an interactive user, API authentication uses credentials such as tokens or keys to grant controlled access to specific API operations. This approach is commonly used for automation, integrations with external systems, and service‑to‑service communication, where interactive login is not appropriate.
In Skylar One 12.5.20 and later, you can assign a "Read-only API User" user policy to any user that you want to have read-only API access.
Choosing an Authentication Method
Organizations often use a combination of authentication methods to meet different access requirements. Interactive users, administrators, services, and integrations may each use different authentication approaches depending on security needs and operational constraints.
Each authentication method described above is covered in detail in its own chapter, including configuration steps, troubleshooting guidance, and escalation considerations.