Category Archives: Security

Verifying Agents using Google Sign-in

January 22, 2018 | Categories: Call Centers, How To, Security | by Bill Zing

Besides using Single Sign-on to limit access to your Zingtree decision trees, a simpler way to do this is to leverage Google Sign-in to verify the identity of agents or employees using your trees. This is incredibly easy to implement. In short:

  1. Add a list of authorized agents to your organization using the My Agents tool.
  2. Enable Google Sign-in Verification in Zingtree.
  3. Make sure each agent is logged into their Google accounts.

For example, if you have added an agent identified as joe@gmail.com, if Joe is logged into his Google account as joe@gmail.com, he will have access to your trees. If Joe is not logged into his Google account, he will be prompted to do so.

Setup Details – Step by Step

Each agent must have their own Google account.

The Zingtree setup is all done from the My Agents area:

First of all, add your agents to your account as follows:

  1. Go to Account, My Agents.
  2. Click Add One New Agent or Add Multiple Agents.
  3. Finish the prompts to add agents. The agent logins must match their Google logins.

Next, click the Enable Google Sign-in Verification button.

When all is set up properly, your My Agents page will have a list of agents, and look like this:

Agent Portal Link

If your agents are using the Zingtree Agent Portal, a special link to the portal will appear at the bottom of the My Agents page like so:

Give this link to all agents using the Agent Portal.

Other Means of Access

If agents are using trees embedded into linked from a web page or CRM,  the login process will happen automatically.  There’s nothing else to set up!

Adding Agents via the Zingtree API

If your company has a central area to provision agents, you can add and remove programmatically them using the Zingtree API. See the agent_add and agent_remove calls.

 

 

| Comments

Configuring Okta Single Sign-on

April 17, 2017 | Categories: Integrations, Security | by Bill Zing

security-blog

If you’re looking for a way to get started with securing access to your trees via Single Sign-on, you’ll first need to have an Identity Provider to manage your logins. Okta is a great service – it’s easy to set up, and very popular.  This article will show you how to get Okta and Zingtree working together.

Set Up Overview

Configuring SSO requires Okta and Zingtree to share information with each other:

  1. Okta needs information about Zingtree.
  2. Zingtree needs information about Okta.

Once you have Zingtree and Okta successfully working together, you can limit access for authors and/or employees or agents.

For the setup, we recommend keeping two browser tabs open – one in Okta, and one in Zingtree.

Configuring Okta

To start, in the Zingtree top menu, go to Account, Single-Sign-on. You’ll see something like this:

 

You can switch between setup for Agents or Authors. Switch to Author setup by clicking this:

Switch back to Agent setup by clicking:

In the above screenshot, you can see the parameters (specific to your organization) to share with Okta. Let’s use this information to set up the Okta side:

  1. If you haven’t already created a free Okta account, do it now.
  2. Go to the Okta Dashboard.
  3. Click Add Applications under Shortcuts.
  4. Click Create New App.
  5. Choose SAML 2.0 as the sign-on method, and click Create.
  6. In the General Settings, give your application a name (like “Zingtree”), and click Next.
  7. Under SAML Settings, configure it as shown below.  For the Single Sign-on URL, use Zingtree’s Login URL. For the Audience URI, use Zingtree’s Entity ID.

  8. Click Next to finish the SAML setup.

Configuring Zingtree

Now, let’s get some information from Okta:

  1. In Okta, click Applications from the top menu, and go to Applications.
  2. Click the new Zingtree application we created.
  3. Click Sign on, then View Setup Instructions. Keep this page open in a browser tab.
  4. Now go back to the Zingtree tab, and click Edit Identity Provider Data.
  5. For the Zingtree Entity ID, use the Okta Identity Provider Issuer.
  6. For the Zingtree Login URL, use the Okta Identity Provider Single Sign-On URL.
  7. Copy the Okta certificate into the Zingtree certificate field.
  8. Click Save Identity Provider Settings.

Testing Your SSO Setup

Once you’ve set up your Identity Provider and Zingtree for SSO, you can test from Zingtree as follows:

  1. In Zingtree, go to Account, Single Sign-on.
  2. Click the orange Test Agent Login or Test Author Login button at the lower right of the page.

From here. you can test logging into Okta from Zingtree.  If you’re already logged in, the test will just return your email or another identifier from Okta.  If you’re not yet logged in, the Okta’s login screen will appear, and then you will be returned to the Zingtree SSO test page after logging in.

Enabling SSO for Agents/End-Users

Once everything is working, in Zingtree go to Account, Single Sign-on. Click Enable Agents:

Next,  you need to restrict access to each tree as follows:

  1. Go to My Trees, and select the tree that you want to require SSO login.
  2. Click the Settings tool, and you’ll see something like this:

  3. Check Require Single Sign-on (SSO) Login to Access.
  4. Click Update Settings.

Note: Once SSO is set up, any new trees created will have SSO required by default.

Enabling SSO for Authors

Once SSO for authors is set up and working, you’ll need to enable it as follows:

  1. Go to Account, Single Sign-on.
  2. Click Switch to SSO for Authors.
  3. Make sure Enable Authors is checked.

One More Step: You also need to add authors to your organization via Account, My Authors. They will not be required to use a Zingtree login to gain access, but this also validates them as a person who has access to your organization’s trees.

Configuring Okta for Embedding or Pop-up Overlays

By default, Okta doesn’t allow logins from iFrames. You can override this as follows:

  1. In Okta, select Settings, Customization.
  2. Make sure Allow iFrame Embedding is selected.

 

 

