In this episode of the Dogfooding Chronicles, we want to go into the basics, and navigate you through Okta IT’s own use cases at a high level, stepping you through our environment and processes. We want to orient you to understand why we make the technology choices that we do. Our hope? You find this information so helpful, you’ll use some of it in your own environment.

Let’s start first with the environment itself: 1700+ users, 7 countries, all SaaS, no data center, office centric populations, and 150 business apps.

Second, how do we get our end users into our Okta tenant? For that, we use HR-as-a-master, specifically, Workday-as-a-Master (WaaM). Using WaaM has significantly improved our NEO (i.e., new employee onboarding) process. How? Okta profile attributes can be directly mapped from Workday attributes, allowing them to be utilized by both systems and downstream assignments to Okta groups, populated by Okta Group Rules. Example attributes include Worker Type (e.g., “Full Time Employee” vs. “Contingent”), Location, and Department.

A day in the life of automation

Okta’s extensible attributes allow our IT team to setup birthright application assignments, best described as the tools you need to do your job on your first day of work. An example of birthright application assignments would be Office 365, Atlassian’s Jira and Confluence, Slack, and Box. Let’s look at a typical user: Brittany has just started at Okta. She is a full-time employee, based in our San Francisco office, on our Marketing team.

As a full-time employee based in San Francisco HQ, she is assigned geo-specific benefits apps and a collection of productivity apps. When she logs into Slack for the first time, she has already been added to all the marketing channels through Group Rules automation and Group Push.

Now let’s dive into how our users authenticate into the Okta platform. While we want to provide a frictionless authentication path for our users, we’re constantly walking a tightrope—weighing ease-of-use with a strong security posture.

One solution? The use of password policies. Our password policies are based on the resources our employees already have rights to, dependent on their group posture within Okta. And we love rules…. For employees that have access to Okta intellectual property or sensitive customer data, we enforce a longer character password length, strong complexity requirements, plus frequent password rotation for compliance.

Allowing trust through zero trust

For the rest of the company, we use a slightly less strict approach. These employees have a shorter character password length, and fewer password changing rotations, but we always enforce strong complexity requirements. So, how can we afford to relax our password policies for employees not privy to sensitive data? Our Zero Trust MFA strategy.

Securing our data is king for Okta, so all Okta employees must enroll in MFA the very first time they log into the Okta tenant. MFA provides an additional layer of protection from attacks like password phishing. Attacks on organizations are beginning to shift from targeting infrastructure to targeting people—it’s essential to protect Okta from those threats.

We offer our employees the opportunity to enroll in secure MFA options like Okta Verify and several WebAuthn options (e.g., Universal 2nd Factor, macOS Touch ID, and Windows Hello). These factors are paired with intelligent sign-on policies based on login context; think user, device, location, and network information. This gives Okta a high-assurance authentication solution while providing a strong level of defence against phishing and man-in-the-middle attacks. If you haven’t setup an MFA policy for your Okta tenant, start planning for it. There’s no better time than now.

Keeping your job and your hair

While the MO for some IT departments may be “just turn it on”, a lack of planning and communication can be disastrous. When it comes to organization-wide policy changes, simply turning the key can often lead to distrust and a major disconnect between IT and the rest of the company.

On this, I speak from experience…. The mix of communicating your changes and securing buy-in from your stakeholders can feel like herding cats into a bathtub. The tenant implementations I’ve listed above may sound straightforward but some of them have given me a gray hair or two. Do yourself a favor and consider the following tips before actioning on a new implementation:

1. Make sure that your front-line IT team is aware of any potential issues that could surface from your changes.
2. Loop in your executive leadership team, and follow up with a short e-mail containing a few bullet points of what to expect.
3. Communicate to the rest of the company through every possible channel (even if you use @here in your 2000-user IT Slack channel, and they don't read it! You're still letting them know why a change was made). Let them know what to expect, and provide ample time and ways to ask questions—it will save you time and sanity in the long run.

So, that’s a peek inside our environment, our implementations, and our grey hairs. We’re hoping this post has surfaced key methods you can directly use to optimize the automation and security of your Okta tenant, while keeping your sanity and security in check.

Missed a previous post? Don't ever skip a meal—read them all!

Introducing… The Dogfooding Chronicles

The Dogfooding Chronicles: Group Therapy—Getting All You Can From Okta Groups