Categoryokta

Introduction to this series and links to each entry are available here.

Guess its time to start studying for the Okta Professional exam 😉

Okta Basics Curriculum: Okta End User Support + Navigating the Okta Help Center (two courses)

We’re at the end of the Okta Basics training here – the last couple of lessons are about getting support and finding additional resources – I’ve been linking good resources as I’ve discovered them in the help centre and elsewhere, and I have a few others I’ll share here.

These last two lessons are pretty basic – resetting user passwords, resetting MFA, nothing special.

Okta has a toolkit they call the End User Adoption Toolkit that has some interesting resources for Okta admins and customers who are rolling the tool out to their users.

The toolkit includes: 

• Adoption Project Plan
• Key Roles and Responsibilities
• Success Objectives
• Communication Plans
• Communication Templates
• End User Training Plans
• End User Training Assets

The Okta Help Center at support.okta.com is easy to navigate, and there are TONS of resources in here to dig into.

They have a couple different ‘ask questions’ options – a question + answer page and a dev forum.

Last page I’d recommend bookmarking is the Okta status page at status.okta.com – always worth keeping an eye on if you’re experiencing any issues with your service.

Okta Basics Curriculum: Configure Universal Directory and User Profiles

Via Okta:
Many companies have multiple identity sources with different types of users, such as contractors, partners, customers, and acquired companies’ employees. 

Okta Universal Directory provides a single view across all these groups with AD and LDAP directory integrations and out-of-the-box connections with HR systems like Workday, SaaS apps like G Suite, CSV files, and third-party identity providers.

There’s a good architecture whitepaper here that is worth reviewing to get to know Okta’s directory integration better.

We’ve covered universal directory and creating user profiles in a few previous posts, but as a recap, Okta allows you to extend user, application, and directory-level profiles from various sources so they can be managed via Okta if the admins want to.

Okta Basics Curriculum: Protect On-Prem Applications with Okta’s Access Gateway (OAG)

The TLDR of Okta’s Access Gateway is that it allows companies to use SSO and MFA between cloud and on prem apps. The Access Gateway is a VM that can be hosted on prem or in the cloud, so it can live essentially anywhere in your environment that supports it.

Via Okta’s docs:

“Okta Access Gateway is a reverse proxy based virtual application, designed to secure web applications that don’t natively support SAML or OIDC. Access Gateway integrates with legacy applications using HTTP headers and Kerberos tokens, and offers URL-based authorization and more. You can use Access Gateway to seamlessly integrate your legacy web based applications with Okta’s Cloud Single Sign-On (SSO) and Adaptive Multi-Factor Authentication (MFA) services. And because Access Gateway is deployed behind the firewall, it lets external users access on-premises web-based applications without the need for traditional VPNs.”

There’s a 25 minute product demo in the Okta Basics training that is recommended viewing (note: no closed captioning per usual).

The user experience is meant to be seamless, so users shouldn’t notice anything different or special if they’re accessing apps behind the Access Gateway.

Okta Basics Curriculum: Configure O365 with Okta

O365 is Okta’s most common integration, and the app integration has evolved enough that you can use Okta to sync with existing O365 users, or to manage them directly.

How does the integration work at a high level?

Regardless of the provisioning type you will be using, Microsoft has 3 requirements: 

1. First, you must register your company’s public domain with your Office365 tenant. This is true for all implementations.
2. Next, you must check that your default domain is set correctly. Again, this is true for all implementations.
3. Finally, you need to prepare your directory. This is when you will decide if you will be using Microsoft provisioning or Okta provisioning. 

There’s a lot here – more that I can explain easily in a post – I recommend watching the Okta training videos and spending some time reading the guides if this is something that you’re going to be doing regularly.

Typical workflow for deploying O365

Overview of the integration capabilities

Okta Basics Curriculum: Enable Secure Access to Linux Servers with Advanced Server Access

Okta’s Advanced Server Access tool provides access management for servers, whether they’re cloud or on prem. Rather than keeping track of various passwords and logins for individual servers, Advanced Server Access essentially manages the identity piece and provides an alternative to manual logins.

Here’s their simple diagram of how this works:

