Categoryokta

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.