Authenticate with SAML

Falcon LogScale and Falcon Long Term Repository

Falcon Long Term Repository (FLTR) customers are provisioned through the CrowdStrike Falcon IDP. Additional users can be added through the Falcon company account management.

LogScale organization owners can add LogScale users by creating the user and sharing the sign-up URL. Alternative authentication methods are supported but must be configured by LogScale Support; users will need to login via their configured IDP.

Contact Support for assistance.

One of the preferred methods for handling authentication is to use Security Assertion Markup Language, using the SAML 2.0 protocol. Security Assertion Markup Language (SAML) is an open standard for authentication and authorizing data between applications. LogScale implements the SAML 2.0 Web Browser SSO Profile. This means authentication is delegated to an existing identity provider (IDP) which is responsible for managing user credentials.

Leveraging an existing SSO solution in an organization provides users with a seamless log-on experience: If they are already logged on through their SSO they will not be prompted for credentials. Instead, authentication will be handled transparently by LogScale and the IDP. This means LogScale will never see the credentials of the user since the authentication is delegated to the IDP. You should be able to use LogScale with any SAML 2.0 provider.

The diagram shows how the user, LogScale, and a SAML identity provider interact.

sequenceDiagram participant User participant Browser participant SP as Service Provider (LogScale) participant IdP as Identity Provider User->>Browser: Access LogScale Browser->>SP: Request access SP->>Browser: Redirect to IdP with SAML request Browser->>IdP: Forward SAML request IdP->>Browser: Authentication prompt User->>Browser: Enter credentials Browser->>IdP: Submit credentials IdP->>IdP: Validate credentials IdP->>Browser: Return SAML assertion Browser->>SP: POST SAML assertion to ACS endpoint SP->>SP: Validate SAML assertion SP->>SP: Create session SP->>Browser: Return access token Browser->>User: Display LogScale dashboard

Click on the links below to learn more about the identity providers that LogScale can be configured to use:

SAML authentication methods comparison for LogScale

This table provides a comparison of some of the different SAML authentication methods that can be integrated with LogScale for identity and access management. This table is not exhaustive; LogScale works with SAML regardless of provider.

Feature ADFS Entra ID Duo Security Okta PingFederate Google Workspace Auth0
Description Windows-based authentication software component from Microsoft Microsoft's enterprise cloud-based identity and access management solution Authentication service with Duo Access Gateway (DAG) Cloud-based identity management service Global authentication authority supporting SAML, OAuth, and OpenID Connect Google's suite of cloud productivity and collaboration tools Identity-as-a-service platform that provides authentication, authorization, and user management for applications
Group synchronization Yes, via LDAP attributes Yes, with Object ID mapping - need to find out Yes, via Group Attribute Statements Yes Similar to Entra ID approach Yes, using the Authorizations extension
User Provisioning Manual or automatic via AUTO_CREATE_USER_ON_SUCCESSFUL_LOGIN Manual or automatic with group assignment Manual account creation required Manual assignment in Okta Manual user creation in PingFederate Manual or automatic with configuration Manual user creation in Auth0 dashboard or automatic with AUTO_CREATE_USER_ON_SUCCESSFUL_LOGIN
Certificate Management Standard X.509 certificate Supports certificate rotation with primary and alternative certificates Certificate required from Duo X.509 certificate from Okta Certificate from PingFederate metadata Standard certificate approach Identity Provider Certificate downloaded from Auth0 dashboard
Attribute Mapping Supports mapping LDAP attributes as claims Supports custom attribute mapping for users and groups Basic attribute mapping Supports custom attribute mapping with regex Attribute contracts for mapping Standard attribute mapping Standard SAML attribute mapping supported
Configuration Complexity Moderate - requires Relying Party Trust setup High - multiple steps for app registration, attribute mapping Moderate - requires DAG setup Low to moderate - straightforward app creation Moderate to high - multiple configuration steps Moderate - similar to Azure setup Low to moderate - straightforward app creation
Special Features LDAP integration Detailed group management, multiple domains MFA capabilities Email customization for user invitations Browser SSO with various binding options Integration with Google Workspace User management dashboard and application integration capabilities
Entity ID Format URL to metadata endpoint URL to metadata endpoint URL to metadata endpoint URL to metadata endpoint URL to metadata endpoint URL to metadata endpoint URL to metadata endpoint

