Overview

The SearchStax Managed Search service can be used to add custom indexes on a Sitecore website.

This page presumes that you have already installed Sitecore and connected it to a Managed Search deployment according to the directions for Sitecore 9.1, Sitecore 9.2, Sitecore 9.3, or Sitecore 10.

Therefore, you already have a Sitecore site that is connected to a compatible Managed Search deployment. You have access to the Solr Dashboard, and you have prepared Solr configuration files for your custom collections, including a custom Managed Schema file.

Contents:

1. Install the Zookeeper Script
2. Upload the Sitecore Configuration Files.
3. Create Sitecore Collections.

Install the Zookeeper Script

Apache ZooKeeper is a centralized service for maintaining configuration information. In a Managed Search deployment, Zookeeper acts as a centralized repository for your Solr configuration files.

SearchStax users do not have direct access to the Zookeeper configsets as they would in a local Solr installation. Instead, they interact with Zookeeper through a modified version of Solr’s standard zkcli script. SearchStax provides both Linux and Windows versions of the script.

You can download the zkcli ZIP file here: searchstax-client-master.zip.

Unzip the file. The top-level directory is \searchstax-client-master. Navigate to the solr-5, solr-6, solr-7, or solr-8 scripts subdirectory (such as \searchstax-client-master\solr-8\scripts). Locate zkcli.bat in that directory. This is the Windows version of the script.

Upload the Sitecore Configuration Files

We assume that you have a directory of configuration files prepared for your custom Sitecore collection. If not, you can download a Sitecore configset from your Solr Cloud deployment and then upload it again under a new name. The configset name should match the name of your custom index.

See How can I update my Solr configurations in Zookeeper? for instructions on using zkcli to download/upload configsets.

Follow these steps to upload the Solr configuration for your new collection:

1. Download any of the existing Sitecore configsets.
2. Upload the configset to Zookeeper under a new name that matches your custom index.

Create Sitecore Collections

When you have uploaded the Solr configuration to Zookeeper, you can create Sitecore collections by following these steps:

1. Navigate to the Collections page in the Solr Dashboard.
2. Click Add Collection.
3. In the config set field, click the Sitecore configuration.
4. Specify the following fields as shown:
5. Repeat for each of the custom collections you wish to add.

The post Sitecore Custom Indexes appeared first on SearchStax Docs.

Use the SearchStax API to add custom Solr JAR files with Solr Package Manager.

Use Package Manager as the preferred workflow for adding or upgrading custom JARs on Managed Search deployments where Package Manager is enabled. Instead of adding a custom JAR directory to solrconfig.xml and restarting Solr after each upload, you upload JAR files to Filestore, register package versions, and reference the package name from your configset.

Solr Package Manager uses Solr Filestore. Filestore stores and distributes JAR files across Solr nodes in a deployment. Package Manager references those files, assigns package names and versions, and makes the classes in those files available to Solr.

Package Manager helps when you upgrade custom JAR files over time. After your configset references a package-prefixed class name, you can upload a new JAR and register a package version without changing the configset, reloading collections, or restarting Solr.

During migration, the Custom JARs mechanism and Package Manager can operate at the same time. This lets you move custom classes to Package Manager incrementally. The Custom JARs workflow remains available for legacy deployments and migration cases.

For the legacy custom JAR upload and restart workflow, see Solr Custom JARs API.

Prerequisites

Before you start, you need:

• A SearchStax Managed Search deployment running Solr 9 or later
• A Premium Managed Search plan, such as Core or higher
• A SearchStax user with Technical Contact access or higher
• Package Manager enabled on the deployment, or an eligible deployment where Package Manager can be enabled
• A SearchStax API token
• The SearchStax account name
• The deployment UID
• A JAR file to upload
• Permission to update the relevant Solr configsets
• Permission to reload affected Solr collections after configset changes

API Base URL

The examples in this article use the following base URL:

https://app.searchstax.com/api/rest/v2

The examples use the following variables:

Authenticate

Request an authentication token from the SearchStax API:

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "username": "<username>",
    "password": "<password>",
    "tfa_token": "<tfa_token>"
  }' \
  https://app.searchstax.com/api/rest/v2/obtain-auth-token/

The tfa_token field is optional unless your SearchStax account requires two-factor authentication.

