Jamf Connect x Okta | Integration Troubleshooting

[fdeltesta]

Hello,

We recently acquired Jamf Connect, and in the process of testing in before deploying it, I'm facing a bunch of problems. And I'm having trouble finding solutions, so here I am.
This is supposed to be some sort of a all-in one SSO-like solution, but man the more I get to know it and discover its limitation, the more I fear that it will simply overwhelm our end users. The workflow is absolutelly awful.

Let's start with what we have now:
Users have their own mac book pro, they are admin of course because "they should be free to do whatever they want, we tolerate personal usage". Yeah right. The disk are not encrypted with filevault since, well, no excuses. We never did it.
But not we're on the verge of the next security step in our organization, we're defining the actual IT charter, and the information system security policy (yeah we don't have any of those at the moment).

So basically users are used to to what they want, install what they want, type one password for their local account and that's all. (Yeah well, they also lose every other password, so that at least one good point for JC).

What we want to do for the users' computers:
-> We want to implement Jamf connect so they only need to care about one password: their only identity will be provided by the AD through Okta and Jamf Connect.
-> We want to start using filevault since it's a additionnal layer of security, aaand thanks to the GDPR: We. Must. Encrypt. Data.

So far so good right?

Ok, first of all, we are using Okta as IDP which gets the users from our on prem AD. In okta we'ave defined that our users needs to authenticate with MFA. As a start I used Push notifications for my lab.
Then, here are the problems and question I have that I can't get the answer by myself. (Yeah, let's be honnest, I'm generally rather lazy but now its a matter of deadline):

Concerning Jamf Connect "Login":
-> Since we We want use FileVault then, users will now need to enter twice their password, one for the disk encryption and one for the session (and the MFA). I though the login was supposed to keep the password from the decryption and try to use it for opening the session but, nothing happens. I think there was some sort of pref key that allows you to disable this automatic process, but can't find it anymore.
Though, my guess is that we're force to re-login because the MFA is needed? Meh, at least the credentials should be autofilled and we'd just be asked for the MFA. Anyway, what I'm missing here ?

-> Since our users are kindergarteners, they will forget their only password. Cause of course, with the new security policies comes a password policy, duh. So they won't be able to use their 3 character passwords anymore. 8 or 12 is definitely too much for them. Where I'm getting at is, that when a password is lost, well we can reset it in the AD, then okta gets it, ok we can finally login, but of course, this doesn't change the local password, once connected you need to sync it by typing the password you lost. So basically, not only we have to reset their password cause they are idiots, but we will also have to intervene on their macs cause we need to locally reset their password as well. What am I missing here again ? What is the proper workflow for when a user forgets his password ?

Concerning Jamf Connect "Menu Bar" (formerly Sync/verify):
-> I can't get my hands on what is missing, when trying to change password from the menu bar, I get the following message : "Configuration file does not specify default realm" I assume this as something to do with the AD, but isn't it supposed to simply push that to Okta, and then it does the rest ?

-> Also, when changing the password through the local account settings, when Jamf Connect asks for a sync, it actually takes the okta password and overwrite the local one. Ok, i'd get it if this was intended but the documentation let you think that's the other way around. Any clue ?

-> We actually need to re-authenticate here, I though once the local session is finally opened using JC login the "token" would be passed down to the manu bar app. Well, it kinda does, the credentials are pre-filled, but we need to re-validate the MFA. Is this what's causing the problem ?

-> When connecting to the Okta login page (for exemple) with safari(and the okta extension), before the 2.0 update, it used to automatically ask the menu bar app for the token, then automatically authenticate. (I mean, ask for the MFA, obviously). But now simply nothing happens. And I won't even talk about other browsers, right?

-> When opening the user session the menu bar app actually doesn't show up in the menu bar even if it's started. (Guys? It's in the name.) Only shows up once we solicited or manually launched. Bug or normal behaviour ?

-> And finally when login through the menu bar app, well the pre-filled credentials are used and then it waits for the MFA. It waits for the MFA yes, but why, why won't you display it ? I can already hear the users' complaints.

Sorry for venting, but this is giving me nightmares.
How are we supposed to provide our user an actual SSO like experience, and security without such hassles ? Can anyone enlighten me while I'll have to tell my manager this is definitely not ready for production.

TLDR; I'm starting to think Jamf connect does not provide the single sing-on experience as it advertised to. Especially if you want to respect data and privacy protection policies. The actual workflow of all this is definitely too complicated for our end users.