cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

SAML Single Sign-on

For several years now there has been a growing industry trend towards consolidating user authentication mechanisms by integrating applications into a single sign-on solution. This has the benefit of allowing end-users to authenticate to a variety of different applications throughout the organization using a single set of credentials. For end-users, the benefit is obvious. One set of credentials to remember, regardless of which application they're authenticating to. For the organization though, providing your users with a seamless and transparent single sign-on solution has tremendous security benefits. The first being one security password policy to enforce. Different applications typically implement their own unique password complexity requirements and password expiration policies that are essentially impossible to synchronize across various autonomous systems. The end result is usually either passwords being written down on sticky notes and 'hidden' under keyboards, or routine and unnecessary calls made to the helpdesk to reset passwords for end-users. For these reasons and others, we have received countless requests from people just like you throughout the last few years, requesting Orion support an open standards method of single sign-on.

 

SAML (Security Assertion Markup Language) being the industry standard, was the most oft-requested solution, as there is a wide variety of commercial, free, and open source solutions already available, implemented, and operating in customer environments today. Many of these SAML providers offer the additional added security benefit of supporting multi-factor authentication, such as hardware or software tokens, biometrics such as fingerprints, or facial recognition, and even two-step authentication via cellular using SMS text messages or native mobile apps. Supporting multi-factor authentication has been another frequently requested feature we've also been eager to deliver upon, and with the addition of SAML support to the Orion Platform, this could now become a reality. To that end, this release of NPM 12.4 includes native out-of-the-box support for SAML 2.0 authentication, allowing users to leverage their single sign-on credentials to authenticate to the Orion web console, regardless of the type of credentials used.

 

The following steps outlined below will walk you through how to utilize SAML authentication with Orion. For demonstration purposes, I'll be using Okta as my SAML provider, though you could use ADFS (Active Directory Federation Services) or virtually any other SAML 2.0 provider. The instructions assume you already have Okta installed, running, and users created.

 

 

Verify Ports are Open

 

Once you have NPM 12.4 installed in your environment, ensure the Orion server can access Okta by opening a browser on your Orion server and logging into the Okta web interface. This will ensure any ports required between Okta and the Orion server are open. Similarly, you also want to verify your client workstations are also able to access both the Orion web interface, as well as the Okta web portal.

 

Configuring Okta

Create Okta Application

 

1. Once you've verified all necessary ports are opened, you'll want to login to Okta and click 'Admin' from the top menu to access the Okta management interface.

pastedImage_2.png

 

2. Click the carrot next to 'Developer Console' if available to expose a drop-down menu. Select 'Classic UI' from the list to switch to the Okta classic interface

pastedImage_17.png

 

3. Next, From the Administration page, click 'Applications' from the top menu bar. A drop-down menu will appear. Click on 'Applications' from the list.

pastedImage_22.png

 

4. On the 'Applications' page, click 'Add Application'.

pastedImage_27.png

 

5. Next, click 'Create New App' on the 'Add Application' page

pastedImage_36.png

 

6. Select 'SAML 2.0' from the list of available Sign on methods and click 'Create'.

pastedImage_42.png

 

7. In the 'General Settings' step, enter a name for your Orion application in the field next to 'App Name'  I named my application 'aLTeReGo's Orion'.

pastedImage_85.png

At this point, you can add an optional Icon that will appear when the user accesses this application directly from within Okta's web portal. If you're looking for an App logo icon, I'm somewhat partial to the one below. Once you've entered a name for your new Okta application click 'next'.

pastedImage_54.png

 

7. Open another browser window or tab to obtain your 'Single sign-on URL' and 'Audience URI' required for the next step in the Okta application configuration wizard. Log into your Orion web console and go to [Settings > All Settings > SAML Configuration] and click on the button entitled 'Add Identity Provider'.

pastedImage_66.png

 

8. Copy the 'Single Sign-on Service URL' to your clipboard and paste it into Okta's 'Single Sign o URL' field in the SAML settings step of the wizard.

pastedImage_73.png

 

9. From Orion's 'Add Identity Provider' page, copy the 'Entity ID' to your clipboard and paste it into the 'Audience URI (SP Entity ID)' field of Okta's SAML configuration wizard.

pastedImage_105.png

 

10. When done, the 'General' section of your Okta's SAML Settings Configuration should look similar to the image below.

