Bringing Okta to Massdrop
By Aaron Zander, Sr. IT Administrator
Massdrop, like many young startups, was running IT via in-office-crowd sourcing when I arrived. As with many startups, they used a variey of SaaS and cloud products, Google Apps, Office 365, Slack, Github, Asana, Atlasssian Cloud, etc. Setting up a new employees took about an hour for basic tools and had to be done in a specific order. Shutting down exiting users was even harder as tracking down all the logins and apps a user had access to amounted to the digital version of a 2 hour Dog the Bounty Hunter episode. Like most small companies there was no directory to connect to, no Active Directory, and no LDAP; the closest thing was Google Apps.
Zombie users roamed free through our SaaS apps and presented some significant potential security risks as well as a lot of confusion. None of this was something that would be considered isolated to Massdrop, lots and lots of companies have these issues, small and large.
These issues are often overlooked by many organizations. Thankfully given the experience of our dev leadership team in similar environments, they knew we needed to change all of this and we needed the change to happen soon. That’s where I stepped in; having just recently completed a Single Sign On Install project for 1000+ person company, I knew what it would take to get this going.
Single Sign on aka SSO as described by Redditor munky9002
Without single sign on: You walk into your office, sit down, put in a password to log in. You open Outlook and it prompts for username and password. You open IM chat app and it asks for username and password. You log into your business app and it asks for username and password.
Lets be realistic — every single time you prompt for password the user hates you 0.01% more and has a 0.05% increased chance of forgotten password.
With single sign on: I walk into my office, sit down, put in a password to log in. I open outlook, IM, business app in 3 clicks and they are all open.
Changing how a company fundamentally does anything is hard enough, but on the scope of implementing a new SSO provider, or in this case a full identity provider like Okta, into an environment with no directory or password conformity is tremendous and terrifying. That said, I believe everything in this post could be done entirely by a tech savvy individual, and not an IT professional.
Unlike my previous company which only needed to create a connector to its existing Microsoft Active Directory, Massdrop had several requirements:
- End-to-end solution for managing users.
- Access control for external apps and tools
- Allow targeted access to internally created tools
- A strong, well documented API
- Integration with BambooHR
- Multi Factor Authentication on demand, or all the time depending on the user.
With checklist in hand I started reviewing about a half dozen SSO providers and quickly narrowed it down to Okta and OneLogin. OneLogin had long partnership with BambooHR; but Okta had the better API, the better GUI, and a better support model. With that, we signed the contract with Okta, and began prepping for launch!
Integration and Execution
With Okta purchased, BambooHR coming online any day, and a list of business critical apps, it was time to create a plan of attack.
With the help of the development team at Okta, we set up the fledgling BambooHR tools and imported all of our users into Okta. Bamboo would serve as our feeder for employee info for Okta, and Okta would serve as a functional directory.
A series of emails explaining the new processes were created and every one was invited to Okta. A time was set to cut over Google to Okta authentication.
At 12:01am on a Wednesday night, Okta went live for Massdrop. When navigating to any Google App sites or services, users would no longer authenticate with Google, but with Okta. A few users who ran into issues, but nothing serious and the cut over was quite smooth.
More and more apps were added in and I started adding rules and guidelines based on departments and titles according to who had access to what.
Creating a user was becoming easier and easier. Shutting one down was just a few clicks.
We were able to insert Multi Factor Authentication into the system, easily and automatically, based on apps, or departments. Every engineer, finance, HR, and executive employee would automatically be enrolled in MFA. The goal was to prevent most threats to the organization through password theft. We settled on giving users a choice between SMS, Google Authenticator, or Okta’s Verify App.
How Our Integration Works
At 12:01 in the morning the day the user is slated to start, Okta will recognize a viable user for import on it’s first sync of the day (every 60 minutes). This kicks off the below flow, automatically interpreting nickname, primary and secondary email address, department and job title.
Okta enables SAML authentication for a wide variety for apps, such as Reflektiv, Atlassian Confuence and Google Apps, which we happily use. We’ve configured those apps to trust Okta SAML tokens, Okta provisions users into those apps, so we’re sure there’s no new passwords involved and those apps will only accept users that are active in Okta. We also leverage the continued use of Google authentication into apps like Slack, Asana, and Meraki’s wifi. This forgoes the need to manually add users to separate databases for each of these tools, and instead allows the user to casually set up the tools with out the need for a new password, or other registration. Through out it all, Okta securely allows the other applications to access its user authentication database meaning the Okta username, and Okta password are used in all the other applications as well. Change the password in Okta, it changes everywhere. For all other other apps that don’t support SAML authentication, Okta has various ways to push an auto-generated password to those apps and automate single-sign on with that password. Either way, it’s super-easy to use Okta with an extensive number of SaaS apps, whether they use secure authentication schemes such as SAML or not.
At this point Ted is totally setup, and I haven’t touched a single thing. I don’t even need to know he’s starting except to make sure he has equipment.
A few years later Ted decides he’d rather start his own research company and fight his own battles. So he leaves Massdrop. Here’s own the termination flow works:
- Ted puts in his two weeks to his manager/HR
- HR sets a termination date
- On the day, Okta polls his account info and begins shutting things down
- His google account is suspended and placed into our Suspended user OU
- His Slack account automatically goes deactivate
- His wiki access is cut, as are any access to any other tools.
I never have to lift a finger. Because Ted authenticates into all of those systems through Okta, even if his accounts were still active, he cannot get to them. It’s a great system, it helps prevent zombie users from walking around going all walking dead on our security.
What once took 1 person a combined 3 hours to do, now takes no one only a few minutes.
All of these rules and automations are setup not with complicated terminal commands, and long scripts, but with a simple to use GUI, problems are promptly resolved through Okta’s support, and more importantly as a sole or no IT person shop, there’s some one there to help if you don’t have some one. If, down the road you get Active Directory, or LDAP, or anything in-between you can connect Okta to these and feed it user data. That’s actually a step we’re moving towards to help us defeat AWS’s notoriously terrible ACL.
Again, while we have no direct need for LDAP, there is a plan to implement one to better deal with Amazon’s poor integration for SAML, and to create better tiered security to VM’s. This will also feedback into several other systems that can use LDAP to pass user data.
In the end, there’s a lot bringing a Single Sign On platform like Okta can do for your company. Big or Small, tech heavy or not, tools like Okta make your company safer, your jobs as IT or surrogate IT professionals easier, and most importantly, at least in my mind, it makes the day to day life of your employees better. The cost is well worth it, usually calculated per-user/per-month, the cost of not being secure, and the time lost in user setup can quickly outstrip the small monthly fee you pay your identity provider.
We were able to move quickly because all of these rules/automations are set up not with complicated terminal commands and long scripts, but with a simple to use GUI. If down the road we get Active Directory, or LDAP, or anything in-between we can connect Okta to these and feed it user data.
Overall we are very happy with this Okta rollout — our company achieved a massive security upgrade while reducing stress for both users and our IT department.