I’ll start this blog with a bit of disclosure - the company I work for partner with Okta so of course it is in my company’s interests to promote them! That aside, this post is in no way affiliated with Okta or my organisation and is just my personal opinion.
I’m a big fan of Okta, both from an end-user perspective and from an administrator/security perspective and this post aims to illustrate some of the features of the solution and the problems it can help organisations solve.
What is Okta?
In Okta’s own words from their website…
“The Okta Identity Cloud is an independent and neutral platform that securely connects the right people to the right technologies at the right time”
In slightly less marketing speak (and with some significant generalisation) Okta provide a SaaS based platform that can help you provide single sign-on, account provisioning/deprovisioning, multi-factor authentication and more to your end-users. Whilst the solution is SaaS delivered, it can help secure both your internal and cloud-based apps and offers an intuitive end-user interface and a lot of flexibility.
With that in mind, let’s look at some common challenges organisations face and how Okta can help.
As organisation’s adopt more and more applications (which are often SaaS-based), users end up with a proliferation of usernames/passwords to remember which often results in weaker security such as users picking easy to remember passwords or re-using existing ones.
It can also be difficult for users to remember which applications they have access to and how to access them as they don’t necessarily have a single place to view them.
How Okta Can Help
Taking a username/password approach to application access is not a scalable or secure approach. Users end up struggling to remember credentials or just re-use existing ones. Solutions such as Okta can help provide true single sign-on for users, meaning they only have to remember the one set of corporate credentials to be able to securely access all the applications they are entitled to. To prevent reliance on user passwords alone (which is NEVER a good idea!) Okta also has the ability to natively provide 2FA such as push verification, OTP, SMS, phone and others. Alternatively, you can seamlessly integrate with your existing 2FA solutions such as DUO, YubiKey, Symantec VIP, RSA etc.
Okta acts as something known as an “Identity Provider” (IdP) and uses federation technologies such as SAML, OpenID Connect and WS-Federation to securely log users into applications, without needing to directly exchange usernames/passwords with the application being accessed.
The Okta solution provides an application portal where users can easily see everything they have access to. A screenshot of a simple portal setup is shown below.
Both of these tasks could of course be accomplished in-house by using something such as Active Directory Federation Services (ADFS), however this comes with it the typical overheads you’d expect with on-prem solutions such as server management, licensing, patching, monitoring etc. You would also need to open up inbound access to servers through corporate firewalls.
Unlike technologies such as ADFS, Okta can also help provide secure single sign-on where the end application don’t support federation protocols. Using a browser plugin, Okta can help effectively manage and secure credentials for sites that only support traditional login mechanisms. Which leads me to the next example…
Like most companies, you probably have a social media presence on platforms such as Twitter, Facebook or LinkedIn. Chances are this presence is managed by more than one person using a shared username/password.
How do you ensure the credentials are sufficiently secure but also usable? How do you track who has logged in when using shared credentials? What about the potential for a disgruntled employee who could cause significant brand damage before you’ve had a chance to rotate usernames/passwords after they leave?
How Okta Can Help
A lack of support for enterprise federation protocols brings with it a number of challenges. Fortunately, Okta offers options to help address this by way of an authentication method known as “Secure Web Authentication (SWA)”. Whilst not as secure as traditional federation technologies, it does significantly improve security over just sharing usernames/passwords directly with the end-users.
Fundamentally, the technology works by having a browser plugin that acts as a password manager. Okta administrators have the option to hide the credentials from the end-user so whilst they can login (after successfully authenticating into Okta - again hopefully with 2FA) they don’t know what the credentials are. Should you end up with a disgruntled employee (which hopefully you don’t) you can just revoke their access to the social media platform through Okta, without needing to disrupt access for the other employees.
The SWA feature provides a number of different ways to handle the credentials such as a single shared credential (useful for the social media scenario discussed), individual credentials set by the user and individual credentials set by the administrator (with a few other sub-options such as random and periodically rotating passwords).
The browser plugin also has the added bonus of being able to act as a password manager for other accounts the user may have which aren’t necessarily managed by Okta. Perhaps for example, employee’s own personal accounts.
Regardless of whether you use federation technologies already (such as ADFS) the chances are that you may still have to provision user accounts on a per-application basis and set them to use ADFS (this isn’t the case for all applications). If you have one or two applications, this may not be the end of the world. But what if you have 10, 20 or more. This adds a significant burden to your internal IT teams when setting up and decommissioning users.
If you don’t use federation technologies, then these issues are only going to be compounded. If an employee leaves an organisation and was using a traditional username/password - what happens if you miss account deletion across some of the applications? They still have access of course! And in my experience over the years, this is far too common.
How Okta Can Help
As well as acting as a single sign-on service, Okta can also take care of account creation/deletion across a number of different applications. Imagine you have a new-user joining, you just take care of adding them to the relevant groups (such as within Active Directory) - Okta will then reach out to the relevant SaaS APIs to create the accounts with the appropriate permissions. Likewise, if and when the user is removed from the group, or deleted from AD, Okta can connect to the relevant application and delete the account.
In years gone by IT have typically been responsible for joiners, movers and leavers from an IT account perspective. HR would typically be responsible for notifying IT, but it would be IT’s responsibility to action the request. This often suffers from issues such as backlogs due to bottlenecks, duplication of effort and the possibility of requests slipping through the net.
How Okta Can Help
With an increase in cloud-based HR systems such as Workday, there has been a shift in organisations as they move towards “HR mastering”. The HR team is typically the best placed in an organisation to say when people are joining/leaving or changing roles - so why duplicate effort and create bottlenecks by passing the request to IT?
With a solution like Okta, you can integrate with systems such as Workday to allow HR to control the creation, deletion and changes associated with user accounts. Okta can then take care of automatically creating the relevant accounts in Active Directory and across your SaaS application estate.
Okta is an extremely flexible and allows you to “master” from multiple sources as required. You can also map and rewrite attributes and pass them between your applications as you need. So, lets say your SaaS application needs five different attributes, three of those may be pulled from AD, and two may be pulled from Workday etc. This offers a more streamlined approach than having to manually add them all as custom attributes within AD when not really required..
Hopefully this gives you an idea of some of the use cases for Okta. This is by no means all that the solution does - it offers a lot of other features and gives you a lot of flexibility to define access policies (such when users can access applications, when they need multifactor etc).
If you want to know more on Okta or see it in action, then feel free to get in touch with me and I’d be more than happy to demo it.
2019-06-13 01:00 +0100