Network Management
Configure PingFederate SSO for SolarWinds Platform
This article describes how to configure PingFederate as the SAML Identity Provider (IdP) for SolarWinds Platform and how to validate individual-account and group-based SAML authorization. The most important group-authorization requirement is that the value emitted by PingFederate in the `OrionGroups` claim must match the SAML group account name configured in SolarWinds exactly. Matching the underlying Active Directory group is not sufficient if PingFederate sends a different representation, such as a full distinguished name (DN) instead of a short group name.
First published date
Last published date
Overview
SolarWinds is the SAML Service Provider (SP). PingFederate is the SAML Identity Provider (IdP).
The expected flow is:
1. The user starts SSO from SolarWinds.
2. SolarWinds sends an AuthnRequest to the PingFederate SSO endpoint.
3. PingFederate authenticates the user and creates a SAML assertion.
4. PingFederate returns the assertion to SolarWinds using HTTP POST.
5. SolarWinds matches the NameID to an individual SAML account and/or matches `OrionGroups` values to SAML group accounts.
Prerequisites
Collect the following values before configuring either system:
- SolarWinds external URL/FQDN
- SolarWinds SP Entity ID/Audience URI
- SolarWinds ACS URL
- PingFederate IdP Entity ID/Issuer
- PingFederate SP-initiated SSO endpoint
- PingFederate signing certificate
- User identifier to use for NameID/SAML subject
- Group attribute source and expected group-value format
Use the same SolarWinds hostname consistently in the external URL, SP Entity ID, Audience, ACS URL, and PingFederate partner connection. Do not mix an internal FQDN and a public alias unless both are intentionally configured as separate supported endpoints.
Product section
Cause
Group-based SAML authorization fails when one or more of the following conditions apply:
1. PingFederate does not include an attribute named `OrionGroups` in the SAML assertion.
2. `OrionGroups` is defined in the PingFederate attribute contract but is not fulfilled with the user’s actual group membership.
3. The group value sent by PingFederate does not exactly match the SAML group account name in SolarWinds.
4. The affected user is not assigned to the PingFederate application or is excluded by a group filter or policy.
5. The SAML response is not returned to the SolarWinds ACS endpoint by HTTP POST.
6. The SolarWinds SSO Target URL points to an IdP endpoint that does not accept the SP-initiated AuthnRequest.
Resolution
SolarWinds configuration
1. Configure the external URL
SolarWinds configuration:
1. Open the SAML configuration page.
2. Set the SolarWinds external URL to the hostname users will use for SSO.
3. Save the configuration.
Example:
https://<SolarWinds-FQDN>
2. Configure the Identity Provider
In the SolarWinds SAML configuration, add or edit the PingFederate IdP and configure:
- IdP Entity ID/Issuer
- IdP signing certificate
- SSO Target URL
The SSO Target URL must be the PingFederate endpoint that accepts SolarWinds SP-initiated SAML AuthnRequests. Use the exact endpoint supplied by the PingFederate administrator. SolarWinds does not require the URL path to contain `idp` or `sp`; it uses the configured value as the IdP destination.
Example placeholder:
https://<PingFederate-FQDN>/<SP-initiated-SSO-endpoint>
Do not assume that a manually tested IdP-initiated launch URL is automatically the correct endpoint for SolarWinds SP-initiated SSO. Validate the endpoint with the PingFederate administrator.
3. Configure individual SAML accounts
For each individual SAML account:
1. Open **Manage Accounts**.
2. Create or edit the individual SAML account.
3. Set the account name to exactly match the NameID/SAML subject emitted by PingFederate.
4. Assign the required roles, permissions, views, and account restrictions.
The comparison is exact and can be case- and format-sensitive.
4. Configure SAML group accounts
For each group-based SAML account:
1. Open Manage Accounts > SAML Groups.
2. Select Add New Group Account.
3. Enter the exact group value that PingFederate will send in `OrionGroups`.
4. Enable the account.
5. Assign the required roles, permissions, views, and account restrictions.
6. Save the group account.
If PingFederate sends a short group name, configure the short name in SolarWinds. If PingFederate sends a full DN, configure the full DN in SolarWinds.
Do not use one format in PingFederate and another in SolarWinds.
5. Verify the group claim name
Verify that the SolarWinds group-claim setting is:
OrionGroups
This is the claim/attribute name, not the name of a specific group.
*****************************
PingFederate configuration
1. Create or edit the SolarWinds SP connection
In PingFederate:
1. Open 'SP Connections'.
2. Create or edit the SolarWinds connection.
3. Select SAML 2.0.
4. Set the connection role to SP.
5. Enable Browser SSO.
6. Enable SP-initiated SSO.
7. Enable IdP-initiated SSO only if that flow is required.
Use a partner Entity ID and Base URL that match the SolarWinds SP Entity ID and external URL.
2. Configure Browser SSO and the ACS endpoint
Configure the SolarWinds assertion consumer service as:
https://<SolarWinds-FQDN>/Orion/SamlLogin.aspx
Set the ACS binding to **HTTP POST**. The SAML response must be posted to the ACS endpoint with a `SAMLResponse` form value.
Recommended settings:
- SP-initiated SSO: enabled
- ACS binding: POST enabled
- Assertion signing: enabled according to the SolarWinds configuration
- SLO: optional and not required for initial SSO testing
3. Configure the attribute contract
Under the PingFederate connection’s assertion creation settings, add these outgoing attributes as applicable:
SAML_SUBJECT
OrionGroups
`SAML_SUBJECT` identifies the user. `OrionGroups` carries the group values used by SolarWinds group authorization.
The attribute name must be spelled exactly as `OrionGroups`.
4. Configure attribute fulfillment
Under 'Attribute Contract Fulfillment':
- Map `SAML_SUBJECT` to the user identifier used by SolarWinds.
- Map `OrionGroups` to the user’s actual group membership source.
- Confirm the group source returns the expected group format.
- Confirm the affected user is assigned to the PingFederate application.
- Confirm group filters and policy rules do not remove the expected group.
- Confirm multi-valued group membership is emitted as usable SAML attribute values.
Adding `OrionGroups` to the attribute contract alone does not prove the assertion contains the claim. Fulfillment and policy evaluation must also be configured.
Validation procedure
Test 1: Individual account
1. Open a private browser session.
2. Start SSO from the SolarWinds login page.
3. Authenticate with a known-working individual SAML account.
4. Confirm the login succeeds.
5. Record the NameID/SAML subject and compare it with the SolarWinds individual account name.
Test 2: Group account
1. Select a user who should receive access through a SAML group.
2. Confirm the user is a member of the group in the PingFederate source.
3. Open a new private browser session.
4. Start a new SSO attempt; do not refresh or reuse a previous response.
5. Capture the assertion with SAML-tracer or browser Developer Tools.
6. Confirm the assertion contains an attribute named `OrionGroups`.
7. Record the exact value for the expected group.
8. Compare that value character-for-character with the SolarWinds SAML group account name.
9. Confirm the login succeeds and the user receives the intended group permissions.
SAML-tracer checks
The successful flow should include:
1. A request from SolarWinds to the PingFederate SSO endpoint containing the SAML AuthnRequest.
2. PingFederate authentication and assertion creation.
3. A request to the SolarWinds ACS URL:
https://<SolarWinds-FQDN>/Orion/SamlLogin.aspx
4. The ACS request using HTTP POST.
5. A form field named `SAMLResponse`.
6. An assertion containing `SAML_SUBJECT` and, for group-based authorization, `OrionGroups`.
Do not use browser Back, refresh, or an old exported assertion while testing. Reusing an assertion can produce `The SAML assertion is being replayed` and obscure the original failure.
Log interpretation
Missing group claim
Groups claim 'OrionGroups' is missing.
Check PingFederate attribute contract, attribute fulfillment, group membership source, group filters, and application assignment.
--------------------
Group value mismatch
Unable to authorize user <user> with claim groups '<values>'.
No matching SAML account or group was found.
The claim is present, but no SolarWinds individual account or SAML group matches the received value. Compare the exact values, including DN prefixes, punctuation, case, and spacing.
--------------------
Non-POST ACS request
The message is not an HTTP POST.
Check the PingFederate ACS binding and confirm that the response is posted to `/Orion/SamlLogin.aspx` with `SAMLResponse`.
--------------------
Assertion replay
The SAML assertion is being replayed.
Start a new private browser session and repeat the test without refresh or Back navigation.
--------------------
Responder authentication failure
Correlate the timestamp with PingFederate authentication, policy, and application-assignment logs. This message alone does not identify a SolarWinds group-name mismatch.
--------------------
Case-specific resolution pattern
In the investigated environment, PingFederate emitted the group as a full group CN/DN value. A second SolarWinds SAML group account was added using the full value so it matched the assertion. The environment retained both a short-name group entry and a full-value group entry during testing.
Deleting individual SAML accounts is not a general requirement for enabling group authentication. Remove duplicate or test accounts only when their presence creates an intentional authorization conflict or when the account is no longer required.
*Example: SolarWinds SAML group accounts configured with both a short group name and a full CN/DN value for comparison during testing.