Key differences and considerations for the various SAML authentication methods are:

  • ADFS: Best suited for organizations already using Active Directory; requires Windows server

  • Entra ID: Ideal for Microsoft 365 organizations; offers extensive group management

  • Duo Security: Focuses on multi-factor authentication with additional security features

  • Okta: User-friendly setup with extensive application integration options

  • PingFederate: Enterprise-grade solution with comprehensive federation capabilities

  • Google Workspace: Good choice for organizations already using Google's ecosystem

  • Auth0: Cloud-based identity platform with flexible authentication options and user management interface

Configure SAML for LogScale Cloud

Configuring an identity provider (IdP) for your cloud installation enables you to use an existing IdP that you may use with other areas of your company security for authentication.

Before configuring your IdP, LogScale needs to know the specifics about the IDP. Gather the following information, and the details on Requirements for identity provider configuration, and contact Support, and they can work with you to setup your chosen IdP service.

  • LogScale uses email addresses for usernames. Confirm that your IdP will pass an email address. If needed, you can tell LogScale the field name to reference in the SAML payload.

  • Users must be created in LogScale before they can log in. Alternatively, if you have Auto create user on successful login, we will provision the user as soon as they successfully authenticate with the IDP.

  • When a user tries to access LogScale the authentication flow will start by redirecting the user to $IDP_SIGNON_URL. Upon a successful authentication the user will be redirected back to LogScale where a LogScale-specific access token will be issued. For details about the flow see the Wikipedia article about Web Browser SSO Profiles.

  • The redirect back to LogScale is handled by the SAML Assertion Consumer Service endpoint located at http://$YOUR_LOGSCALE_URL/api/v1/saml/acs. The SAML binding used in this interaction is the HTTP POST Binding. While the logon interaction from LogScale to the IDP is done through a HTTP Redirect (GET) Binding.

  • Metadata about LogScale as a SAML Service Provider is available at http://$YOUR_LOGSCALE_URL/api/v1/saml/metadata.

Access token lifecycle

When the SAML-specific authentication flow is finished and successful, a LogScale access token is issued by LogScale itself. Until the token expires, the IDP will not be involved in authentication of the user's requests. The lifetime of the access token is 24 hours.

New user accounts

If LogScale encounters a new user that has been granted access through the IdP it will create the user in the context of LogScale. For this purpose the NameId in the SAML authentication response will be used as the username property of the LogScale user. The recommended username is the email.

url
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">Username</saml:NameID>

By default, the user has no rights. So unless a user is otherwise granted access rights, they will not be able to do anything besides see an empty list of repositories. You can use SAML roles to control access. Otherwise, the user needs to be added explicitly as a member or admin to a repo/view to be able to access it. For information about how to manage user permissions and groups, see Manage Users and Permissions.

Log in with SAML authentication

When SAML-based authentication has been enabled, users must enter their corporate email address into the Single sign-on box from the login screen.

Users must use the enterprise login route, even if you have configured login through a service supported natively by LogScale (i.e. Google, Github or Bitbucket).

Note

Falcon Long Term Repository (FLTR) customers sign in with their Falcon login. If you want to setup your corporate IDP solution instead, contact Support.

Troubleshoot SAML Authentication

When troubleshooting SAML authentication issues, first verify that the basic configuration is correct:

  • Verify that the PUBLIC_URL matches the URL users use to access LogScale.

  • Confirm that the IdP entity ID and sign-on URL are correctly configured.

  • Check that the certificate is in PEM format and accessible to LogScale.

To collect logs that are available in the humio repository make sure that the SAML_DEBUG environment variable is set to true.

Common error messages and their solutions

Problem Solution
SAML Response validation failed This typically indicates a certificate mismatch or incorrect IdP configuration. Verify that the certificate provided to LogScale matches the one used by your IdP.
User authenticated but has no permissions Check role mappings
SAML Response validation failed Certificate or configuration mismatch
Redirect URI mismatch Verify PUBLIC_URL configuration
Clock skew too large Check time synchronization between IdP and LogScale
Missing attributes in SAML assertion Verify IdP configuration