Authoralexntaylor

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.

Okta Basics Curriculum: Managed Application Single Sign-On (SSO)

Today we start digging into Okta’s capabilities – we’re going to walk through setting up integrations to allow users access to applications using single sign-on.

Okta offers three different ways to set up SSO authentication:

1. Secure Web Authentication (SWA) – Okta uses a browser plugin to securely pass credentials into a web form on behalf of the authenticated user
2. Security Assertion Markup Language (SAML) – XML-based standard for exchanging authentication and authorization data – SAML allows Okta to create a secure connection to an application or service provider and essentially builds a bridge of trust between the auth provider and the service provider (this is commonly used for SSO whether you’re using Okta or another identity tool)
3. WS-Federation – Commonly used with Microsoft applications and works the same general way as SAML does

SAML is a BIG topic that deserves more research if you’re interested – Duo has a fun blog post here that covers the essentials that you need to know.

Today we get to dive into the Okta Integration Network (OIN) and start choosing some applications that we want to integrate into our Okta environment. You can find this in your dashboard via Applications on the sidebar and then clicking ‘Add Application’.

As you’ll see, each application has details under the logo about what integration options are available, and you can dig into each app to see more information about the integration capabilities offered.

You’ll also see integration properties in the OIN which gives you information about who built out the integration – some are Okta-built, some are community-built.

So how do we configure an application using SAML? So glad you asked.

Select the app you want to configure for SSO, and then hit the blue Add button to kick the process off. Depending on the application, you’ll be presented with a list of general settings and options to fill out before you can finalize the integration.

Some applications will offer different options for setting up the integration – Salesforce as an example offers SWA and SAML and Okta admins can decide which works best for their organization.

Its important to follow the service provider setup instructions that are linked – every app is going to have a different process for setting up SAML and you’ll want to make sure that everything is copy-pasted correctly for the integration to work.

How do we configure an application using SWA?

SWA applications are typically used to connect applications such as LinkedIn or Facebook. The beginning of the process works the same way – search for the application or website in the OIN and follow the steps. If you’re using different accounts for different teams, remember to add a clear application label so you can tell them apart (Marketing vs Sales etc).

SWA integrations need the Okta browser plugin to be installed on the users’ computer – that linked page has a lot of information about installation, security, and use cases for the plugin.

Some of these applications will allow you to set a shared username and password – this is useful for shared access to a corporate social media account or things like that.

Some applications will also provide the option to set account mapping – Here’s what the Facebook setup looks like:

Once the integration is set up and configured, you can assign these SWA integrated apps to certain users or groups, and they will see them in their Okta profile once they log in.

Okta Basics Curriculum: Integrate Okta with LDAP-Mastered Users

Continuation here from the previous day – instead of AD, we’re going to learn how to integrate users from LDAP.

What is LDAP?

The Lightweight Directory Access Protocol is a vendor-neutral application protocol used to maintain distributed directory info in an organized manner. LDAP stores this data by way of records which contain a set of attributes. Each entry has a unique identifier (a ‘Distinguished Name’ most often seen as ‘DN’).

As with AD, LDAP-Mastered users are authenticated against the external directory, so they log into Okta using the credentials they use for LDAP. Generally, these users cannot change their password within Okta, but Okta Super Admins do have the power to enable this if needed.

Okta has an LDAP integration guide here for further review. We’ll go through most of these steps below. Also worth reviewing is the LDAP integration prerequisites page.

Okta offers an LDAP agent for Windows or Linux and the agent needs to be installed on a server that is on at all times – Okta needs to be able to access this agent regularly. One difference from the AD agent is that Just-in-Time provisioning is automatically enabled with the LDAP agent, which means that users will automatically be activated and updated when they log into Okta.

The LDAP Agent can be downloaded from the dashboard via Directory > Directory Integrations and the install wizard does most of the work.

Ensure that you log in with Super Admin credentials during the permissions pop-up.