pastedImage_96.png

 

11. Scroll down Okta's SAML Settings page until you reach the 'Attribute Statements (Optional)' section. Create three attributes using the values specified in the following table.

 

NameName formatValue
EmailUnspecifieduser.email
FirstNameUnspecifieduser.firstName
LastNameUnspecifieduser.lastName

 

12. Scroll slightly further down the same page to the section entitled 'Group Attribute Statements (Optional) and create a single attribute using the values shown in the table below

NameName formatFilterValue
GroupNamesUnspecifiedRegex.*

 

Once you've completed steps 11 and 12, verify your 'Attribute Statements (Optional)' and 'Group Attribute Statements (Optional)' field look identical to the following image and click 'Next'.

pastedImage_10.png

 

13. If prompted to 'Help Okta support understand how you configured this application' select 'I'm an Okta customer adding an internal app' if asked 'Are you a customer or partner'. Similarly, if you are asked to define the 'App type' select 'This is an internal app that we have created' and click 'Finish'.

pastedImage_16.png

 

Grant Okta Users Access to Orion

 

1. Edit the Okta application you just created and click the 'Assignments' tab in the top navigation. Then click the 'Assign' button

pastedImage_27.png

 

2. Select from the list of existing Okta users by clicking the 'Assign' button next to their name. Once you've selected all users you wish to access the Orion web console using single sign-on, click 'Done'.

pastedImage_34.png

Configuring SAML Authentication in Orion

 

1. Return back to the Orion Web Console and go to [Settings > All Settings > SAML Configuration] and click 'Add Identity Provider'.

pastedImage_66.png

 

2. In the 'Add Identity Provider' window click 'Next'

pastedImage_2.png

 

3. In the 'Identity Provider Name' enter a friendly name of your SAML provider. Note that the name entered here will appear to your end users when logging into the Orion web console. In my configuration, I named my Identity Provider simply 'Okta' as this is a name well known to my users.

pastedImage_8.png

 

4. In a separate browser Window or tab return to the Okta administration console, edit the application you created earlier and click on the 'Sign On' tab. Once there, click on the 'View Setup Instructions' button pictured below.

pastedImage_13.png

 

5. Copy the 'Identity Provider Single Sign-On URL' from Okta and paste it into the 'SSO Target URL (Endpoint)' field in Orion.

6. Copy the 'Identity Provider Issuer' from Okta, and past this information into the 'Issuer (Entity ID)' field in Orion

7. Copy the 'X.509 Certificate' in its entirety, including '-----BEGIN CERTIFICATE-----' through to -----END CERTIFICATE----- and paste this into the 'Public Certificate' field in Orion.

pastedImage_19.png

 

8. When you're done, the 'Add Identity Provider' wizard should look similar to the following. Once you've validated your changes, click 'Next'.

pastedImage_18.png

 

9. On the final step of the 'Add Identity Provider Wizard' simply click 'Save'.

pastedImage_34.png

 

10. When you're done you will be returned to the 'SAML Configuration' page. At the top, you will find a slider which allows you to globally enable or disable SAML authentication for Orion. By default, it is enabled once SAML authentication is successfully configured.

pastedImage_40.png

 

Creating SAML User Accounts in Orion

 

Now that you have SAML configured both in Okta and Orion, you'll need to create matching SAML user accounts in Orion so can assign permissions and apply any view restrictions you desire, no different than you would any other user in Orion.

 

1. To get started navigate to [Settings > All Settings > Manage Accounts] and click 'Add New Account'.

pastedImage_3.png

 

2. In the list of account types to create, choose 'SAML individual account' and click 'Next'.

pastedImage_8.png

 

3. In the 'Enter Account Info' step, enter the username of the user you wish to access Orion using SAML authentication into the 'Name ID' field. It's important that this name match identically to what appears in Okta or the user will be unable to login to Orion. Once you've entered the username into the field click 'Next'.

pastedImage_15.png

 

4. In the final step of the Wizard, assign any special permissions, views, menu bars, or view limitations you wish the user to have when the login to Orion. When complete, scroll to the bottom of the page and click 'Submit' to save these changes.

pastedImage_22.png

 

 

Testing your SAML Authentication

 