The response includes a token:

{
  "token": "<token>"
}

For the remaining requests, include the token in the Authorization header:

Authorization: Token <token>

Step 1: Check Package Manager Availability

Package Manager is available for Solr 9 deployments on eligible Managed Search plans. New Solr 9 deployments created in July 2026 or later have Package Manager enabled by default. Existing Solr 9 deployments created before July 2026 may need Package Manager enabled before you use package-managed JAR files.

List existing packages to review the packages registered with the deployment:

curl -s \
  -H "Authorization: Token <token>" \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/

Successful response: 200 OK.

Example response:

{
  "result": {
    "znodeVersion": 0,
    "packages": {
      "my-package": [
        {
          "package": "my-package",
          "version": "1.0.0",
          "files": [
            "/my-plugin-1.0.0.jar"
          ]
        }
      ]
    }
  }
}

If Package Manager isn’t enabled on your deployment, use the enable endpoint before uploading package-managed JAR files.

Step 2: Enable Package Manager, If Needed

If Package Manager isn’t enabled on an eligible deployment, use the enable endpoint before you use package-managed JAR files:

curl -s -X POST \
  -H "Authorization: Token <token>" \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/enable/

Successful response: 200 OK.

Don’t include a request body unless SearchStax provides one for your deployment or workflow.

Note: For deployments created before July 2026, contact SearchStax Support if you can’t enable Package Manager from your account.

Enabling Package Manager may trigger a rolling restart of the deployment.

Step 3: Upload a JAR File to Filestore

Upload the JAR file to Solr Filestore:

curl -s -X POST \
  -H "Authorization: Token <token>" \
  -F "file=@./my-plugin-1.0.0.jar" \
  -F "checksum=<sha512_checksum>" \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/files/

The checksum field is optional. Use this field to provide the SHA-512 checksum of the JAR file.

When you upload a JAR through the SearchStax API, SearchStax signs the JAR and uploads the signed JAR to Filestore. Solr validates the signature before accepting the file.

Request Fields

Successful response: 201 Created.

Example response:

{
  "file": "/my-plugin-1.0.0.jar",
  "responseHeader": {
    "status": 0,
    "QTime": 67
  }
}

If the same file metadata already exists, the response can include a message similar to the following:

{
  "file": "/my-plugin-1.0.0.jar",
  "message": "File with same metadata exists ",
  "responseHeader": {
    "status": 0,
    "QTime": 13
  }
}

Step 4: Create a Package Version

After the JAR is available in Filestore, register it as a Solr package version:

curl -s -X POST \
  -H "Authorization: Token <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "add": {
      "package": "my-package",
      "version": "1.0.0",
      "files": [
        "/my-plugin-1.0.0.jar"
      ]
    }
  }' \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/

Request Fields

Successful response: 200 OK.

Example response:

{
  "responseHeader": {
    "status": 0,
    "QTime": 59
  }
}

If the package version already exists, the response can include a Solr 400 error:

{
  "responseHeader": {
    "status": 400,
    "QTime": 8
  },
  "error": {
    "msg": "Error executing command, errors: [...]",
    "code": 400
  }
}

Note: Solr uses lexicographic ordering, not semantic version ordering, to determine the latest package version. For example, Solr considers 1.9.0 newer than 1.11.0. Choose version labels carefully so the latest intended version sorts correctly.

Step 5: Update Configset Class References

Update the relevant Solr configset files so Solr references the package-prefixed class name.

Before Package Manager, custom classes use a fully qualified class name.

class="com.example.solr.MyClass"

With Package Manager, prefix the class name with the package name:

class="my-package:com.example.solr.MyClass"

For example, the following request handler:

<requestHandler name="/example" class="com.example.solr.MyClass" />

becomes the following:

<requestHandler name="/example" class="my-package:com.example.solr.MyClass" />

Upload the modified configset using your normal configset management workflow.

Step 6: Reload Affected Collections

Reload each Solr collection that uses the updated configset.

The reload applies the initial configset changes without requiring a full deployment restart.

Use your normal collection reload workflow. This might be a SearchStax workflow, a Solr API workflow, or a process that you coordinate with SearchStax Support.

Update a Package to a New JAR Version

To update a package, upload the new JAR file and create a package version with the same package name.

For example, upload my-plugin-1.1.0.jar, and then register a new version of my-package:

curl -s -X POST \
  -H "Authorization: Token <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "add": {
      "package": "my-package",
      "version": "1.1.0",
      "files": [
        "/my-plugin-1.1.0.jar"
      ]
    }
  }' \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/

After the configset uses the package-prefixed class name, future package version changes don’t require another configset class-name change, collection reload, or Solr restart. Solr uses the latest package version automatically.

Note: Because Solr uses lexicographic ordering to determine the latest package version, confirm that the new version sorts after the previous version.

Manage Existing Files

List Files

List files in Solr Filestore:

curl -s \
  -H "Authorization: Token <token>" \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/files/

Successful response: 200 OK.

Example response:

{
  "files": {
    "/": [
      {
        "name": "my-plugin-1.0.0.jar",
        "size": 262,
        "timestamp": 1712345678901,
        "sig": [
          "<signature>"
        ],
        "sha512": "<sha512_checksum>"
      },
      {
        "name": "_trusted_",
        "dir": true
      }
    ]
  },
  "responseHeader": {
    "status": 0,
    "QTime": 5
  }
}

Get File Metadata

Retrieve metadata for a specific file.

The <filename> path parameter can’t contain /.

curl -s \
  -H "Authorization: Token <token>" \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/files/<filename>/

Successful response: 200 OK.

Example response:

{
  "files": {
    "/my-plugin-1.0.0.jar": {
      "name": "my-plugin-1.0.0.jar",
      "size": 262,
      "timestamp": 1712345678901,
      "sig": [
        "<signature>"
      ],
      "sha512": "<sha512_checksum>"
    }
  },
  "responseHeader": {
    "status": 0,
    "QTime": 5
  }
}

Download a File

Download a file from Solr Filestore.

The <filename> path parameter can’t contain /.

curl -L \
  -H "Authorization: Token <token>" \
  -o my-plugin-1.0.0.jar \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/files/<filename>/download/

Successful response: 200 OK.

Response body: Binary file content. The response is the file itself, not a JSON object.

Delete a File

Delete a file from Solr Filestore.

The <filename> path parameter can’t contain /.

A file can’t be part of any package when you delete it. Delete the package version that references the file before deleting the file.

curl -s -X DELETE \
  -H "Authorization: Token <token>" \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/files/<filename>/

Successful response: 200 OK.

The response body can include a Solr response header.

{
  "responseHeader": {
    "status": 0,
    "QTime": 18
  }
}

If the file is still referenced by a package, the response can include a Solr 400 error:

{
  "responseHeader": {
    "status": 400,
    "QTime": 11
  },
  "error": {
    "msg": "jar in use, can't delete",
    "code": 400
  }
}

Manage Existing Packages

List Packages

List packages registered with Solr Package Manager:

curl -s \
  -H "Authorization: Token <token>" \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/

Successful response: 200 OK.

Example response:

{
  "result": {
    "znodeVersion": 2,
    "packages": {
      "my-package": [
        {
          "package": "my-package",
          "version": "1.0.0",
          "files": [
            "/my-plugin-1.0.0.jar"
          ]
        },
        {
          "package": "my-package",
          "version": "1.1.0",
          "files": [
            "/my-plugin-1.1.0.jar"
          ]
        }
      ]
    }
  }
}

Delete a Package Version

Use the delete package command to delete a package version:

curl -s -X POST \
  -H "Authorization: Token <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "delete": {
      "package": "my-package",
      "version": "1.0.0"
    }
  }' \
  https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/package-manager/

Request Fields

Successful response: 200 OK.

Example response:

{
  "responseHeader": {
    "status": 0,
    "QTime": 10
  }
}

Note: The package delete command uses the same POST /package-manager/ endpoint as package creation.

Endpoint Reference

Package Manager Endpoints

File Endpoints

Request Body Reference

Upload File Request

Add Package Version Request

{
  "add": {
    "package": "my-package",
    "version": "1.0.0",
    "files": [
      "/my-plugin-1.0.0.jar"
    ]
  }
}

Delete Package Version Request

{
  "delete": {
    "package": "my-package",
    "version": "1.0.0"
  }
}

The post Solr Package Manager API appeared first on SearchStax Docs.

Overview

The SearchStax Managed Search service can be used to enable Apache Solr on a Drupal 7 website using Drupal’s Search API and its Search API Solr modules.

This article was based on a blog post by Thomas Hada of Anant.

Basic Steps:

1. Create a new deployment in SearchStax.
2. Install the Zookeeper script.
3. Upload a custom configuration to your Solr Server.
4. Install Drupal.
5. Install the Search API and Search API Solr modules.
6. Configure the Search API Solr module.
7. Optional – Add sample content.
8. Optional – Manually index Your site.
9. Optional – Secure your site

Step 1: Create a New Deployment in Managed Search

Assuming you have already created a SearchStax account and do not already have a deployment set up, click on the Deployments tab and then click on the Create New Deployment button at the top. Enter a deployment name, and select the most appropriate region, plan, and Solr version for your needs. In this example we will be using Solr 5.5.5.

Once you create your deployment, you will see it in the Deployments dashboard.

Clicking on the name of the deployment will give you pertinent information about your deployment’s servers. The Solr HTTP Endpoint will take you to your Solr server dashboard.

Step 2: Install the Zookeeper Script

Apache ZooKeeper is a centralized service for maintaining configuration information. In a SearchStax deployment, Zookeeper acts as a centralized repository for your Solr configuration files.

We have created a script to help you interact with Zookeeper. This script makes it easier to connect to Zookeeper and upload your Solr configurations. We provide both Linux and Windows versions of the script.

We have made the script available in several different ways. Choose the one that is easiest for you. All methods download the same master.zip or searchstax-client-master.zip file. This file contains both the Linux and Windows scripts. Unzip the file in a directory of your choice.

• From the Linux command line, you can use wget https://github.com/searchstax/searchstax-client/archive/master.zip.
• If you have a GitHub account, you can follow this link to a repository that contains the script and its libraries. Look for the green Clone or Download button to create and download a ZIP file. https://github.com/searchstax/searchstax-client
• If you are using Windows, or are not familiar with GitHub, you can download the ZIP file directly here: searchstax-client-master.zip.

Unzip the file. The top-level directory is \searchstax-client-master. Navigate to the scripts subdirectory (\searchstax-client-master\solr-6\scripts). Locate zkcli.sh and zkcli.bat in that directory. These are the Linux and Windows versions of the script, respectively.

Step 3: Upload a Custom Configuration to Your Solr Server

Download the Search API Solr module files: https://www.drupal.org/project/search_api_solr/

Included in the Search API Solr download are several configurations in the solr-conf folder, with subfolders 4.x, 5.x, and 6.x for the respective Solr versions.

SearchStax uses Apache ZooKeeper for maintaining configuration information. Upload the appropriate configuration files via Zookeeper and create a new collection. If you have your Zookeeper script already, the two commands you will need are as follows:

Upload Configuration:

Linux:

> ./zkcli.sh -zkhost <zookeeper URL> -cmd upconfig -confdir <Solr configuration> -confname <configuration name>

Windows:

$ zkcli.bat -zkhost <zookeeper URL> -cmd upconfig -confdir <Solr configuration> -confname <configuration name>

Create New Collection:

Linux:

> curl '<Solr HTTP Endpoint>admin/collections?action=CREATE&name=<collectionName>&collection.configName=<configName>&numShards=1'

Windows:

$ curl.exe "<Solr HTTP Endpoint>admin/collections?action=CREATE&name=<collectionName>&collection.configName=<configName>&numShards=1" -k

Step 4: Install Drupal

Please refer to the official Drupal 7 installation page.

Step 5: Install Search API / Search API Solr Module

Install the Drupal Search API Module.

Once the Search API is installed, you can add the Search API Solr Module.

Finally, you will need to enable the installed modules. Enable Search API and Solr Search.

Step 6: Configure the Search API Solr Module

Now that the modules have been enabled, click on the Configuration tab. Look for section SEARCH AND METADATA and click on Search API to configure it.

Once there, click Add Server.

Give your server a name. Make sure the Service class is set to Solr service. Check that HTTP protocol is set to https. The Solr host is the deployment’s Solr HTTP Endpoint without the /solr/ element. For incoming connections from Drupal, the Solr port is always 443. The Solr path is /solr/ plus the name of the collection, such as /solr/testcollection.

