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 selectSkip group assignment for now.Save your integration.
Once saved, navigate to the General Settings section under theGeneral tab. Select Edit.
In theGrant type section, deselect the option forAllow Access Token with implicit grant type. SelectSave 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):
Navigate to theGeneral 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 forResource Owner Password.
Select theClient ID from the General tab and save this value to a safe location. We will refer to this value as theOIDC Application Client ID in future instructions. This value will be used to configure Jamf Connect.
Assigning users to the Jamf Connect applications
Select theAssignments 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.
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 theTest button in the upper right corner of the window to test bothOIDC andROPG.
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:
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.
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.
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....
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 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?
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.
@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?
@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.
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.
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.
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