Using Okta with OIDC/ROPG with Jamf Connect

[rabbitt]

Instead of using the Okta Authentication API, Jamf Connect can also use the Custom identity provider type with an application set up for OIDC/ROPG in the Okta tenant. This allows for granular application of Authentication Policies in the new Okta Identity Engine tenants.

Create App Integration in Okta

Navigate to the organization Okta administration page.  Select Applications → Applications and pick the Create App Integration option.

Select the options for OIDC - OpenID Connect and Native Application.  Select Next to continue.

Select a name for the App integration name.  In Grant type, select the options for:

• Resource Owner Password (this enables ROPG for ongoing password checks)
• Implicit (hybrid)

Scrolling down for more options, remove the default entries with the X option for Sign-in redirect URIs and Sign-out redirect URIs.  Enter a new sign-in redirect URI with the value https://127.0.0.1/jamfconnect

Optionally, assign users to the Jamf Connect application or select Skip group assignment for now.  Save your integration.

Once saved, navigate to the General Settings section under the General tab.  Select Edit.

In the Grant type section, deselect the option for Allow Access Token with implicit grant type.  Select Save in the bottom of the section to save the settings.

Navigate to the Okta API Scopes option. Find the option named okta.users.read and select the Grant option.

(Optional) Enable Groups in Identity Token

Navigate to the Sign On tab and select the Edit option on the OpenID Connect Token section.

Change Issuer to Okta URL ([your Okta domain]).  Change Groups claim type to Expression.  Set Groups claim expression claim name to the value groups and the input expression to one of the following options:

• To select all Okta and all on-premises Active Directory groups (if federated):

Arrays.isEmpty(Arrays.toCsvString(Groups.startsWith("active_directory","",100))) ? Groups.startsWith("OKTA","",100) : Arrays.flatten(Groups.startsWith("OKTA","",100),Groups.startsWith("active_directory","",100))

• For additional options, refer to https://support.okta.com/help/s/article/Can-we-retrieve-both-Active-Directory-and-Okta-groups-in-Ope...

Use the Save button to save changes.

Navigate to the General tab and copy the Client ID value to a safe location.  This value will be used to configure Jamf Connect in a later step.

(Optional) Creating a second application to apply multi-factor authentication policies to the Jamf Connect login screen

Repeat the process above to create a second application.  In the General tab, navigate to General Settings, select Edit.  Deselect the option for Resource Owner Password.

Navigate to Security → Authentication Policy and select or create a policy that enforces your organization requirements for multi-factor authentication.  Note that as of the date of these instructions creation (15DEC2022), macOS does not support hardware authentication tokens (FIDO2, Yubikey, USB based hardware tokens) at the login screen with wkwebview, also known as WebKit.

Select the Client ID from the General tab and save this value to a safe location.  We will refer to this value as the OIDC Application Client ID in future instructions. This value will be used to configure Jamf Connect.

Assigning users to the Jamf Connect applications

Select the Assignments tab.  Users can be assigned to the Jamf Connect application either individually or through group membership.  If you are using the optional second application for enforcing MFA at login, make sure the membership assignments match for both applications.

Security settings

Okta Identity Engine applies login policies in two ways:

• Global Session Policy - Applies a high level requirement to all logins for a group of users, regardless of the application.  This was used in Okta Classic engine to enforce MFA for Jamf Connect logins.
• Authentication Policies - A very granular set of rules that can be applied to an individual application.

With Identity Engine and Jamf Connect as a Custom OIDC app, create a security policy that:

• Global Session Policy:
• Allow for the use of a user name and password for authentication

• Authentication Policies:
• A password only policy to allow for silent non-interactive background check of the password.  If using one app, apply this to the Jamf Connect application created in the first step.

• (Optional) If using two applications to enforce policies at the macOS login screen, create a policy with your organization requirements for the login screen.  Apply this policy to the second application which does not have the resource owner grant applied.
• Avoid policy requirements that require the device be a managed device or a registered device.  Keychain items to validate this requirement may not be available at the login window.
• Avoid policy requirements that check for a device compliance state.  If a device is out of compliance, a user could not log into the machine to get the device back into compliance.
• Do not allow for the use of hardware authenticators like FIDO2 tokens.  Hardware authenticators cannot be used by WebKit as of the writing of this article (15DEC2022).

Use Jamf Connect Configuration to test configuration

Download the latest version of Jamf Connect from your assets located at account.jamf.com.  In the Jamf Connect software disk image package, copy the Jamf Connect Configuration application to your Applications folder on your Mac.  

Open the Jamf Connect Configurations app and create a new configuration.  If this is your first time creating a configuration, a new config is created by default.  If not, use the + in the lower left corner of the window to create a new configuration.

Identity Provider: Select Custom

OIDC client ID: 

• If you have created two applications, use the second application Client ID where the resource owner grant is not selected
• If you are only using one application, use the Client ID you recorded in the first step.

OpenID connect scopes: Use the value openid+profile+email+groups

ROPG client ID: Use the Client ID you recorded in the first step.

OIDC redirect URI: Use the value https://127.0.0.1/jamfconnect

Discovery URL: Substitute the name of your Okta tenant in the following format

https://[your Okta tenant like org.okta.com]/.well-known/openid-configuration

Note: Do not use the domain that contains a -admin like organization-admin.okta.com.  This is the URL for your administration page, not your Okta login page. 

