Enable SAML for MFA
Set up multi-factor authentication (MFA) in SEM
The SEM web console uses the SAML 2.0 (Security Assertion Markup Language) protocol to integrate with various identity providers, enabling Single Sign-On (SSO) authentication. This enables integration with authentication methods such as 2FA, passwordless logins, or passkeys for the web console.
Centralized management of user identities allows centralized control and management of user identities across the organization. SAML is widely used in enterprise environments where organizations want to manage user identities centrally and provide seamless access to various applications, such as cloud services, intranet resources, and third-party applications.
SAML can be used to replace Kerberos SSO in situations where the Kerberos setup is not a viable solution.
How SAML works in SEM
SAML is an XML-based protocol that enables single sign-on (SSO) by allowing an identity provider (IdP) to authenticate users and securely transmit authentication and authorization data to a service provider (SP).
SEM supports two SAML authentication process flows: SP-initiated flow and IdP-initiated flow.
SP-initiated flow
This is the main scenario, with SEM as the initiator of the SAML flow. With SAML properly configured, users will go to the SEM login page and click Login with SSO.
This scenario is more secure because it involves two-way verification: the SAML request generated by SEM is verified by the IdP, and the SAML response generated by the IdP is verified by SEM.
-
The user initiates the login process by interacting with the SP.
-
The SP generates a SAML authentication request.
-
The SP signs the generated SAML request to ensure request integrity and authenticity using its request signing private key.
-
The SP redirects the user to the IdP with the signed request using user’s browser.
-
The IdP validates the signed request (if required) using SP’s request signing public key/certificate.
-
The user enters their credentials (or is already authenticated via single sign-on if they are logged in).
-
The IdP generates a SAML assertion containing user information after successful user authentication.
-
To ensure the SAML assertion's integrity and authenticity, the IdP signs the SAML assertion with its private key. This ensures that the assertion has not been tampered with during transmission.
-
(Optional): If assertion encryption is enabled, the IdP encrypts the signed SAML assertion using the SP’s public key/certificate to ensure confidentiality.
-
The IdP posts the SAML response containing signed and optionally encrypted assertion of the authenticated user back to the SP.
-
(Optional): If the assertion/response was encrypted, the SP uses its assertion encryption private key to decrypt the SAML assertion/response.
-
The SP validates the SAML assertion, which includes:
-
The SP uses the IdP’s public key/certificate to verify the signature on the SAML assertion to confirm that it was issued by a trusted IdP and has not been tampered with.
-
The SP also validates other aspects of the assertion, such as expiration, audience, etc.
-
-
The data in SAML response/assertion is used to create/update the SAML user in SEM and also assign it to the proper SEM role.
-
The user is authenticated in SEM and redirected to application main screen where they can start using SEM according to resolved user role.
IdP-initiated Flow
In this scenario, SAML authentication is initiated by the IdP. It provides a more seamless login experience from the corporate library of applications, such as MSFT My Apps.
This scenario is generally less secure than the first scenario because it lacks the two-way verification the first scenario offers.
Post SAML authentication in SEM
After SAML authentication is fully complete (from both IdP and SP standpoints), SEM extracts user data from received SAML response to create a SAML user in SEM and also to assign it with a proper SEM role based on the received groups (similar to what SEM does for LDAP auth). See Configure role to group mapping.
In SEM, user identity for SAML users is determined by the username. When a SAML user is authenticated, SEM receives their NameID and uses it to match the existing external SAML user in SEM.
-
If the user is matched, SEM refreshes the user attributes, such as first name, last name, email, and roles, with the values received from the SAML assertion and updates the last login date.
-
If the user is not matched by the received
NameID, SEM creates a new SAML user.
Who can manage and use SAML in SEM
Only the SEM admin user can configure and manage SAML.
Once SAML SSO is properly configured, SAML authentication can be used by all SEM user roles (except those who cannot log in to the Web console).
How to manage and use SAML in SEM
Configuring SAML authentication involves setting up two parties: the service provider (SP), such as SEM, and the identity provider (IdP), such as Azure AD (Entra ID). Both parties need to be aware of each other's specific configurations to ensure proper communication and authentication.
-
Go to Settings > Authentication > SAML SSO tab.
-
Determine whether the settings are configured.
-
If not configured, click Configure SAML SSO.
-
Complete the SAML configuration form, using the tooltips and hints to view additional information, if needed.
SolarWinds recommends configuring the IdP first, using the settings provided by SEM.
Configure the identity provider party using service provider settings
Enterprise admin rights and the following settings are needed to configure a new application or client in your IdP.
Service provider settings to copy/download from SEM for IdP configuration
| Field | Description & Instructions | Required |
|---|---|---|
| Entity ID (Audience URI) |
|
Yes |
| Assertion Consumer Service URL (ACS URL or SSO Service URL) |
|
Yes |
| Sign SAML Requests |
Enables SAML request signing for the SAML requests generated by SEM. The request signature is verified by the IdP to ensure the request's authenticity and integrity. To enable and use this setting, the user needs to:
|
No |
| Encrypt SAML Assertions |
Enables SAML assertion encryption/decryption for the SAML response generated by the IdP. The assertions are encrypted by the IdP using the public key/certificate and decrypted by SEM using the corresponding private key. To enable and use this setting, the user needs to:
|
The certificates generated for Sign SAML Requests and Encrypt SAML Assertions have expiration dates, which can be viewed once the certificate is generated. When a certificate is near expiration or expired, it should be regenerated and reimported to the IdP for proper SAML functionality.
By default, newly generated certificates are valid for:
-
Request Signing - 365 days
-
Assertion Encryption - 730 days
Important: After the certificate is regenerated, the old key-certificate pair will be replaced with the new one, meaning the previous pair will be lost and no longer work.
After configuring the IdP’s application with the copied SP settings above, configure the attributes and claims mapping in the IdP’s application settings. By default, SEM expects the following user claims in the received SAML attributes/asserts, which can be configured internally.
SAML claims expected by SEM
| Description | Expected claim names (case insensitive, first preferred) | Required |
|---|---|---|
| Authority/groups |
|
Yes |
|
No | |
| First name |
|
No |
| Last name |
|
No |
It is better to setup filtering for the groups claim (for example, using name prefix SEM_) to expose only SEM relevant groups. This exposes less information and also saves the bandwidth.
Configure the service provider (SEM) party with identity provider settings
To proceed with SEM configuration, obtain specific settings from the IdP’s.
Configure IdP settings in SEM by uploading the IdP’s SAML metadata file
The SAML IdP metadata file contains the essential IdP configurations, such as IDs, endpoints, and certificates, needed for establishing SAML authentication when imported by the SP.
The metadata file approach is simple and flexible, minimizing the need to manually copy certificates, identifiers, and endpoints. SolarWinds recommends this approach over manual configuration.
SEM SAML settings to enter when configuring IdP from the metadata file
| Description | Expected claim names (case insensitive, first preferred) | Required | Constraints |
|---|---|---|---|
| Identity provider Metadata File |
Upload the IdP metadata XML file that contains the necessary settings for the SP to configure SAML authentication. This file can be obtained from the IdP settings and may be named Federation Metadata XML or SAML 2.0 Identity Provider Metadata, depending on the IdP vendor. |
Yes (if settings are not filled manually) |
|
-
Obtain and upload the SAML metadata file:
-
Obtain the SAML metadata file from the IdP’s application settings.
-
Upload the metadata file into the SEM SAML IdP’s settings.
-
-
Manually enter SAML settings obtained from the IdP:
If you prefer, you can manually enter the IdP’s application settings into SEM.
SEM SAML settings to manually enter when configuring IdP
Field Description & Instructions Required Constraints Entity ID (Issuer URI) IdP entity unique ID, obtained from the Entity ID (Microsoft Entra Identifier) field in the IdP application settings.
Yes - Max length 1024 characters
- Valid URI or URN (not necessary reachable location, can be just unique identifier)
- Must use http, https or urn scheme
- For urn scheme, must follow the general URN pattern, to at least contain 2 parts:
urn:<namespace>:<identifier>Single Sign On Service URL (SSO Target URL) IdP SSO URL, obtained from the Single Sign On Service URL (Login URL) field in the IdP application settings. Yes - Max length 1024 characters
- Valid URI (reachable location)
- Must have https scheme
- Must have host part
- Must not have query parameters
Signature Verification X509 Certificate IdP signing certificate in PEM format, obtained from the IdP settings. Should be opened with a text editor, and copied and pasted the contents of it into this field. In the IdP settings, it is typically named Signing Certificate (Base64). Yes - Valid base64 or pem content
- Length <= 16384 characters
- Decoded PEM is X509 certificate
-
Obtain the Entity ID (Microsoft Entra Identifier), SSO Target URL (Login URL) and Signature Verification X509 Certificate (Certificate Base64) from the IdP’s application settings.
-
Manually enter the necessary values.
Configure role to group mapping
This mapping allows you to determine SEM roles for SAML users. For example: if IdP is configured to expose user groups in a groups claim, and user is a part of the IdP group SEM_ADMINS, and the group SEM_ADMINS is mapped as the Admin role, then the authenticated user becomes an SEM administrator. SAML users without matching groups are rejected during SAML authentication. This mapping can also contain group identifiers instead of group names.
The example below contains a mapping of group ID instead of group name, because Entra ID exposes group IDs instead of group names.
| Field | Description & Instructions | Required | Constraints |
|---|---|---|---|
| (Admin|Auditor|Guest|Monitor) role |
Contains the mapping of SEM role to SAML group. The value entered by user should be an IdP’s group name or identifier, that when found in SAML group claim, should be resolved to the corresponding SEM role. |
Yes |
|
If the groups claim is not configured or sent in the SAML response, or does not match any mapped SEM roles, the user will be rejected from authenticating in SEM, even if SAML authentication succeeds, as SEM will not be able to identify the user's role. You can check how to configure groups claim in the IdP and see other claims SEM expects in the Configure the identity provider party using service provider settings section.
Users in SEM can be assigned to only one role. If a SAML user is part of multiple groups mapped to different SEM roles, the highest priority SEM role is assigned from the list of mapped roles. For example:
If a user is part of group 1 (mapped to the admin role) and group 2 (mapped to the monitor role), the user will be assigned the SEM admin role.
The role priority order is as follows (from highest to lowest priority):
-
Admin
-
Auditor
-
Monitor
-
Guest
(Optional) Configure Advanced Settings
Advanced settings allow you to configure certain SAML behavior, like forcing reauthentication of every SAML user on every next SAML login, or, tolerating the specified clock skew between the SP and IdP.
Enable SAML and prefer it over Kerberos SSO
After all settings are configured, click Save on the bottom right corner of the form. If the settings were previously not saved and enabled, you will be prompted to enable SAML SSO.
If you do not enable settings in this dialog, you can do it later by enabling the switch on the top of the SAML SSO form.
After SAML SSO is enabled, it can be used as the SSO authentication option when Log in with SSO is pressed on the login screen.
Having both Kerberos SSO and SAML SSO enabled creates a conflict regarding which flow is triggered when the Log in with SSO button is clicked.
By default, if both SSO methods are enabled, the Log in with SSO button will trigger the older Kerberos SSO flow.
If only one SSO method is configured, this setting has no effect.
To change the SSO authentication method to use SAML SSO, go to Settings > Authentication > Login Options and enable Prefer SAML SSO.
Test and use SAML to authenticate
To confirm SAML SSO is configured correctly, enabled, and working in SEM, either log out and return to the login screen, or open a new incognito tab in the browser.
Click Log in with SSO and confirm you are redirected to the IdP’s login page, indicating the SP-initiated SAML authentication flow was triggered.
It is highly recommended to test if SAML SSO works first before disabling local users or enabling SSO-only mode.
Delete SAML settings
If SAML authentication is no longer needed, go to the SAML SSO form and click Delete at the bottom of the form. Once you confirm you want to delete the settings, the settings are removed from SEM.
SAML user management
Successful SAML authentication creates or updates SAML users internally in SEM, as described in the Post SAML authentication in SEM section.
SEM administrators can list, filter, and view details of SAML users, and delete users.
Supported identity providers
-
Azure AD (Entra ID) for cloud-based identity management
-
ADFS (Active Directory Federation Services) for on-premises identity management
-
Keycloak for open-source, on-premises identity management
There is no requirement to use only the mentioned identity providers. SAML in SEM is not restricted to a specific identity provider vendor and can also work with other identity providers, as long as they support SAML 2.0.
Troubleshoot SAML
Proper SAML setup can be challenging for inexperienced users, because it involves cross configuration of both parties (SP and IdP) and optional setup of asymmetric cryptography (private and public key pairs) that are used for signing and encryption of SAML request and response/assertions.
There can be many points of failures, typically related to misconfiguration of one or another party. The first thing to figure out: where the error happens.
If error happens on the IdP login page, then SEM will not provide any detailed information about the error, and IdP is responsible for providing error messages or error codes to the user, that will help to troubleshoot the problem or fix the configuration.
On another hand, if error happens on the SEM side (when IdP responded to SEM), SEM will provide the descriptive error message, on why it’s failed to validate SAML response from IdP or to create SAML user.
IdP logs
If error is displayed on the IdP login page, and issue is not clear, customer can use IdP logs to troubleshoot the problem.
SEM error messages
If error happens during SAML configuration, the problematic field will be highlighted and the error message will appear near this field. If error is not expected, try the operation again. If it does not help, check the Network logs and inspect the failed Request’s response for more detailed reason of failure.
If error happens during SAML authentication, SEM will display using server’s internal error page. Usually this error page will contain an error code (it gives a hint that for example problem is with decryption) and error message.
SEM events
SEM emits the following events on both successful and failed SAML authentication (only after SAML response reaches the SEM party):
SEM logs
SAML follows SEM standard way of logging authentication logs, capturing successful and failed attempts. Log level can also be increased to troubleshoot particular problems with SAML, like problems with settings or the authentication itself:
Log levels to adjust
com.solarwinds.lem.web.security.saml=14 com.solarwinds.lem.core.users.saml=14 com.solarwinds.lem.commons.service=14 org.springframework.security.saml2=14 org.opensaml.saml=14
Logs example
(Mon Feb 24 22:56:54 EET 2025) DD:DEBUG [SemRelyingPartyRegistrationRepository] {https-jsse-nio-8443-exec-4:49} SAML RP registration get: id='sem' exists=true
(Mon Feb 24 22:57:22 EET 2025) DD:DEBUG [SemRelyingPartyRegistrationRepository] {https-jsse-nio-8443-exec-11:266} SAML RP registration get: id='sem' exists=true
(Mon Feb 24 22:57:22 EET 2025) DD:DEBUG MODE [CompositeSessionAuthenticationStrategy] {https-jsse-nio-8443-exec-11:266} Preparing session with ChangeSessionIdAuthenticationStrategy (1/2)
(Mon Feb 24 22:57:22 EET 2025) II:INFO [HttpSessionClientSessionManager] {https-jsse-nio-8443-exec-11:266} sessionIdChanged 81C07C2CC99A52E73B6DEB9DBFD76821 -> 0B73A2042469451394C2DA326A70B23B
(Mon Feb 24 22:57:22 EET 2025) DD:DEBUG [ChangeSessionIdAuthenticationStrategy] {https-jsse-nio-8443-exec-11:266} Changed session id from 81C07C2CC99A52E73B6DEB9DBFD76821
(Mon Feb 24 22:57:22 EET 2025) DD:DEBUG MODE [CompositeSessionAuthenticationStrategy] {https-jsse-nio-8443-exec-11:266} Preparing session with CsrfAuthenticationStrategy (2/2)
(Mon Feb 24 22:57:22 EET 2025) DD:DEBUG [SamlUserProvisioningSuccessHandler] {https-jsse-nio-8443-exec-11:266} IdP auth success: username='ipotap@keycloack.local' sessionIndexes=[a016******************************************************************7cc2]
(Mon Feb 24 22:57:22 EET 2025) II:INFO [SamlUserProvisioningAuthProvider] {https-jsse-nio-8443-exec-11:266} SAML authentication for 'ipotap@keycloack.local' from 0:0:0:0:0:0:0:1
(Mon Feb 24 22:57:22 EET 2025) II:INFO [SamlUserPlugin] {https-jsse-nio-8443-exec-11:266} Provisioning SAML user 'ipotap@keycloack.local' with authorities [SEM_MONITORS, SEM_AUDITORS, SEM_ADMINS, SEM_GUESTS]
(Mon Feb 24 22:57:23 EET 2025) II:INFO [LemAuthenticationManager] {https-jsse-nio-8443-exec-11:266} Successful authentication: user=[8430] ipotap@keycloack.local, roles=[admin_role]
Browser, network logs and tooling
-
Manually dropping the
JSESSIONIDcookie from the browser before SAML authentication can solve certain problems, likeinvalid_in_response_to. In fact, SEM automatically drops this cookie once it detects this issue, so simply trying to login again should work after. -
SAML-related communication can be captured in the network tab of the browser. Make sure to have Preserve log checked before initiating the SAML authentication, because SAML can use redirects, that can lead to requests/responses to disappear from the Network log.
-
For troubleshooting SAML, use the GitHub - simplesamlphp/SAML-tracer: Browser extension for examining SAML messages, tool that can be installed as a browser extension and shows parsed SAML attributes for requests and responses, and also highlights SAML traffic in the log.
Additional information
-
SAML logout is not supported. Ending the SEM SAML user session will not affect the IdP session for the user, and vice versa.
-
When a SAML user is logged off from SEM, their session on the IdP side may still remain valid. This can allow them to bypass entering credentials on the next SAML login to SEM (unless authentication is forced in the SAML settings).
-
When the user's session is ended from the IdP, but they are still logged in to SEM, it will have no effect on the active SEM user session. However, on the next SAML login, the user will be prompted to enter their credentials.
-
-
Downloading the SEM SAML metadata file is only possible after SAML is configured and enabled.
-
This creates a challenge in scenarios where a customer wants to configure the IdP first by importing the SEM (SP) metadata file.
-
The recommended approach is to first manually configure the IdP client by copying the settings from SEM (SP), and then import the downloaded IdP metadata file of the configured IdP client.
-
The reason for this restriction is to ensure that all SAML endpoints, including public ones like the metadata endpoint, are disabled when SAML is disabled. We may consider changing this once we receive some feedback.
-
-
There is no specific method to test the SAML login functionality for the configured SAML settings, such as a Test button, to verify that SAML is properly configured.
-
The only way to test if SAML login works is to go to the login screen and attempt to perform the SAML login.
-
-
SEM always redirects the SAML user to the main application page (dashboard).
-
In the future we could preserve redirect path in the Relay State and properly implement the redirection of the user to the preserved path after SAML authentication is successful.
-
-
SAML errors appear only on a server internal error page that provides information about the error.