Applicability

Splunk Observability Cloud Organisations configured with SAML SSO Existing users with local authentication Multiple organisations using the same SAML identity provider (IdP) and email domain

Description

An administrator enabled SAML federation for an email domain after a user already existed with local authentication.

The administrator needed to determine whether the same email identity could use both local login and SAML SSO, whether local authentication could be removed without removing the user’s SAML access, and whether the same approach could be used in multiple organisations connected to the same IdP.

No product error message was reported.

Investigation

Confirm the following before changing authentication access:

 

1. Confirm that SAML SSO is configured and functioning for the organisation.
2. Confirm that the IdP assertion identifies the user with the same email address used by the existing Splunk Observability Cloud user.
3. Confirm whether local login remains enabled for the organisation.
4. Test SAML sign-in with a non-production or designated test user.
5. Confirm that the user retains the expected organisation membership and role after SAML sign-in.
6. Confirm that an emergency administrative access method remains available before removing any local credentials.
   
   

Important: The email address or other configured SAML identifier must consistently match the existing user identity. Differences in email address, case handling, or identifier mapping can result in unexpected user matching or access behaviour.

Resolution

Questions and answers:

Q1. Can a user authenticate using both local login and SAML login?

 

Local authentication and SAML SSO can operate in parallel if local login remains enabled for the organisation.

 

When SAML is enabled, a user who needs to sign in with local credentials must use the supported local-login or SSO-bypass sign-in path instead of the normal SSO sign-in flow.

 

SAML SSO should be the primary authentication method for standard users. Local authentication should only be retained where there is a defined operational requirement, such as a securely managed emergency administrator account.

 

Q2. Can a separate local-login account be created after the user has been created through SAML?

Maintaining more than one authentication method for the same standard user is not recommended.

The behaviour of the user interface when attempting to create local credentials for an identity that already exists through SAML must be confirmed before making this change. A single SAML-managed identity provides clearer identity lifecycle management and reduces the risk of unexpected access behaviour.

 

Q3. Can only the local-login credentials be removed while retaining the SAML-based user?

 

Local authentication should be removed only after SAML sign-in has been verified.

 

The removal process must preserve the user’s SAML-based access, organisation membership, roles, and associated resources. Administrators should use the supported Splunk Observability Cloud user-management process or engage Support to remove the local authentication method.

 

Administrators must not use procedures intended for Splunk Enterprise, such as modifying a local passwd file, unless explicitly directed by the relevant product documentation or Support. Splunk Observability Cloud is a SaaS service and its supported user-management workflow may differ.

 

Q4. Can the same process be performed in two organisations using the same IdP, domain, and user information?

 

The process can be used in multiple organisations when each organisation independently validates SAML identity matching and user access.

 

The shared IdP and email domain do not, by themselves, create an issue. Each organisation should confirm that the SAML identifier, such as the email address, matches the intended user identity and that the expected organisation membership and permissions are retained after SAML sign-in.

General Guidelines:

Use SAML SSO as the primary authentication method

SAML SSO should be the primary login method for standard users. This provides centralised identity lifecycle management through the organisation’s IdP.

Maintaining both local and SAML authentication for the same standard user is not recommended unless there is a defined operational requirement.

 

Access local authentication when SAML is enabled

Local authentication and SAML SSO can operate in parallel when local login has not been disabled for the organisation.

A user requiring local authentication must use the supported local-login or SSO-bypass sign-in path rather than the standard SSO sign-in flow. The administrator should obtain and validate the current supported local-login path from Splunk Observability Cloud documentation or Support before relying on it for operational access.

 

Do not create duplicate authentication methods for standard users

Creating a separate local-login account after a user has been created through SAML is not recommended.

The supported user-interface behaviour for creating a second authentication method for the same identity must be validated before attempting this configuration. A single SAML-managed identity should be used for normal user access.

 

Remove local credentials only after SAML access is verified

Before removing local authentication:

 

1. Verify successful SAML sign-in for the affected user.
2. Verify the user’s organisation membership, role, and permissions.
3. Confirm that at least one administrator retains emergency access.
4. Record the existing user and authentication configuration for rollback.
5. Use the supported Splunk Observability Cloud user-management process, or engage Support, to remove only the local authentication method while preserving the user’s SAML-based access.

 

The local credential removal process must not delete the user’s organisation membership, role assignments, dashboards, detectors, or other user-associated resources.

 

Use the same approach in multiple organisations

The same migration approach can be used for multiple Splunk Observability Cloud organisations that share the same IdP, domain, and user information, provided that each organisation independently meets these conditions:

 

• The SAML identifier matches the intended local user identity.
• SAML sign-in is tested successfully in that organisation.
• User membership and role mappings are verified.
• An emergency administrator access method exists.
• A rollback plan is available before removing local authentication.

 

Changes should be tested in one organisation first, then repeated in the remaining organisations only after successful validation.

 

Recommended practice

Use a dedicated, securely managed emergency administrator account only where local access is operationally required. Standard users should authenticate through SAML SSO.

 

Revision History

Revision	Publish Date	Comments
1.0	20-Oct-2026	Initial Release