Test the configuration.  Use the Test button in the upper right corner of the window to test both OIDC and ROPG.  

A successful OIDC test will appear like the following:

The decoded ID token field is a scrollable text box.  Use this to determine if the groups you expect have been sent in the token:

A successful ROPG test will appear like the following:

[rastogisagar123]

Very well articulated!!

[vmalapati_mu]

Very well documented article. Can we get same for the JC + Azure?

[rabbitt]

The Azure instructions are located at https://learn.jamf.com/bundle/jamf-connect-documentation-current/page/Integrating_with_Microsoft_Azu...

Instructions for using Jamf Connect with Azure and setting up apps that will work with Microsoft conditional access are located at https://github.com/jamf/jamfconnect/tree/main/azure_conditional_access

[dvasquez]

Excellent. I have not looked at Okta in a while but I could easily use this doc. 

[arajabzadeh]

this article was amazing , Thanks , we are not using the okta yet but we will soon 

[eckermike87]

Has this guide changed at all with version 2.22 stating the configuration tool supports Okta OIE now @rabbitt ?

[rabbitt]

Jamf Connect Configuration in version 2.22.0 has some preview features for Okta Identity Engine and future releases of Jamf Connect with the Okta Authentication API.  That being said, there may be upcoming improvements for Okta as and OIDC app in Jamf Connect as well as more features around Identity Engine.

You can use Okta and Jamf Connect in its standard config with no changes needed - Jamf Connect has always supported Identity Engine tenants.

And you can continue using Okta as a custom OIDC provider with no problems too!  Did you know the difference between picking your IDP and custom is just Jamf Connect automagically determines the Discovery URL?  Azure, OneLogin, Ping...  they're all the same as picking Custom as long as you define the Discovery URL manually.

[rabbitt]

Yes, keep using “Custom” as the provider – the new Okta Identity Engine option in Jamf Connect Configuration is still in preview and there’s more changes coming for Okta.

The trick for ANY identity provider is that ANY of them can be set up as a “custom.” The advantage of picking your specific provider (Azure, OneLogin, etc) is that Jamf Connect automatically calculates the Discovery URL. When you pick “custom” you simply need to define the Discovery URL explicitly.

[dandorato]

It seems in OIE with IDP MFA JAMF connect is unable to find the IDP MFA factor

@rabbitt 

[MrBombadil]

Does anyone know if JC 2.25 | Okta OIDC support Authentication Passthrough?  I have been struggling with getting this to work with Okta OIDC.  A few have mentioned via Mac Admins channel that this is a feature request but Jamf support has mentioned that it does work with Auth Passthrough and Okta OIDC. Scratching me head....

[rabbitt]

Yes, passthrough authentication works with Okta as an OIDC application as of 2.21. I’ve personally tested it with the identity provider listed as “Custom” and defining the Okta discovery URL, but I’ve not personally tested it with provider set to Okta-OIDC yet. If you’re seeing issues with it set to Okta-OIDC, open a support ticket.

[MrBombadil]

Ticket was opened a few days ago have a meeting with Jamf today to discuss.  I will keep this thread updated.

[wlew]

@MrBombadil I've been looking to configure this Okta OIDC for exactly the passthrough auth. Did it work for you and if so, do you mind sharing what needs to be set in JC and Okta? 

[dandorato]

I have the latest version of Jamf Connect Configuration but there is no documentation on hoe to configure it properly for OIE.  Currently using a "Custom" provider but looking to see how to properly configure for OIE.

[spuriousthames]

@retro bowl I've been looking to configure this Okta OIDC for exactly the passthrough auth. Did it work for you and if so, do you mind sharing what needs to be set in JC and Okta? 

[pmac789]

@rabbittCould you please share the configurations for your global session policy and authentication policies? I'm uncertain if the new Okta Identity Engine (OIE) is impacting users' systems, particularly in cases where they use a recovery key to unlock and are then directed to the standard Okta login. At this stage, we're encountering issues where users receive an "invalid username or password" error. Currently, our only workaround is to enter recovery mode and reset the password from there.

[MrBombadil]

Sorry for the delay guys. We ended up ditching JC and going with Okta Device Access (Desktop Password sync).. Not as feature rich as JC but it fits our needs better than JC. 

I did get the issue figured out there were a few settings in Okta clashing that I had to change, it’s been a few months and now I can’t remember what the setting was. 

[rabbitt]

Scroll back up in the article and search for the phrase “With Identity Engine and Jamf Connect as a Custom OIDC app, create a security policy that:” and you’ll find the documented global session policy and authentication policies.

It sounds like you’re running into something else – you want to reset the local password to a known good value before you try to log back in with Okta to re-sync the passwords. Instead of using the recovery key to unlock the drive, use the recovery key and recovery mode to reset the password first.

Follow the OPTION 3 in the Apple KB article here: https://support.apple.com/en-us/102633

Once the local password is set to a known value, THEN log in with Jamf Connect.

Remember too that if you’re using Jamf Connect with Okta as an OIDC app, you’ll be

* Prompted for your Okta user name and password
* The Okta password won’t match the local password
* You’ll be prompted for this new local password you set when you reset the password in recovery mode
* Jamf Connect will update the local password to match the Okta password

[pmac789]

Thanks @rabbitt 
what are your settings for the global session policy for Okta? I see you have two rules there.