Step 2 of the LDAP integration is configuration of the directory mappings. You’ll have the opportunity to select an LDAP version template – this will populate the appropriate fields and you’ll have the opportunity to choose the Okta username format you prefer.

Okta provides a ‘test configuration’ button – you’re looking for a Green box with ‘Validation Successful’ – if that shows up, you’re good to move forward.

That’s all you need on the integration side of things – Your users are free to start activating their accounts by logging into Okta with their LDAP credentials.

Okta Basics Curriculum: Integrate Okta with Active Directory-Mastered Users

For folks brand new to identity, some background research will be needed at this point – you’re going to need to understand the basics of Active Directory and how it works.

Active Directory is a Microsoft directory service that manages computers and other devices operating in a network. Users accessing a similar database may be grouped into a single domain. A group of domains is referred to as a tree, while a group of trees is called a forest.

Active Directory is a huge hulking beast of a topic and there’s plenty that I don’t even know about it – I’ll eventually write a separate series about AD as I level up my skills on that side of things, For now, just know that Active Directory is a directory service, and we’re going to import users from AD into Okta.

The key difference between directory-mastered users and Okta-mastered users is that directory-mastered users will authenticate against the external directory’s password policy, which is maintained by the directory administrator. Generally, these users can’t use Okta to change their directory password, although Okta super admins do have some power to make that change.

Okta manages the Active Directory integration with an agent that you’ll need to download and install on a Windows Server. The agent wizard does most of the work – you’ll provide all the information needed about your Okta service account and the agent will build the API.

Once the agent installation and setup is complete, you’ll be prompted to select which Organizational Units you want to import into Okta, and then you’ll be prompted to select which attributes from AD you want to include in your Okta User Profiles.

Once all of the above is complete, the integration process is essentially done – from here, you can begin importing users from Active Directory and building out their identity profiles in Okta. Manual confirmation and activation is an option, but you also have a few options – you can implement Just in Time provisioning, which creates and activates Directory-Mastered accounts as the person logs into Okta, or you can set up scheduled imports.

That wraps up things up for today – tomorrow we’ll learn about importing LDAP-Mastered users.

Okta Basics Curriculum: Manage Okta-Mastered Users

There are 3 types of people or user accounts that can exist within Okta:

• Okta-Mastered people
• Directory-Mastered people
• and Application-Mastered people

The lesson today is about Okta-Mastered people – people who are created directly within Okta (not imported from a different tool or database).

You can add new people manually from the Dashboard via Directory > People

There are 4 attributes that are associated with an Okta-Mastered person’s account which are required: first name, last name, username, and email address.

More information in the Okta Help Center here if you’re looking for additional documentation about user creation.

There’s also a guide here about user account states to help you understand what each state means (Active/Locked Out/Suspended etc).

You can also create Okta-Mastered users with a CSV import – Okta offers a template that you download and fill in and then re-upload – you can’t add custom attributes to the base template, but you can add these fields via the user profile once they exist in the Dashboard.

Last step for this lesson is learning how to add admin rights and roles to users – from Security > Administrators, click Add Administrator and Okta gives you a pop-up with options for admin roles you can assign to your user.

The training course also includes a spreadsheet with full information about each of the admin roles and what permissions each of them have – recommended download to get insights into which role each admin actually needs.

Good start to the training. Tomorrow we’ll learn more about importing users from Active Directory.

Okta Basics Curriculum: Introduction to Workforce Identity

Today’s course is a good overview of why IT teams need tools like Okta – it covers a number of different scenarios including new hires and role changes that require access and permissions changes. Nothing much to comment on for this one, but a recommended watch if you’re new to Okta.

Today we’re going to sign up for an Okta developer account which will allow us access to an Okta dashboard and give us some practice using the tool. You can create a free account here and its a simple process to sign up.

Once you’re signed up and logged in, your Dashboard will look something like this:

Nothing else needed for today – we’ll start digging into adding users tomorrow.