| Comments

How to Use Existing Login Credentials to Restrict Access to Decision Trees

March 9, 2017 | Categories: How To, Integrations, Security | by Bill Zing

security-blog

Some of our customers have asked for an extra level of security for their trees, such that only people authenticated via a corporate intranet can access it. This article shows how it’s done, for ANY login system on ANY intranet.

Universally restricting access is accomplished by having an internal server access the tree via a server-side include, rather than via a user’s browser via embedded code in the page. This means that all accesses of the tree come from a single corporate IP address or range. Zingtree has an IP filtering option for any tree, so it’s easy to restrict access and use whatever authentication processes are already in place on the corporate intranet.

The method described here can work with organizations using SSO (Single Sign On), or any other login system.

Here are the basics:

  1. Restrict access to your tree to just the IP address of your server(s). This is done via Zingtree’s Settings tool.
  2. Create a web page for the tree to display on your internal server. This page will include the necessary JS and CSS files to show the tree. Load your tree using a server-side call, instead of embedding it into an iFrame or linking to a URL hosted at Zingtree.com.

Examples

Here’s PHP source code for a simple server-side include.

See how this page appears.

Technical Details

The example above is written using PHP, but any server-side scripting language can be used.  Our demo is a template around which a URL for a tree can be loaded. This template contains all the CSS and JS files needed to display a functioning Zingtree decision tree.

Zingtree is built on top of Bootstrap 3, so the basic Bootstrap files are loaded.  There are a few custom controls as well included in the template.

You can swap out the PHP with Python, Ruby, Perl, or any other scripting language you choose.
Have any questions or comments about making your trees more secure? Talk to us!

Tags: , , , , , | Comments

Single Sign-On for Zingtree Decision Trees

January 8, 2017 | Categories: Business, How To, Integrations, Product Updates, Salesforce, Security, Zingtree News | by Bill Zing

security-blog

Zingtree supports Single Sign-on (SSO) as a means of restricting access to trees.  Many customers have sensitive corporate processes or procedures encapsulated in their trees, and ensuring these trees are accessible only to certain employees can be invaluable.

Single Sign-on can be enabled with separate login systems for:

  • Employees/agents/end-users.
  • Tree Authors.

Single Sign-on is a service provided by many vendors, including Okta, Microsoft (ADFS / Active Directory / Azure), Google (G-Suite), Salesforce and more.  These services are known as Identity Providers.  A single log-in through an Identity Provider gives a user secure, authenticated access to applications provided by Service Providers like Zingtree.

Once you log in through your Identity Provider, you don’t need to re-enter your login credentials. SSO is a very convenient way to secure access to your applications, while not burdening end-users with extra hurdles.

Zingtree supports any service that is SAML 2.0 compliant, which is a common standard.

Set Up Overview

Configuring SSO requires your Identity Provider and Zingtree to share information with each other:

  1. Your Identity Provider needs information about Zingtree.
  2. Zingtree needs information about your Identity Provider.

Configuring Zingtree for SSO

To start, in the Zingtree top menu, go to Account, Single-Sign-on. You can specify SSO for either Agents (employees or end-users) or Authors.

You’ll see the parameters (specific to your organization) to share with your Identity Provider. Here’s how agent view appears:

If you’re setting up SSO for Authors, click this button:

You can switch back to Agent setup by clicking this:

Configure your Identity Provider with these parameters.

Next, click the blue button to Enter Identity Provider Data into Zingtree. The following screen appears:

Copy the rest of these settings from your Identity Provider.

Click Save Identity Provider Settings when finished.

SSO just needs to be set up once for your organization.

Testing Your SSO Setup

Once you’ve set up your Identity Provider and Zingtree for SSO, you can test from Zingtree as follows:

  1. In Zingtree, go to Account, Single Sign-on. This SSO configuration screen appears:
  2. Click the green Test Author Login or Test Agent Login button at the lower right of the page.

From here. you can test logging into your Identity Provider from Zingtree.  If you’re already logged in, the test will just return your email or another identifier from your Identity Provider.  If you’re not yet logged in, the Identity Provider’s login screen will appear, and then you will be returned to the Zingtree SSO test page after logging in.

Enabling SSO for Agents/End Users

Once SSO is working properly from your test, you can restrict access to any tree as follows.

  1. From Account, Single Sign-on, make sure you are on the Agents page.
  2. Tick enable Agents.

IMPORTANT: You still need to specify individual trees to restrict access to. Here’s how:

  1. Go to My Trees, and select the tree that you want to require SSO login.
  2. Click the Settings tool, and you’ll see something like this:

  3. Check Require Single Sign-on (SSO) Login to Access.
  4. Click Update Settings.

Dedicated Agent Login

Rather than having Agents go through the Zingtree login page, you can send them directly to your SSO login page. Here’s how:

  1. Go to Account, My Agents.
  2. Give your agents the link from this button:

Enabling SSO for Authors

From Account, Single Sign-on, switch to SSO for Authors:

Make sure Enable Authors is ticked:

One More Step: You also need to add authors to your organization via Account, My Authors. They will not be required to use a Zingtree login to gain access, but this also validates them as a person who has access to an organization’s trees.

The rest of the setup for sharing information with your identity provider is identical to Agent Setup.

 

This article was originally published on April 4, 2017 and has been updated on January 8, 2018 to include enhanced SSO capabilities and improvements.

Tags: , , , | Comments