1. To test your SAML authentication, log out of the Orion web console or open a different browser from the one you're currently logged in with. E.G. if you're using Google Chrome to configure Orion, open Firefox to test your SAML configuration.

pastedImage_29.png

2. When you first access the Orion login page you may notice you now have a new option that wasn't there prior to configuring SAML authentication. Below the usual 'Login' button, there is now an additional button entitled 'Login with Okta'. Okta is the friendly name we gave to our SAML provider in step #3 of 'Configuring SAML Authentication in Orion' above. Click the button 'Login with Okta' to proceed.

pastedImage_34.png

 

3. You should now be redirected to the Okta web portal. If you're not already logged into Okta, you will be prompted to authenticate. Simply enter your Okta credentials and click 'Sign in'

pastedImage_41.png

 

4. Once you've successfully authenticated to Okta, you should be immediately redirected back to the Orion web console and transparently authenticated

pastedImage_47.png

 

Summary

 

As stated earlier, this walkthrough is simply an example of using individual user accounts with Okta. If you've configured Orion SAML authentication, we'd love to hear which identity provider you're using and whether you're leveraging individual user accounts or groups. Also, if you have any tips and tricks or better yet,  a walkthrough on how you configured a different identity provider, we'd love to hear from you!

 

Note that SAML can be used simultaneously in conjunction with all other existing authentication mechanisms supported by Orion, including both Active Directory user and group authentication via LDAP or MSAPI, as well as local Orion user accounts. SAML does, however, require that your IIS be configured to use Forms Based Authentication (default behavior) and cannot be used with Windows Integrated Authentication (optional setting located in the Configuration Wizard).

Comments

Great work and tutorial! Happy to see SAML 2.0 is now supported!

FYI, I ran into some trouble with the group attribute statement...seems that the Name needs to be OrionGroups...If I use GroupNames as suggested above, SAML succeeds, but authentication for the test user fails.

Also, in my environment I use an additional webserver behind and F5 VIP to access orion.  In that configuration, SAML fails and the error indicates that it's trying to use just the URI, not the full URL (/Orion/SamlLogin.aspx instead of https://orion.hostname.com/Orion/SamlLogin.aspx).  If I change the VIP to use the core server instead of the additional web server SAML works fine.

I have a ticket open with solarwinds support #00265496

joelgarnick  wrote:

FYI, I ran into some trouble with the group attribute statement...seems that the Name needs to be OrionGroups...If I use GroupNames as suggested above, SAML succeeds, but authentication for the test user fails.

You are correct. There should be ‘OrionGroups’. This may be an error in our documentation.

Also, in my environment I use an additional webserver behind and F5 VIP to access orion.  In that configuration, SAML fails and the error indicates that it's trying to use just the URI, not the full URL (/Orion/SamlLogin.aspx instead of https://orion.hostname.com/Orion/SamlLogin.aspx).  If I change the VIP to use the core server instead of the additional web server SAML works fine.

We will need some additional information, like the specific error(s) you are seeing.

Each website address has to be filled in IdP. See sections about additional websites in this KB:

https://support.solarwinds.com/Success_Center/Orion_Platform/Orion_Documentation/Orion_Platform_Admi...

You may need enter the FQDN of the website users enter into the URL bar of their browser to access Orion (which is likely the F5 load balancer) rather than the Orion server itself.

This is the specific error I get.  There's also the SAML request and response xml that I could provide, but has some sensitive info in it, so I won't post it here...

Type:

ComponentSpace.SAML2.Exceptions.SAMLProtocolException

Message:

The SAML response destination https://domain.com/Orion/SamlLogin.aspx doesn't match the expected destination /Orion/SamlLogin.aspx.

Stack Trace:

at ComponentSpace.SAML2.AbstractSAMLProvider.CheckDestination(StatusResponseType samlResponse, String destinationUrl)

at ComponentSpace.SAML2.InternalSAMLServiceProvider.ProcessSAMLResponse(XmlElement samlResponseElement, Boolean& isInResponseTo, String& authnContext, String& userName, SAMLAttribute[]& attributes)

at ComponentSpace.SAML2.InternalSAMLServiceProvider.ReceiveSSO(HttpRequestBase httpRequest, Boolean& isInResponseTo, String& partnerIdP, String& authnContext, String& userName, SAMLAttribute[]& attributes, String& relayState)