This is actually an extremely cool feature, assuming it actually works the way they say it does. I’m going to recommend that people go through the Okta training for this piece because they do a better job of explaining it than I can here. Essentially, Okta grants a short-lived certificate and a client application installed on the users’ workstation initiates a secure session with the target server. The certificate expires in minutes and they self-revoke after use, so there are no concerns about credential theft and much less of an attack surface than normal.

Okta’s docs about Advanced Server Access has more information if you want to dig in further.

The video for this lesson also makes note of some cool command line options that Advanced Server Access offers as well – you have the option once you’re authenticated to see which servers you have access to, so you can just choose one without having to re-authenticate or log in directly.

The other obvious benefit of managing server access this way is that it makes things a lot easier to handle if one of your admins leaves the company – no need to reset a hundred passwords – once they’re offboarded in Okta, any potential access goes away.

Okta Basics Curriculum: Manage API Access with Okta
(note that I’m doing this one slightly out of order – the O365/Okta lesson is a beast so I’ll work on that one tomorrow when I have more time)

Some definitions/quick explanations to start here – I’ll be writing a lot more in depth about both of these in the near future, but for the sake of this guide…

API = Application Programming Interface
Loosely, this is a software integration that allows two different applications to talk to each other and share data. There are MANY reasons why people and companies might use APIs, but the primary reason is to enable better user experiences.

OAuth – Wikipedia says it best for this one –
“An open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.”

Okta identifies three groups that care about/manage APIs – developers, architects, and the security team. These three groups often have conflicting opinions on how much access should be given to the APIs and the data beyond.

The key to API security is to focus on least privilege – as with any data, it is essential that administrators focus on limiting access to only users who are authorized, and that their access is limited to only the data they need, for the least amount of time necessary.

Okta covers three different API security approaches –

1. Public APIs – no security
   Clearly the worst ‘security’ option – companies often aim for ‘security by obscurity’ in this case and assume that their public APIs will remain hidden if they don’t advertise their location, but anything on the public internet can be found and accessed with enough effort and motivation.
2. API Keys – better security
   API keys essentially create an authentication tunnel from one application to another – good for more secure access, but they tend to be all-or-nothing and do not allow specific permissions to be set depending on the user or partner application.
3. OAuth 2.0 – ‘best’ security (according to Okta)
   OAuth 2.0 tokens allow API designers to grant specific permissions to specific data. These tokens are also designed to expire, which helps limit and control the access.

Digital Ocean has a good in-depth technical guide to OAuth 2.0 if you’re interested in digging in further. Highly recommended.

Okta’s solution to these challenges is their API Access Management – this allows Okta to act as both the Identity Provider and the OAuth Authorization Server, so the full identity cycle is managed in one place.

From the dashboard, you can set up and configure your API Authorization Servers via Security > API

From here, you can switch to the Access Policies tab and define who has access to the API and how long that access should last.

There’s plenty more to learn about this piece of the Okta puzzle – looking forward to digging in further myself and figuring out how best to use this tool.

Okta Basics Curriculum: Implement Multi-factor Authentication (MFA)

A definition to start –

Multi-factor Authentication: An authentication method that uses two (or more) different types of evidence to provide their identity. The three most common authentication factors are:
a) something you know (passwords, etc)
b) something you are (fingerprint, iris scan, etc)
c) something you have (swipe card, software token, etc)

Okta currently offers four different types of MFA for users and accounts –

1. Soft token with Okta app – user authenticates with a tap on the Okta app on their phone or Soft token on mobile with Google Auth – user authenticates with a one-time-password (six digit code) from the Google Authenticator app on their phone
2. SMS authentication – user authenticates with a token that is texted to their phone or Voice call authentication – user authenticates via inbound phone call
3. Third party authentication – user authenticates with a third party app/token/fob (Yubikey, RSA SecurID, etc)
4. Security Questions – user authenticates (during account setup) with a security question that only they know the answer to (unless they tell everyone on Facebook while filling out a questionnaire)(note that security questions are not technically a second ‘factor’ in normal situations if the user is also using a password – both of these are ‘something you know’)

Multifactor options are under the Security tab in the Okta dashboard

