How To Configure Okta’s Flexible Security Policies For Your Environment
One of the nice things about working with Okta’s SSO (Single Sign On) platform is that even though they aren’t a tried and true security company, they have built a lot of security tools into their product. When leveraged correctly, these tools really help lock down employee access to enterprise applications and give the security folks at your company helpful insight into how employees access governed cloud services.
No matter how powerful the software is, though, if it is configured incorrectly, it poses a security risk. The most secure system is one implemented by a competent system administrator.
This guide will explain the different security policies in Okta — and, hopefully, help you become competent with Okta yourself.
Sign On Policies
Okta allows admins to configure sign-on policies at two points during the user experience. The first is initial sign-on to Okta when a user tries to log in to Okta directly from the http://www.w3.org/2000/svg\”>”); background-size: 1px 1px; background-position: 0px calc(1em + 1px); background-repeat: repeat no-repeat;”>https://yourdomain.okta.com URL, and the second is when they try to access an SSO application from their Okta end-user dashboard.
This means you have two places you could configure your MFA policies: at the front door, or prior to accessing specific applications. (I don’t recommend configuring your policies in both places, or doubling up, because there is nothing end users hate more.)
Let’s look at two scenarios and investigate how these different approaches might fit into your environment.
Scenario 1:
Company A
- 500 Users
- 2 Office locations with 200 employees apiece
- 100 remote users (contractors & sales)
- 5 mission-critical applications in Okta, nothing else.
Info:
Company A has been configured by admins to only allow SSO into 5 big-ticket applications, O365, Salesforce, Box, Tableau & AWS. All of these applications contain very sensitive information pertinent to the day-to-day operations of Company A, as well as a lot of valuable IPs.
How would you configure security policies for Company A?
There are a few ways you could approach this, but I’ll explain the approach that is the simplest while still being secure.
First, I would whitelist the external IP users inside Company A’s offices that will be accessing Okta. This allows these IPs to skip being challenged for Okta if they are operating from inside the office. Some people would contest that this is not secure, but unless the company has compliance requirements they need to meet (like MFA for all content-sharing apps), I generally try to leave the Okta user experience as simple and straightforward as possible.
This is especially helpful when introducing Okta to them for the first time. If users see Okta as a convenience, rather than a hindrance, Okta projects run much more smoothly.
The only other policy you would need to configure is the front-door policy for remote users. You can configure this under the “Security” > “Authentication” tab, and then under the “Sign-on” sub-tab. A front-door policy is the best policy here because configuring 5 separate policies for each app creates unnecessary overhead on the part of the user.
Lastly, I would configure a session timeout. This means that if someone‘s laptop were to get stolen, company information would still be secure.
Scenario 2:
Company B
- 50 Users, 1 office
- Startup company with a highly mobile workforce. Over half of the employees are remote
- 2 Apps, GitHub & Dropbox
- User self-service is active
Info:
Company B has been using Okta since its inception. Its employees use Okta to access Company B’s Github and Dropbox environments via SAML, but they also use Okta as a store for whichever apps they see fit thanks to user self-service. In addition to Github and Dropbox, they have added personal accounts to various websites and disparate email services to their end-user dashboards.
How would you configure security policies for Company B?
Since Company B is a startup and has yet to lock down which applications their employees use for official business purposes (outside of GitHub and Dropbox), I would recommend configuring MFA only for Dropbox and Github. These are the only applications that need to be secured from a company perspective, so it is more convenient to leave the sign-in to Okta free from MFA.
The central issue in this scenario is not really Okta security policies, but company policies themselves. Startups often use many different applications, most of which do not support sophisticated integration with Okta. Until Company B decides which services to officially support, they should just focus on putting MFA on their business-critical applications and leave the rest untouched.
If you as an admin are concerned about users adding MFA to their personal accounts, a better way of enforcing it is setting it up app-side. Applications like Twitter and Facebook have their own MFA. If you know your users heavily use the self-service features of Okta, a company-wide email about setting up MFA individually in these applications is a smarter move, because I know from experience if you don’t have these applications configured with SAML. You put an MFA policy on it, end-users will just navigate to the site’s regular login in order to bypass MFA.
In Conclusion
That’s it for now, configuring security policies in Okta can only hold my attention for so long and I’m sure any readers feel similarly. Thanks and stay tuned for more.
Check out some of Dark Rhino Security’s Okta Success Stories and Business Events