at SolarWinds.Orion.AccountManagement.Saml.SamlManager.ReceiveSSO(HttpRequestBase request)

at SolarWinds.Orion.AccountManagement.Saml.SamlManager.ReceiveSSO(HttpRequest request)

at SolarWinds.Orion.AccountManagement.LegacyWebSite.Orion_SamlLogin.Page_Load(Object sender, EventArgs e)

OK, finally caught on...so in the SAML settings in Orion I added the same URL that I use for my main site on each of the additional webservers (not the webserver hostnames, the VIP URL).  After making that change, SAML works via the additional webservers.  Thanks!

I am having an odd issue where when I go to configure SAML the service URL is not populating in Solarwinds, I have put in what seems to be the default however my configuration is failing and there is nothing in the SAML log. Is it possible that my website needs a rebuild, or is there another way I can verify my service URL?

pastedImage_0.png

Try to diagnose your connection between Orion and SAML server using instruction from paragraph "Test your SAML configuration" in the bottom of documentation Authenticate users with SAML v2 - SolarWinds Worldwide, LLC. Help and Support.

Already attempted the troubleshooting steps from the article prior to posting. Thus the surprised that I have all these failures and nothing in my SAML log.

Got this working. Redid the configuration using chrome instead of IE and SAML started working after that. I would like to highlight this as a potential bug though

Nice find christopher.t.jones123​! Out of curiosity, do you use Internet Explorer as your daily browser?

Not a chance! I was brought in after the fact and the original configuration was conducted using IE, noticed that in IE it did not populate the service URL, but in Chrome it would so then we decided to try the setup in Chrome and were successful.

If I had set it up initially then I would’ve used Chrome, but would have never stumbled on this weird behavior.

My guess is that the setup also does a service activation of some sort, and when it is conducted in IE that service activation does not happen correctly.

Is that how the underlying system is accomplishing this?

The bug is confirmed. Internet Explorer has a display issue on the page. As a consequence, when the Single Sign On URL is not the right one, it doesn't know what to do with the SSO data received. It then redirects to the login page like any unauthenticated URL.

Good article

Can we use Shibboleth SP with Orion ?

wakhan  wrote:

Can we use Shibboleth SP with Orion ?

Yes

@aLTeReGo We are facing problems adding the Groups name in the SMAL Groups.  We are using the group.  For example, "Solarwind_Admin" is the security AD group, a member in that we are login and getting error  "This user or user group is not defined in the Orion Platform.  Can you please suggest what we are doing wrong. @

Have you created the corresponding group in Orion? [Settings > All Settings > Manage Accounts > SAML Groups]

aLTeReGo - Thanks for replying.  Let me ask you a question, little differently.  The problem we are facing the user under the group name is not able to log in. The error we are getting is, "This user per user group is not defined in Orion Platform."  We have given a name like ENT_Solarwind_admin, the AD security group, and we are using the name in the Saml group and user under that are not login.  Can you please suggest what are we missing? 

pastedImage_0.png

Did you configure the ‘OrionGroups’ SAML attribute? This can be quickly checked by providing the result of the SAML test. It should display something similar to this:

pastedImage_0.png

Looks the Solarwind have bug which prevent the Solarwind groups to fetch group data.

--

Thank you,

Nishil

Can you describe the nature of the bug? From reviewing your case it appears you were able to get the issue resolved.

The bug is that Solarwind application is not able to pull user from the Azure group. Here the your internal Jira ticket for that bug.

https://jira.solarwinds.com/browse/CUST-58540

--

Thank you,

Nishil

Ahh, that makes sense as Azure ADFS is not currently supported by Orion. Azure ADFS is significantly different than ADFS and may other standard SAML providers.

Yup, is that something you guys are working adding in the feature release?

--

Thank you,

Nishil

Unfortunately, I cannot provide any specific details beyond what is posted publically in our What We're Working on post.

Hi -

I am using Ping Federate and SSO isn't working. Any help? TIA

I've already created a SAML Group called PingFederate

