Strange login issue with Okta and Self Service

[Louie]

I wanted to see if anyone else has or is experiencing this, we have a jamf cloud hosted instance.  So far jamf support has been unable to determine the cause of the issue.  When signing into Self Service, which uses Okta for us, instead of going into Self Service and seeing your available applications to you, it opens a webkit window of our jamf pro dashboard inside the Self Service app, if you don't have login rights to our console then the user gets access denied.  This is a screen grab from our dev enviroment, where the issue started happening first and then "magically" started occurring on our production instance which is on a slightly older version of jamf.  Of our identity team that manages Okta says they have made no changes.  I have tried turning SSO on and off for the instance, turning off SSO for Self Service and turning that back on, but it's still the same experience.  Both instances were working perfectly fine up until about week ago.

 

[Wakko]

@Louie have you gotten an answers or solution to this issue? Interestingly enough we are seeing this very same issue as well. We to are on a cloud instance, recently upgraded to version 10.41.0-t1661887915. Coincidentally, this started to happen to us right after the update.

Now what's even stranger is that if you close that SS window and relaunch it. This time around if you sign in it might work. We've seen instances of this working each and every other time. Or some times it just doesn't work at all. While other times, it work on the first try and each other try afterwards. We haven't found the root cause of as yet, but I'm submitting a ticket about this issue to see what JAMF says. If I get an answer I'll post it here.

[Louie]

Yes, finally support gave a workable option, i'll paste below what worked for us:

Some more information has come to light in the past 24 hours related to this.

- Two Engines -

In 2022, Okta introduced a new "Engine" for it's product.
The term "Classic Engine" now refers to the older version of Okta and "Identity Engine" refers to the current version.

Reference: https://developer.okta.com/docs/guides/oie-intro/

In the Okta Administrative console, a 'C' or 'E' is visible in the Version number at the bottom of both pages which helps to tell which "Engine" is in use.
"C" signifies Classic Engine and "E" signifies "Identity Engine".



- Identity Engine / Product Issue -

Those using the "Identity Engine" can encounter this Self Service issue by default.
Note that this issue is filed as Product Issue # PI110475

Here are some steps to take to work around this issue for those using the "Identity Engine":

1) Open the Jamf Pro SSO Application within the Okta Administrative Console
2) Select the 'Sign On' section of the settings for the Jamf Pro SSO Application
3) Edit those settings and locate the 'Default Relay State' setting
4) Set the 'Default Relay State' setting to the following value:
samlsuccess.jsp

5) Save the changes
6) Observe the results in the Self Service Application

[OwenCrote]

Ive just tried this after out okta instance was updated yesterday. get 404 error now. Got a support call open with Jamf at the moment

[cingalls]

Had the exact same issue in Fall 2022. Jamf support gave the same answer, so I can confirm this samlsuccess.jsp fix works

[nelsoni]

We also use Okta for our SSO and this has fixed the issue for us.

[mjgadient]

Just a heads up for anyone else running into this issue. In Okta, the above solution wasn't working for us as it required a forward slash prefix.  Once we changed the default relay state to "/samlsuccess.jsp" we were able to once more authenticate as expected.