First post in a long time: I’ve been silly busy learning lots of non Apple related stuff. However there does seem to be a need for a how to guide of sorts on how to implement Jamf’s new SSO requirements.
Back in the day, you set up a SAML integration from your IdP to Jamf Pro. Access group of users on one side, Jamf user accounts on the other and you called it done.
Jamf is changing how all this works. Instead of an integration per app, they are replacing everything with one OIDC connection from your IdP to their Jamf Account page. Every single SaaS app you then get from Jamf will then already be enabled for SSO, you just have to put the accounts in place. Essentially authentication becomes a once and done and the gating is done on the application side.
Any other speculation as to intent from Jamf here I think is complete hogwash.
Before I get into the technicals I do need to point out a major caveat. This removes IdP initiated login entirely.
Once you implement this then you and your technicians will have to navigate to a specific webpage per Jamf product and enter your email address. That (assuming you don’t already have a valid access token in your browser) will then direct you through the SSO process and allow/deny access.
Here’s what you are going to need access to, or have teams you can liaise with to get this all working.
- Jamf Account with administrator access
- DNS of your external domain to register it
- Administrator access to Jamf Pro or other Jamf products that you use
- Sufficiently high access to your IdP to implement new integrations. (Okta in this case).
I am going to assume you already have a Jamf ID married to a Jamf Account for your organisation. Start by logging in here with your Jamf ID.
Jamf Account Domain Registration
We will start by registering your company domain with Jamf Account. Anyone who’s done this for services like Apple Business Manager or various Google services will be in familiar territory here.
Go to Organization -> SSO in the portal and you should get a screen that looks like the above. Click on the Domains button to start the registration process.
Enter the domain name to register here and click Save.
This will give you some instructions. Either log into your DNS portal, or talk to the team that does DNS records and put the TXT record into your record. Wait for it to sync. I know it says up to 72 hours, but with things like AWS Route53 I’ve never seen it take longer than 10 minutes.
Click Verify when ready. Jamf will check for that record and validate your domain. You can remove the txt record at this point as this is a one off check.
Jamf OIDC app setup
This is where you’ll have to juggle your Jamf Account and your IdP admin windows. In this example, i’ll be using Okta.
Start in this case by creating a new blank OIDC app in Okta.
Choose OIDC – OpenID Connect and Web Application.
Okta will ask for more information. This is is covered here: https://learn.jamf.com/en-US/bundle/jamf-account-documentation/page/Okta.html
Essentially you have to configure your Sign-in redirect URIs with the appropriate URL for your location. For me this was the us address. The Sign-out URI needs to be https://account.jamf.com/logout
In the General tab, you’ll need to copy out the Client ID and the Client Secret. You’ll need these on the Jamf side soon.
For Assignments, best if you only assign yourself for now for testing. You can easily replace this later when you’re ready to go live.
On the Authentication tab, we should configure that so Okta should not send group information over so we don’t overload the OIDC token. Set the Issuer to Dynamic, the claim type to Filter and groups claim filter to blank. The Jamf documentation goes into more depth than this if you do need groups.
Jamf Account Connection
You’re ready to take the details from this new app and make a new connection in the Jamf Account portal. Organization -> SSO -> New Connection.
Important: Jamf gives you a choice of integrations here. I did this with the Generic OIDC one so we could potentially in the future have group access. There is a specific Entra and Okta one but I didn’t use these. Read the docs, your mileage will vary.
Give it a name, then paste in the Client ID and Secret from your IdP. The Issuer URL will need to match the URL you sign into your IdP with. If you use a CNAME for Okta, use that rather than the original URL that Okta gives you.
The Scopes at the bottom are very important for Okta and this frankly isn’t well documented. I have them ringed in green but essentially (no quotes) they are “email openid profile”. Doing that disallows group access from Okta. Other IdPs will vary but this is what works for me.
To finalize the level of access required, scroll down the page.
It’s quite important that you attach the domain you verified earlier to this connection. Or it won’t work. Just click the Assign tick box to do so. After that it’s just a matter of tick boxes to enable which of your services you are allowing access to.
At time of writing, you can only allow ONE domain per connection. It’s not possible to have multiple integrations feeding towards individual apps from the same domain. One registered domain, one connection. I went pretty wrong here and that cost me a week of change control cancellations and re-approvals.
Testing
Let’s assume you have all this now set up. You have one user scoped on your IdP on this new app (yourself), and you’ve only enabled this on your sandbox Jamf Pro instance. Does it work straight away? Nope! We have to enable it on that too!
Log into your Jamf Pro server. Go to Settings -> SSO and grab the failover address just in case.
Check ALL the settings on this page, especially the stuff about mapping of users. When you’re feeling brave, click Edit and change the authentication method from SAML to Jamf Account.
My advice at this point is to leave this browser window alone. Do all your testing from a different browser entirely or an incognito type window.
Go to the URL for your Jamf instance. You should get a window that looks similar to this:
Enter your email address, click Continue and Jamf should take you through your SSO process.
IF that has worked, you are ready to change your scoping on that OIDC app to everyone. Obviously don’t include groups with service accounts and the like. All the authentication happens via the new app, but access control is now gated entirely from inside the various Jamf App(s) you have.
Aftermath
Let’s be clear here, after all this effort to get to Jamf’s new SSO platform it really kinda sucks we can’t just have a tile to click on anymore. I have made this point to my account reps, and obviously something like that will take time to develop.
There is a workaround for now. Okta Bookmark apps.
Okta thankfully gives the ability to just have a tile that opens to a specific URL and that’s exactly what I’ve created for our products. These have groups attached so that only users who’ve been granted access can see the tile. It’s not ideal but it does take most of the sting out of this.
To create bookmark tiles in Okta, go to Applications menu and click on the Browse App Catalog button.
Search for Bookmark App, it’ll show up quickly. You can then create a tile with the appropriate icon and URL then scope appropriately.
I hope this helps the people who read this. I know it’s caused a lot of hassle and confusion out there, so anything that smooths waters is good.
Best of luck!