Appreciate the information in that post from @christianjm. Confirms the pattern of ids I’ve been seeing.
We came across an id that starts with “exk” but that’s not on the list. We pulled it out of the SAML request traffic while troubleshooting some problems. The application (ConnectWise screenconnect on prem) says we should use an Okta tile of type “bookmark” and keep the SAML tile hidden. The bookmark URL they say to use is contained in the SAML transaction and looks something like this:
We’re using Terraform, but I pulled down the SAML tile’s data from the Okta API and I don’t see this exk value anywhere, nor the very long SAMLRequest value.
What is an exk id, and any ideas where it comes from? It certainly looks like an id, especially since it ends with 4h7 as others do.
Any ideas where the encoded SAMLRequest value comes from? The documentation for the ScreenConnect application that says how to set up Okta[1] implies that this obnoxiously long URL is static. The base64 value (seems to) decodes into binary, so it doesn’t seem to be something ASCII/readable.
I don’t want to hardcode this crazy long URL into the Terraform, but if I can construct it by knowing the source of these values and could look them up, I would do it.
Isn’t that just the Sign On URL for the application? If you check in the dashboard, do you see the exk value in the SAML Metadata details section?
In TF, I think this ID is stored as the entity_key. Can you check if that lines up correctly?
I can’t say I understand why they don’t want you to use the app tile itself and to configure a Bookmark app instead. The normal app tile uses the App Embed link, which doesn’t even reference the entity key. I assume they are using the SAML SSO url instead so that the RelayState can be passed in, but I don’t know why they would expect you to hardcode the SAMLRequest parameter either…
Thanks for the quick reply. You’re right that in the Terraform data/attributes returned from the okta_app_saml resource, the entity_key field is a value that starts with exk. The ScreenConnect application’s metadata has a field entityID which is the URL they tell you to set for the okta_app_saml’s audience, destination, recipient, and sso_url.
This URL is in the form https://screenconnect.myorg.com/__Authentication/...uuid.../Login
I’m also not sure why they say to show the users a bookmark tile. It might be because when you use the SAML tile from Okta, you land on a page inside the SC application that’s basically blank and have to navigate the UI to something useful[1]. If you use the bookmark URL they say to use, you end up on a dashboard of sorts (only allowed to attach 1 image to this post).
While I was able to find the exk value in the TF output, I dumped the entire okta_saml_app and didn’t see a value that looked similar to the SAMLRequest string. I’m not thrilled about hardcoding that value anywhere, so the users might just have to live with the application’s goofy UI initial state.
I wonder if just adding the RelayState would be enough to get the users to land in the right portion of the application. RelayStates are intended to be used for deeplinking.
If you tack on only the RelayState parameter and value they gave to the .../sso/saml url, does that behave better than just following the .../sso/saml url without any parameters?
