User16370330549592969269 (Customer Support Online Experience) asked a question.
Did you know that Okta provides a self-service upgrade process that gives you complete control over protecting your apps and resources, helping you easily schedule and manage your org’s upgrade to Okta Identity Engine (OIE)? No matter where you are in your journey to upgrade, we’ve got you covered! Brent Arrington on the Product Acceleration team at Okta will answer your burning questions, from researching and remediating upgrade blockers to understanding and acknowledging warnings before scheduling your upgrade to new product features/functionality and UI/UX in OIE.
Ask questions from today to Wednesday, August 23, 2023. Please use the Answer button below to ask your questions.
Come back on Thursday, August 24, from 7 a.m. to 9 a.m. PST to join the online session as our OIE Product Expert, Brent Arrington answers your questions.
Want to learn more details about this AMA session? Check out this blog post --> https://support.okta.com/help/s/blog/a674z00000013xbAAA/aug-24-ask-me-anything-with-okta-identity-engine-product-team?language=en_US
Awesome news. Thank you, Leila. Can't wait!
Is there a step by step guide we can follow for all of our SAML apps? Also how does this affect okta verify and device trust?
Hi @Terry Hunt (Alpine Intel (formerly Donan)) !
For SAML app integrations, there should be no impact whatsoever. All of the changes in authentication flows in OIE are on the "front end" of the process -- i.e. in the authentication to Okta, itself. The way that Okta asserts identities into SAML apps (or OIDC, or WS-Fed, etc.) once the Okta session is established does not change, so no changes are required for your existing downstream app federations.
Existing Okta Verify functionality will also not be impacted at all by the upgrade. However, once you have upgraded to OIE, you will have the ability to enable new functionality in Okta Verify -- specifically, FastPass. For more details on FastPass, see this deployment guide or the recording of our "Password-less" webinar from the OIE Playlist of the Okta YouTube channel.
Mobile device trust must be disabled before you may proceed with the OIE upgrade, then re-enabled and configured post-upgrade. Desktop device trust can remain in place through the upgrade, and can be converted to the new, Okta Verify managed framework post-upgrade. For more details, see: https://help.okta.com/oie/en-us/Content/Topics/identity-engine-upgrade/dt-mobile-turn-off.htm and https://help.okta.com/oie/en-us/Content/Topics/identity-engine-upgrade/migrate-from-dt-to-fp-faqs.htm
Why is Okta disabled on Apple Watch? It was very convenient for logins. Are you planning to enable Okta on Apple Watch again?
Hi @hzdst (hzdst) !
I believe the decision to deprecate the Apple Watch app essentially came down to 2 factors: 1) it wasn't very widely used. (I know -- I can't believe it, either. That's literally the only reason I bought an Apple Watch). And 2) OIE introduces enhancements to Okta Verify centered around phishing resistance and biometrics, which were not supported on the watch.
I'm not aware of any plans to bring back the Apple Watch app, but I'm sure that could change if there is enough demand.
I DEMAND! I DEMAND!! 😉
Now that we can deploy custom authentication policies for our apps, what is your suggestion for best practice for the default policy that covers most standard apps?
Since policies are evaluated top down, we were thinking of having a whole stack of polices to 'catch' all the outliers that would require special rules: High Risk Behaviors, Medium Risk Behaviors, Off Prem, On VPN, etc. etc.
Is there a better way to go about it?
Hi @JasonA.21559 (Customer) !
Every situation is different, but a common pattern that we have seen work well for customers is to define policies around an "assurance level" model -- i.e. High Assurance apps, Medium Assurance apps, Low Assurance apps -- set Authenticator requirements/constraints, location, behavior, etc., criteria accordingly, and associate to appropriate apps based on sensitivity of the apps in question.
For a discussion & demo of what this might look like, check out this portion of our recent "Password-less" webinar.
Hmmm - I was more focusing in on a standard baseline for let's say medium assurance.
High assurance 'apps' = everyone has to pass muster (HR app with PII let's say)
Low assurance 'apps' = we don't care (bookmark app to public website)
What I'm focusing on is:
Med assurance 'apps' = most apps. Let's say like slack, gsuite, aws etc. etc.
We had the idea to have a stack of policies:
If the user has medium assurance (you used password + okta verify push) - you get in with an 8 hour session.
But let's say the risk for that logon was high? We'd want to lower the session lifetime and/or not allow email/phone authenticators. Maybe they get a 2 hours session.
What if the risk is high but they are onprem? Oh - they have a new phone/computer. That's ok, we trust them more, so they can use SMS as an authenticator.
We'd have to have quite a few rules, all tiered correctly. Plinko from TPIR comes to mind. The user bounce off all the policies until the get to the right one..
Special users/groups
1) restricted users = very strict rules
2) full access = very lax rules
High risk first
3) High Risk off prem = very strict rules.
4) High risk on prem = medium rules
All other risk
4) SMS/Question/Email = medium rules
5) Managed Device = lax rules
6) on prem = lax rules
Hi @JasonA.21559 (Customer)
You could certainly accomplish something like this. The details, as you noted, could get fairly complicated. At a high level, you would need to manage this using a combination of Global Session Policy and Authentication Policy settings, as the session time is governed in the Global Session Policy (though, you can set "re-authentication" requirements at the app level), along with specific Behavior detection, and specific Authenticator requirements/constraints, Device Assurance requirements, etc., are defined in the Authentication Policy (app level). It really warrants a full-on architectural/design session to do it well, but there is certainly the flexibility available to accomplish this in OIE.