Single sign-on or SSO at its simplest is a technology that allows someone to log in to multiple applications with one single login. Many people are already familiar with this technology, having used or seen tools like “Sign in with Google” or “Login with Facebook”.

Anywhere that the user has leveraged Google, Facebook, Twitter, LinkedIn, etc. to log into an application or software that is not Google/Facebook/Twitter/etc. they’ve been using SSO.

Within the context of a business, employees can also utilize SSO. Typically this looks like one of two things:

The employee has an email address that is provided by Google (Google Workspace) / Microsoft (Office 365) and they're able to leverage “Sign up / Sign in with Google / Microsoft” buttons to sign in or authenticate.

The employee is directed to use a specific system to authenticate across multiple business applications. This is commonly done via tools like Okta, Azure Active Directory, or OneLogin.

One confusing (but often not all that important) thing that can sometimes happen, occurs when an organization is utilizing an enterprise SSO system BUT that same provider also has a social SSO option. Google is the most common use case.

If an organization is using Google Enterprise SSO but the application has a “Sign in with Google” button, it can commonly occur that an employee authenticates across two separate methods, depending on the day. Normally Google is smart enough to authenticate the user and pass them along regardless of the method used.

Simplicity. There are a lot of things that a business needs to watch out for internally. With SSO a business can control & manage all of the following in one single place:

It’s much, much easier to verify the right people can log in & have the right permissions when it’s all controlled and stored in one place. Instead of logging into 40 different applications and removing users every time someone leaves a company, with SSO they can merely update the user’s access in one place.

🚧 Single sign-on user attribute updates are not real-time updates. Real-time updates are only possible with Directory Sync. SSO updates a user’s information within Tactic only when they log in. If they haven’t logged into the system for a while, their information will be out of date. This can be problematic if an admin is relying on the updated information for things like inviting attendees to a meeting or creating desk restrictions.

At Tactic, we allow any organization to purchase SSO as an add-on to allow them the benefits described above. A lot of organizations won’t allow a company to purchase SSO separately – so many that it’s become known as the SSO tax. There’s even a website that’s been created to name and shame the companies that do this. We charge a nominal fee since ultimately we have built in costs with each new SSO connection we add.

To set up SSO, an organization will need three things:

🚧 Common email addresses like gmail.com, yahoo.com, hotmail.com, etc. will not work. These URLs must be URLs within your organization’s control.

💡 Note: If you do not see your provider, don’t worry. You may still be able to set up SSO via the generic “SAML” or “OpenId” options. You will need to check if your provider allows for generic SAML or OpenId connections. If so, you can use those options.

If you’ve gone through all of the portal setup steps and you’ve successfully tested the implementation, congratulations 🎉 You’re all finished.

If you ran into any issues, please reach out to our support team at “[email protected]” or by clicking on “Create Ticket” on the top right of the Tactic Help Center.

Now that SSO is all set up, any user that attempts to log in to Tactic with the email URLs provided will be redirected to authenticate on your enterprise authentication provider. Once successfully authenticated, they will be redirected to your organization’s Tactic dashboard.

The software industry really loves acronyms. Single sign-on just-in-time (JIT) account creation is a fancy way of saying that we support creating user accounts on their first login i.e. just in time.

We’re able to do this since theoretically a user authenticating within your enterprise provider account would mean the user in question should have access to Tactic– at least as long as your enterprise provider has been configured correctly.

This behavior is enabled by default. If you would like to turn this behavior off, please send an email to [email protected].

We're always adding to the list but currently the list includes:

First and foremost, send an email to [email protected] so we can get it added to our product roadmap! Also, that's why the "SAML (Generic)" option is on the list. If your provider has a SAML option, you can use the generic setup and it still should work. If you're seeing any funny business, again please reach out and someone on our team will try to help.

As long as SSO JIT is enabled and the user is configured within your SSO provider to have access to Tactic, an account will be created during the process of their first login. All of the data that your SSO provider gives to Tactic during this login process will be used to populate their account i.e. name, email address, etc.

Single Sign-On and Directory Sync are different features that can be purchased and used separately, but we always recommend using them together. SSO used separately means that users will be redirected to your enterprise identity provider to authenticate.

The downside is that many data attributes will not be passed automatically to Tactic AND any data attributes that may be passed will only be updated each time that a user is forced to manually log in i.e. if they check the “Remember me” box when logging in, that could be quite some time.

Directory sync is especially important if you are relying upon Tactic for features like desk, meeting room, or zone assignments being made to specific teams or users. Without having user accounts pre-created and team assignments being accurate, assignment to specific resources within Tactic will be impossible to achieve accurately.

Yes, though we typically discourage it. The onboarding process especially can be a little tricky for users since they'll need to receive an invite email, allowing them to create a password and essentially "claim" their pre-created account.

Not a problem. Send an email to [email protected] and we will manually deactivate the feature for your account.