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 (2FA) using the Google Authenticator. Navigate to the User Preferences > Two-Factor Authentication tab.

The setup procedure is simple. Click the Set Up Google Authenticator 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.

The SearchStax Managed Search service now offers the ability for customers 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). We use Microsoft Azure Active Directory to implement SSO for SearchStax.

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

The following steps explain how it can be set up for Microsoft Azure Active Directory.

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 Azure Active Directory. Select Enterprise Applications, and then click on “New Application.”
2. Now Click on “Create your own application.”
3. Enter a name for SearchStax application – say “SearchStaxManagedSolr”, and select the last dropdown “Integrate any application you don’t find in the gallery” and then click on the “Create” button.
4. This creates a new Enterprise Application. In the screen that appears, click on the link for Step 1 > Assign Users and Groups. Here you can assign which Users/Groups have permission to SearchStaxManagedSolr Enterprise Application.
5. Click on “Add user/group” and then follow up to add all the users of groups that you would like to grant access to.
6. Once you are done with Step 1, click on the “Get started” link for Step 2. Setup single sign on.
7. Now select the single sign-on method as “SAML.”
8. It now shows the screen to configure the SAML endpoints:
9. Click on Edit on Step 3, and change Signing Option as “Sign SAML assertion” and click “Save.” The option can be anything else too, but the same setting should then also be chosen in the Managed Search Dashboard in the SSO settings.
10. Click on Edit button for Step 1 > Basic SAML Configuration.
    1. Enter the “Metadata URL” that shows on your https://app.searchstax.com/admin/sso/configure/saml2/ page as Identifier (Entity ID). Remove any extra entries and make sure the “default” checkbox is checked.
    2. Enter the Assertion Consumer Service URL as the “Reply URL” as shown below.
    3. Click “Save.”
11. Set up Step 2 > User Attributes & Claims. Click on Edit.
12. Managed Search has roles defined. If your active directory has a field containing a mapping for those roles, click on “Add new claim” and assign “role”. If you do not have a mapping for Managed Search roles, you can leave it as it, and the users will get created with Team Member as the role by default. Those can always be changed later from the Managed Search Dashboard.
    
    As just an example, we are mapping user.jobtitle field as the “role” as shown below.
    
    The Unique User Identifier (Name ID) should be mapped to your active directory field that is the email for the users that will use Managed Search. In our case, the default user.userprincipalname contained the information.
13. Now back on the Managed Search dashboard…
    1. Set the “Metadata url” as the “App Federation Metadata Url” shown in Step 3.
    2. Set the “Login Url” as the “Login URL” shown in Step 4.
    3. Set the “Logout Url” as the “Logout URL” shown in Step 4.
    4. Set the “Idp Entity Url” as the “Azure AD Identifier” shown in Step 4.

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 Azure Sign-in page. After you authenticate, it brings you back to your Managed Search 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 Azure 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 – Azure AD appeared first on SearchStax Docs.

The SearchStax Managed Search service takes the security of your Solr search infrastructure very seriously. We have built-in industry-standard security at the level of the cluster, network and SearchStax Managed Search dashboard.

• Industry-standard security at the Solr cluster level and network level.
• Environments secured with SSL out-of-the-box using Solr basic authentication.
• Custom firewall rules to lock down search infrastructure to a whitelist of IP addresses.
• Two-Factor Authentication (2FA) to increase log-on security.
• Regular quarterly scans to identify and patch any Apache Solr vulnerabilities.

Contents:

• Cluster Security
  • Connecting to the Cluster
  • Solr Basic Authentication
  • IP Filtering
  • API Keys
  • SearchStax User Roles
• Activity Log

Cluster Security

You can lock down your clusters as described below.

Connecting to the Cluster

SearchStax recommends that you situate your application infrastructure in the same local network as your hosting provider (for example, AWS or Azure). 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.

Solr Basic Authentication

You can optionally enable the Solr Basic Authentication Plugin through the SearchStax Managed Search Dashboard. This restricts access to your Solr dashboard and demands authorization for query requests and index updates.

To enable the Basic Authentication plugin:

1. Select the desired Deployment and click the Security > Auth option in the menu tree.
2. Click the Enable button.

1. Click the Add User button.
2. Add a user, entering the username, password and role (see below). Click Add.

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

To disable the Authentication and Authorization plugin, click on the Disable Auth button and confirm the action. Disabling Basic Auth erases all Solr users. (Again, Solr services will be restarted.)

Solr Basic Authentication provides four user roles:

• Admin users have full access to the views and tools of the Solr Dashboard. They can query the index from an external location using a /select command, and they can load new records into the index using a /update command.
• Non-Admin users can enter the Solr Dashboard but cannot view or make changes to the collections.
  • Read users can query the index using /select.
  • Write users can add new records to the index using /update.
  • ReadWrite users can use both /select and /update.

IP Filtering

You can limit access to a Solr deployment to a list of IP addresses using the Security > IP Filter menu.

You can configure access for Solr+Zookeeper, Solr, and Zookeeper endpoints separately.

The addresses are expressed in IPv4 format, using the familiar dot-decimal notation. Ranges are specified using Classless Inter-Domain Routing (CIDR) format.

CIDR notation can be daunting, but note the following three examples of typical CIDR rules:

• 0.0.0.0/0 This rule permits unrestricted access to Solr. Any IP address whatsoever may connect, regardless of other filters you have added to the list. (SearchStax Managed Search will refuse to accept this value if you try to enter it for Zookeeper.)
• 64.118.123.159/32 This rule permits a connection from exactly one IP address.
• 64.118.123.0/24 This rule allows Solr access from any of the 256 IP addresses on a subnet.

The /n at the end of each rule is called the prefix length.

To limit access to a specific IP address or IP address range:

1. From within a Deployment’s details page, click on the Security > IP filter option.
2. Click on Add Row.
3. Add a specific IP address in the appropriate field. Note that SearchStax Managed Search can detect your computer’s IP address. Click My current IP to enter it automatically.
4. Select a service you need to limit access to (Solr+Zookeeper, Solr, or Zookeeper).
5. It is a Best Practice to enter your name or email in the label field.
6. Click Save changes.

To remove a filter, click on the X button and then Save changes.

API Keys

The Security > API Keys menu option exposes a table of the deployment’s API Keys.

SearchStax User Roles

Each SearchStax account is restricted to the Owner of that account plus any SearchStax users who have been granted access to that account by the owner. The additional users may be limited to specific roles at the Owner’s discretion. See SearchStax User Roles.

Activity Log

The SearchStax Managed Search activity log provides you with a list of all user actions within your account, including those of the SearchStax Support team. The list consists of a User column including email of the user who performed the logged change, his/her role, Timestamp of action in UTC, Action itself, Action detail and IP address where the action originated.

The post Securing Deployments appeared first on SearchStax Docs.