Each option on the above page needs to be activated before they’re available as an option for users. Once they’re activated, you move on to the multi-factor enrollment policy, which will prompt users to enroll in MFA once it is enabled. Okta allows you to set different policies for different groups, if needed, and you can also decide which MFA factors are required vs optional.

The next step after MFA is configured is setting up an Okta sign-on policy. From Security > Authentication, you can set up new sign on policies from the ‘Sign On’ tab.

Once you add a new policy for a new group, you’ll be prompted to set up a rule for that specific policy – as you can see below, you dictate to Okta whether someone will be authenticated or not, depending on how they attempt to log in and authenticate. This rule also allows you to decide how long the session will last before the user needs to re-authenticate.

Okta also allows you to set sign-on rules for specific applications if needed – from the application’s profile page, click the Sign On tab. At the bottom of the page, the Sign On Policy can be added and built out with specific rules.

Okta Basics curriculum: Workflows: Automate Identity-Specific Tasks without code

Okta’s pitch here is that admins can automate workflows without needing custom scripts or code – essentially if/then statements, automated! Let’s see what this actually looks like…

First spot that Workflows come in handy is during user provisioning and deprovisioning – Okta gives you the option to automatically assign app licenses when a default account is created, or in my case below, suspend a user’s account if they haven’t been active for a certain period of time.

The usefulness of these workflows is of course to make onboarding/offboarding/role changes easier for the IT admins – the more automation, the less manual work they have to do, and the less risk of something getting missed.

Okta also has automation options for manual tasks that are not integrated into Okta – you can automate a ticket creation that instructs the IT admin to move forward with those manual tasks.

They also offer a neat feature that would have come in handy during my compliance days – you can schedule access changes for different timeframes for the same user. The example they use in the training is someone who leaves and has their access revoked, but still needs access to HR/payroll for tax purposes. Okta allows enough automation that access to that last piece can be revoked automatically after one year. Smart tool there, and helps eliminate the chance that that access could get missed or forgotten about.

Similarly, you can structure a workflow to allow temporary access and then revoke it automatically – useful for third party contractor management especially – which again helps eliminate the risk that someone will forget about the account and decommission it late.

Okta Basics Curriculum: Automate Lifecycle Management

User lifecycle management is one of the most critical processes in any organization – it impacts compliance, security, access management, data protection, and plenty of other things. It is absolutely critical that organizations find an effective way to onboard, manage, and offboard users, and ensure that their internal access fits their job role.

For obvious reasons, automating the onboarding and offboard process makes everything easier for everyone, especially the IT teams responsible for managing identity at an organization.

Okta offers some user provisioning options that helps make this process smoother. Not every application integration including provisioning options, but a lot of them do. They can be accessed via the application profile under the ‘Provisioning’ tab.

Once the API credentials are confirmed, you can move forward and configure the provisioning settings both from Okta to the app, and from the app to Okta, depending on what workflow works best for you. You can also configure the app profile to automatically deactivate users when their Okta profile is deactivated – this piece is obviously a great tool when it comes to compliance.

From the application page, you also have the option to assign the application to specific groups – this allows you to automate the assignment of applications to new users. As new users are added to groups, they will be given access to the same groups as others in their group, without the need to manually assign each application to each user.

Next item on the list today is learning about how the Application Integration Wizard works. This wizard provides assistance when you have applications that you want to integrate into Okta, but they do not exist in the Okta Integration Network.

Under the Applications menu, hitting the ‘Create New App’ button brings up the following pop-up:

From here, you can choose the appropriate option (only choose SAML 2.0 if the application supports it). The wizard walks you through the steps to set up the integration, allowing you to add a logo, determine the app visibility (visible outside your org or not), and then configuring the SAML or SWA connectivity.

Last item on the list is setting up the application self-service menu for your users. Kind of a cool tool here if it fits your organization – you can allow users to add apps to their Okta menu themselves.

This essentially allows administrators to build a custom app catalogue that users can choose from, and add as needed, without needing to get an Okta admin involved. This also allows administrators to decide if some apps need approval before users can add them.

So that’s the quick run-through of lifecycle management in Okta – as mentioned earlier, this is a huge undertaking for any organization with a lot of moving pieces, so it isn’t as easy as just adding all your apps to a pool and turning access on and off. That said, Okta does have features that help make the process easier.