If your configuration settings are valid, you will see a message saying that the information was saved successfully.

Next you will need to define an index. In the Search API configuration screen, click on Add Index. Give your index a name, and select the item type you wish to index.

Step 7: Optional – Add Sample Content

Install the Devel module: https://www.drupal.org/project/devel. Then, enable Devel and Devel generate.

You will see new options in multiple menus. Go to Administration > Configuration, and scroll down to the Development section. Here you have options to Generate content via Devel.

Click on Generate Content.

Select a Content Type and enter the number of nodes. For example, selecting Article and typing “20” nodes will produce 20 new articles filled with dummy data.

Step 8: Optional – Manually Index Your Site

A cron job will periodically index your site automatically, but if you want to see your results immediately go to the Search API configuration screen and click on the index created earlier. At the bottom, click on the Index now button.

After you begin, you will see a progress bar. Once it reaches 100%, you will get a success message.

After your site has been indexed, you can view and query the data in Solr.

Step 9: Optional – Secure Your Site

SearchStax and Solr provide some optional security features that can help you lock down your Solr deployment. Please consider some or all of the following security options.

Connecting to the Managed Search Cluster

SearchStax recommends that you situate your application infrastructure in the same local network as your hosting provider (for example, the same AWS or Azure region). Internal network security for these hosting providers is extremely high and eliminates any chance of a hacker potentially sniffing your network traffic.

If your application is hosted elsewhere, try to host it as close to your search infrastructure as possible. This can be done by choosing the Cloud Provider Region which is closest to your application. This improves both security and performance.

Note that all connections to the SearchStax Dashboard use HTTPS, which encrypts your traffic in transit.

IP Filtering

SearchStax can limit access to a deployment to specific IP addresses. You can configure access for Zookeeper and Solr servers separately. Instructions will be found at SearchStax IP Filtering.

Tenant Users

Each SearchStax account is restricted to the owner (and admin) of that account plus any SearchStax “tenant users” who have been granted access to that account by the owner. The additional users may be enrolled as normal SearchStax operators or as admins at the owner’s discretion. See Managing Users.

Solr Authentication and Authorization

Solr offers an Authentication and Authorization feature that lets you set up username/password protection for the Solr server dashboard. SearchStax makes it very easy to enable this feature.

Note that Solr user accounts are independent of SearchStax user accounts.

If you set a username/password for Solr, you’ll need to edit the Search API server (under “Basic HTTP authentication”) and input the same information there.

The only warning is that enabling/disabling Solr authentication forces the Solr servers to restart. See Solr Authentication and Authorization.

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Managed Search for Drupal 7 appeared first on SearchStax Docs.

The post Managed Search Solr Help Center appeared first on SearchStax Docs.

The SearchStax Managed Search service automatically secures your Solr search infrastructure with built-in industry-standard security measures at the cluster, network and dashboard levels.

Learn more about securing your Solr deployment:

• Change your password
• Two-Factor Authentication
• Single Sign-on – Okta
• Single Sign-on – OneLogin
• Single Sign-on – PingFederate
• Single Sign-on – Azure
• Securing Solr Deployments

The post Managed Search Security Overview appeared first on SearchStax Docs.

There are multiple ways to change a password in the SearchStax Managed Search service depending on context.

If you are locked out of your Managed Search account, use the password reset link on the login page.

If you are logged in to Managed Search, but need to change your password because it is about to expire, navigate to the User Preferences > Password page.

Users and passwords associated with the Solr Basic Auth feature can be managed from within Managed Search. Visit the Deployment Details page and open the Security > Auth page. The Managed Search admin can edit the Solr users and passwords from there.

As a footnote, it is also possible to set Solr Basic Auth passwords procedurally from the Searchstax Provisioning API.

The post Change Your Password appeared first on SearchStax Docs.

All SearchStax Managed Search service users have the option of enabling Two-Factor Authentication (TFA). Navigate to the User Preferences > Two-Factor Authentication tab.

The setup procedure is simple. Click the Set Up Authentication App button to generate the QR code on this screen:

Install the Google Authenticator app on your phone or tablet and use it to scan the QR code. Once the link to SearchStax is verified (which is almost instantaneous), the phone app begins to display six-digit numbers.

When you log into Managed Search, enter your email address and strong password as usual. Managed Search will open a field for your six-digit code. This code changes once each minute, so it is a very secure way to authenticate.

Note that Managed Search displays a screen of Backup Verification Codes that you can use if you lose your phone. We recommend that you store these codes in a safe place that isn’t on your phone.

You can also deactivate Two-Factor Authentication from the same User Preferences screen.

The post Two-Factor Authentication appeared first on SearchStax Docs.

The SearchStax Managed Search service now offers the ability for clients to set up Single Sign-On (SSO) to let their users log into SearchStax apps with a single ID and password that works across multiple software systems.

We use the open standard Security Assertion Markup Language (SAML) to allow identity providers (IdP) to pass authorization credentials to service providers (SP). This page provides instruction to use Okta to implement SSO for Managed Search.

SSO is an add-on Managed Search feature that is purchased separately. If you are interested in SSO, please contact Sales.

Once SSO is enabled for your account and a domain is set up, the admin is able to see the configuration options in the User Preferences screen of the Managed Search Dashboard.

The following steps explain how it can be set up for Okta.

Instructions

Once your account has been enabled for SSO by the SearchStax team and a domain has been provided, the account owner and/or admin can see the option to complete set up. This option is found in the User Preferences screen of the Managed Search Dashboard:

1. You need to be an Admin in Okta to set up the SearchStax Application.

2. Go to the Okta Admin Console. Click on Applications > “Create App Integration”. Select “SAML 2.0” and click on “Next”

3. Enter the name of the App as “SearchStax Cloud” and click on Next

4. Configure the SAML Settings with the following information:

• Set the “Single sign on URL” as the Assertion Consumer Service URL provided in SearchStax Cloud
• Check on “Use this for Recipient URL and Destination URL”
• Set the “Audience URI”as the Metadata URL provided in SearchStax Cloud
• Set the “Name ID format” as “Unspecified”
• Set the “Application username” as “Email”
• Set the “Update application username on” as “Create and update”

5. Click on “Show Advanced Settings” and set “Response” and “Assertion Signature” to “Signed”. Below is a sample of Advanced Settings

*If you change the response and assertion settings, you will need to also change the SearchStax Cloud “Assertions responses signed*” setting to match.

6. The next section provides Attribute Statements for mapping Okta fields to SearchStax. Below are sample mappings that we defined

The above example assigns the role of “Admin” to all users in SearchStax Cloud. However, if you have a different field in Okta that maps the role, you can assign that field instead. Here is more information about roles in SearchStax Cloud. If a role is not specified, users will be provisioned with the “Team Member” role, which is a read-only role.

Click on Next.

7. Select “I’m an Okta customer adding an internal app” and click on “Finish”

8. Now click on the “View SAML setup instructions” button that is displayed to the right

9. Copy the “Identity Provider Single Sign-On URL” from the screen and set it as the Login url in SearchStax Cloud.

10. Copy the “Identity Provider Issuer” from the screen and set it as the Idp entity url in SearchStax Cloud.

11. Copy the XML shown in the Optional section with the title “Provide the following IDP metadata to your SP Provider” and host it on a URL (optionally, you can send it to us and we can host this for you). Copy this hosted IDP metadata URL and set it as the Metadata url in SearchStax Cloud.

12. Now, set SSO to “Enabled”.

When you are testing, also check “Allow email password login” (You can turn this off once SSO testing is complete). Here is our example setting page:

Once set up is complete, the “Your direct Sign-In URL” is the URL that your team can use for signing into SearchStax Cloud. They can also enter the domain name mentioned when choosing Single Sign-On from the SearchStax Cloud Sign-In page.

Login Using SSO

On https://app.searchstax.com/ , click the “Sign-In With your ID Provider” button.

Enter the domain.

Click Continue. This takes you to the Okta Sign-in page. After you authenticate, it brings you back to your SearchStax Cloud Dashboard.

Alternately, you can directly go to https://<Subdomain>.searchstax.com to login, and clicking on the “Sign-In With your ID Provider” will take you directly to Okta Sign In.

SSO + Two-factor Authentication

A User can have SSO and Two-Factor authentication both setup. The 2FA settings for a user will apply to all accounts that the user has access to.

However, for the account that has SSO Setup, while logging in, SearchStax 2FA settings will not apply. In that case, 2FA should be set up at the SSO Provider.

The post Single Sign-On – Okta appeared first on SearchStax Docs.

The SearchStax Managed Search service now offers the ability for customers to set up Single Sign-On (SSO) using OneLogin to let their users log into SearchStax apps with a single ID and password that works across multiple software systems.

We use the open standard Security Assertion Markup Language (SAML) to allow identity providers (IdP) to pass authorization credentials to service providers (SP). This page provides instructions on how to configure OneLogin SSO with SearchStax.

SSO is an add-on SearchStax feature that is purchased separately. If you are interested in SSO for your deployment, please contact Sales.

The following steps explain how it can be set up for OneLogin.

Instructions

Once SSO is enabled by SearchStax for your account, the owner and/or admin can see options to set it up. The options to set up SSO are in the User Preferences screen of the Managed Search Dashboard:

The first option is the Single Sign-On subdomain. This is a label like mycompany, which the system will use to build a URL such as mycompany.searchstax.com.

Click Next to view the next page of SSO parameters.

The “direct Sign-In URL” is the URL that your team can use for signing into Managed Search. The other two URLs are discussed below.

1. Go to OneLogin administration dashboard and select the Applications drop down. Select Add App in the top right corner:
   
2. Now Search for “SAML Custom Connector (Advanced)” and then select the application:
   
3. Enter a display name for the custom SearchStax application – something like “SearchStax”. Feel free to customize the icon as well then click Save in the top right corner:
   
4. This creates a new Application in your user dashboard. Now go back to the applications tab still inside the administration dashboard and select your newly created application. You will see some new tabs on the left. Select the Configuration Tab:
   
5. This tab is where you will configure the SSO application with the information provided in our SearchStax dashboard. Since we used “mycompany” as our subdomain we will continue to use that here as well. Enter the provided metadata URL in the Audience (EntityID) box
   
   
6. Enter the provided ACS URLs into the Recipient, ACS Validator, and ACS URL boxes:
   
7. Enter the Login URL into the Login URL Box:
   
8. Be sure your settings align with what is shown below. This will be SP initiated, with a Persistent nameID, and both the assertion and response will be signed, then click Save in the top right:
   
9. Select the Parameters tab on the left. We expect Email, First Name, and Last Name to be passed so your parameters should look like the box below. You also have the ability to pass a “role” parameter. If you do not have a mapping for SearchStax roles, you can leave it as it, and the users will get created with Team Member as the role by default. These roles can always be changed later from the Managed Search Dashboard:
   
   
10. Next click into the SSO tab on the left. Take note of the Issuer URL and the SAML 2.0 Endpoint.
    
    You will be putting these values in the Managed Search dashboard as shown below. Click Save Settings when finished:
    
    

The steps below show how we have integrated it with our OneLogin instance.

Login Using SSO

https://app.searchstax.com/ now provides a button at the bottom for SSO – “Sign-In With your ID Provider.” Click this button.

Enter the domain that was set up for the client.

Click Continue. This takes you to OneLogin Sign-in page. After you authenticate, it brings you back to your SearchStax Dashboard.

Alternately, you can directly go to https://<Subdomain>.searchstax.com to login, and clicking on the “Sign-In With your ID Provider” will take you directly to OneLogin.

SSO + Two-factor Authentication

A User can have SSO and Two-Factor authentication both setup. The 2FA settings for a user will apply to all accounts that the user has access to.

However, for the account that has SSO Setup, while logging in, SearchStax 2FA settings will not apply. In that case, 2FA should be set up at the SSO Provider.

The post Single Sign-On – OneLogin appeared first on SearchStax Docs.

The SearchStax Managed Search service now offers the ability for customers to set up Single Sign-On (SSO) using PingFederate to let their users log into SearchStax apps with a single ID and password that works across multiple software systems.

We use the open standard Security Assertion Markup Language (SAML) to allow identity providers (IdP) to pass authorization credentials to service providers (SP). This page provides instructions on how to configure PingFederate SSO with SearchStax.

SSO is an add-on SearchStax feature that is purchased separately. If you are interested in SSO, please contact Sales or your Account Manager.

The following steps explain how it can be set up for PingFederate.

Instructions

Once SSO is enabled by SearchStax for your account, the owner and/or admin can see options to set it up. The options to set up SSO are in the User Preferences screen of the Managed Search Dashboard:

The first option is the Single Sign-On subdomain. This is a label like mycompany, which the system will use to build a URL such as mycompany.searchstax.com.

Click Next to view the next page of SSO parameters.

The “direct Sign-In URL” is the URL that your team can use for signing into Managed Search. The other two URLs are discussed below.

Note: Make sure you have an Adapter already set up inside PingFederate!

1. Go to PingFederate IdP administration console and select the Create New button underneath the SP Connections section:
   
2. In the Connection Type tab select the Browser SSO Profiles/SAML 2.0 Template then click Next. In the Connection Options continue with Browser SSO and hit Next again:
   
3. The next tab is the Import Metadata tab. You can choose to extract our metadata from the URL (shown in a screenshot above the instructions) in our dashboard and import it here, this will prefill some future sections for you:
   
4. In the General Info tab you will need to ensure that the following boxes have the correct information in them whether you imported our metadata or not.
   
   The Entity ID box should contain our EntityID which is also our metadata URL.
   
   Connection Name is whatever you want to use to identify this connection in your PingFed dashboard.
   
   Virtual Server IDS is important because it will overwrite your “master” EntityID and display a value in your metadata that we require to connect properly. This will also need to be in a URL format so something like https://sso-t.com/idp/SSO.saml2 is recommended.
   
   After this scroll to the bottom and click next
   
   
5. The next tab is where you will configure the Browser SSO settings. After clicking configure Browser SSO select SP-Initiated SSO and hit Next.
   
   We left the Assertion Lifetime settings as default and then hit next again.
   
   
6. Next we need to configure the Assertion Creation by clicking the Configure Assertion Creation button. Keep standard identity mapping and hit Next. In the Attribute Contract tab you will need to pass surname, email, and givenName in the assertion via the Extend the Contract sections and then hit Next.
   
   
7. Now that the attributes are created they need to be mapped. This is done with the Map New Adapter Instance button on the Authentication Source Mapping tab.
   
   Here you will select the Adapter you have configured for this connection and then hit Next until you come to the Attribute Contract Fulfillment tab.
   
   Here you will map your values to the email, surname, and givenName attributes being passed from your end, when finished hit Next and then the Done button until you see the Configure Protocol Settings button.
   
   
   
8. When configuring the protocol you will want to send your POST requests to the ACS URL provided in our SearchStax dashboard.
   
   It will look something like this *.searchstax.com/saml2/acs/ then hit Next until you arrive at the Signature Policy Tab.
   
   Here you will select the Always Sign the SAML Assertion box. Now hit Next again until you get to the Configure Credentials button.
   
   
   
9. Here you are selecting the valid certificate used in your signings:
   
   
   Now hit Next and review all the tabs that are presented. If everything looks good you can activate the connection and then hit Save.
   
   
10. When you are finished settings things up in PingFed you will need to come back to our dashboard and input the values of your SSO:
    
    
    We need your IdP Entity URL, as discussed above this will be your VSID that you configured specifically for this connection.
    The URL to your metadata.
    Then finally the Login URL used for this connection.
    Once the above is added you can select the Enabled box and hit Save Settings.
    
    

Login Using SSO

https://app.searchstax.com/ now provides a button at the bottom for SSO – “Sign-In With your ID Provider.” Click this button.

Enter the domain that was set up for the client.

Click Continue. This takes you to PingFederate Sign-in page. After you authenticate, it brings you back to your SearchStax Dashboard.

Alternately, you can directly go to https://<Subdomain>.searchstax.com to login, and clicking on the “Sign-In With your ID Provider” will take you directly to PingFederate.

SSO + Two-factor Authentication

A User can have SSO and Two-Factor authentication both setup. The 2FA settings for a user will apply to all accounts that the user has access to.

However, for the account that has SSO Setup, while logging in, SearchStax 2FA settings will not apply. In that case, 2FA should be set up at the SSO Provider.

The post Single Sign-On – PingFederate appeared first on SearchStax Docs.