[153] (45) ERROR SolarWinds.Orion.AccountManagement.Saml.SamlManager - (null)  ComponentSpace.SAML2.Exceptions.SAMLProtocolException: The SAML response destination https://<FQDN>/Orion/SamlLogin.aspx doesn't match the expected destination /Orion/SamlLogin.aspx.

   at ComponentSpace.SAML2.AbstractSAMLProvider.CheckDestination(StatusResponseType samlResponse, String destinationUrl)

   at ComponentSpace.SAML2.InternalSAMLServiceProvider.ProcessSAMLResponse(XmlElement samlResponseElement, Boolean& isInResponseTo, String& authnContext, String& userName, SAMLAttribute[]& attributes)

   at ComponentSpace.SAML2.InternalSAMLServiceProvider.ReceiveSSO(HttpRequestBase httpRequest, Boolean& isInResponseTo, String& partnerIdP, String& authnContext, String& userName, SAMLAttribute[]& attributes, String& relayState)

   at SolarWinds.Orion.AccountManagement.Saml.SamlManager.ReceiveSSO(HttpRequestBase request)

I'm afraid I'm not familiar with Pingfederate, but the error suggests that the SAML response from Pingfederate is not configured correctly. Have you used the 'test' button?

download.png

Yes, I have tried using the Test button – same error

This issue might be caused by mismatch of URL formats used on Orion and SSO side. Ideally use complete format that include schema and domain parts. Something like https://www.solarwinds.com in “Orion Web Console URL” field in Orion Identity Provide configuration page, and  https://www.solarwinds.com/Orion/SamlLogin.aspx in Ping Federate configuration.

If it is not possible, try to use URL without domain part on both places.

Hello folks,

I went through the document guide to configure Okta and Orion. However, it throws this error once login. The message is clear that the HTTP method is not correct. I don't seem to find any info on the internet, also I don't see any additional configurations in Orion to change the HTTP method. Any advice must be appreciated. Thanks.

"ExceptionMessage": "The message is not an HTTP POST.",

------------------------------

2020-01-10 12:28:35,814 [41] (13) WARN SolarWinds.Orion.AccountManagement.LegacyWebSite.Orion_SamlTestResult - (null)  SAML Test Result:

{

  "TestResult": 2,

  "Title": null,

  "Message": null,

  "UserName": null,

  "Groups": null,

  "IsGroupClaimMissing": false,

  "SamlRequest": "<samlp:AuthnRequest ID="_f955rg78-3e51-487d-b514-5b8t5jcc741f" Version="2.0" IssueInstant="202001-21T22:17:48.088Z" Destination="https://atg.oktapreview.com/app/ouractualurl/somerandomstuff/sso/saml" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://solarwindsdev.ourdomain.com/Orion/SamlLogin.aspx" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://solarwindsdev.ourdomain.com</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>",

  "SamlResponse": null,

  "SamlInitLoaded": "2020-01-10T12:28:34.8584709-05:00",

  "SamlLoginLoaded": "2020-01-10T12:28:35.6897877-05:00",

  "SamlLoginFinished": null,

  "ExceptionType": "ComponentSpace.SAML2.Exceptions.SAMLBindingException",

  "ExceptionMessage": "The message is not an HTTP POST.",

  "ExceptionStackTrace": " at ComponentSpace.SAML2.Bindings.HTTPPostBinding.ReceiveResponse(HttpRequestBase httpRequest, XmlElement& samlMessage, String& relayState)

   at ComponentSpace.SAML2.InternalSAMLServiceProvider.ReceiveSSO(HttpRequestBase httpRequest, Boolean& isInResponseTo, String& partnerIdP, String& authnContext, String& userName, SAMLAttribute[]& attributes, String& relayState)

   at SolarWinds.Orion.AccountManagement.Saml.SamlManager.ReceiveSSO(HttpRequestBase request)

   at SolarWinds.Orion.AccountManagement.Saml.SamlManager.ReceiveSSO(HttpRequest request)

   at SolarWinds.Orion.AccountManagement.LegacyWebSite.Orion_SamlLogin.Page_Load(Object sender, EventArgs e)"

}

This error typically occurs when the Orion URL ends in a trailing slash '/'. Okta then turns service URL (ACS) into ...//Orion/SamlLogin.aspx (note the double slash).

Actually, I removed the "/" at the end, but same issue still exists. However, I just learned that Okta shipped with SolarWinds app, so instead of creating a new app on Okta, we used the SolarWinds app and it works perfectly. This option works fine for us. Thanks for stopping by.

Version history
Revision #:
1 of 1
Last update:
‎09-03-2018 02:34 PM
Updated by: