Use this page to learn about general changes to the AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Console, feature updates and deprecations, end of support for certain components, improvements to certain areas of the Okta platform, as well as other items that may not be tied to a particular Okta release.
|Production||2019.07.0||2019.07.1 Production release is scheduled to begin deployment on July 22|
2019.07.2 Preview release is scheduled to begin deployment on July 31
After December 31, 2019, Okta will end support for all Okta products on Android operating systems versions below 6.0. Accordingly, Okta recommends that you direct your end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. to update their Android devices to a supported version (6.0 or higher) before that date.
For more about Okta-supported mobile operating systems, see Okta-supported versions of Apple and Android operating systems.
Dates and Impacts
- October 9, 2019, no new releases: After this date, Okta will no longer release new features to Android OS versions below 6.0. We will continue to maintain existing features and provide bug fixes.
- December 31, 2019, end of support date: For all Okta products, after this date, admins will not be able to submit support cases for issues or bugs for problems occurring on Android OS versions below 6.0.
Okta products will continue to function on Android versions below 6.0, but end users will not be able to reinstall or upgrade Okta Mobile or Okta Verify until their device is on a supported version. After Okta support ends, Okta expects no immediate change to the existing end-user experience. New users on unsupported Android versions will not be able to view or download Okta apps from the appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. store until they upgrade to an Okta-supported version of Android.
To streamline user access to Okta web resources (Okta Help Center, Okta Learning, Okta.com), the sign-in and self-registration experience for these resources is now enhanced and unified. The user can use their existing Okta credentials to access these resources without having to fill out the registration form again. Users who don't yet have an Okta account can create their credentials using the self-registration process to access these resources. For more information, see knowledge article: Okta services sign-in experience.
To enhance the user experience in navigating between various Okta content sites and the findability of content, the Okta Product Documentation site and the Okta Help Center site are now enhanced with a common navigation bar and an enhanced Search feature. For more information, visit this Knowledge Base article.
We have disabled the creation of new LinkedIn identity providers until further notice due to the upcoming LinkedIn API V1 deprecation.
Okta has transitioned our PagerDuty integration to use the new v2 API and no customer impact is expected. PagerDuty is in the process of deprecating its v1 API and will cease support for it on October 19, 2018. Any existing v1 API keys and newer v2 API keys will continue to work with the new v2 API. There is no action required from customers to switch to v2 API, and we expect your existing Pagerduty instances to continue to work seamlessly. For more information, see PagerDuty Dev Platform. For more information about PagerDuty provisioning, see the PagerDuty Provisioning Guide.
Please be aware that Okta will now present informational banners to all orgs in the Admin Dashboard. While Okta presents such banners to most orgs already, Okta selectively withheld such banners from certain orgs for various reasons. Okta uses these banners to communicate information such as planned maintenance and product upgrades.
The System Log API is now Generally AvailableGenerally Available features are available to all orgs automatically according to each customer's SKU. You don’t need to enable them in the console or contact Okta Support.. Developers of new projects are strongly recommended to use this in lieu of the Events API.
The password policy soft lock feature for users of the Okta Universal DirectoryUniversal Directory enables you to store an unlimited amount of users and attributes from applications and sources like AD or HR systems. Any type of attributes are supported including linked-objects, sensitive attributes, and pre-defines lists. All of it accessible by all apps in our OIN catalog, over LDAP or via API. product has been reverted for users who received it automatically as part of the 2017.36 production release. Password policy soft lock is retained for organizations that requested it as an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. It will be released as a Generally Available feature at a later date.
When a work profile is configured on an Android O device, Google Chrome is automatically installed. This prevents Okta Mobile and other apps that use web views from crashing due to a bug in Android O. See the Google documentation of the bug for details.
We sent a communication to all customers on May 17, 2017 announcing that it is imperative that all customers using SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. Authenticators for Confluence and Jira, and SAML Toolkit for Java, upgrade to the latest versions by June 19th.
Under our responsible disclosure policies, we are now ready to release more information about the vulnerability, to keep our customers informed. In the Java toolkit, which is used by Confluence and Jira Authenticators, we were validating the SAML signatures cryptographically; however, we were not validating the SAML XML Signature profile. This in some cases allowed a user to log in to Confluence as another user. Due to the nature of the vulnerability, Okta is not able to determine if the vulnerability has been exploited in a customer’s environment. However, we’ve received no customer reports of any malicious activity due to this vulnerability. As of May 16, 2017, this vulnerability has been fixed in all the GA, EA, and Beta versions of the Confluence Authenticator and SAML Java toolkit.
In alignment with the Atlassian support end of life policy, beginning July 15, 2017 Okta will discontinue toolkit support for all versions of the JIRA and Confluence On-Premise app versions that are more than two years old. When Atlassian discontinues support for a given version of the app, Okta Customer Support will no longer investigate issues related to the Jira/Confluence on-premise versions that are classified as End of Life Status by Atlassian. Likewise, Okta will deprecate Okta toolkit versions that only support deprecated Jira/Confluence on-premise versions.
For example, since Atlassian released JIRA 7.0 in October 2015, they will end of life support for JIRA 7.0.x in October 2017. Accordingly, Okta will discontinue support for the Jira on premise toolkit version 2.0.0 in October 2017.
To determine when Atlassian plans to discontinue support for a specific version of a JIRA or Confluence On-Premise app, see the Atlassian Support End Of Life Policy page.
Note: Your End of Life status version of the JIRA On-Premise app will continue to work with deprecated versions of the Okta toolkits. However, if you experience any difficulties, Okta strongly recommends that you (1) switch to a newer version of the Jira on premise app, and (2) download and install the latest SAML toolkit and necessary JIRA toolkit from the Dashboard (Settings > Downloads).
As of 05/05/2017, Okta no longer supports the Oktaadmin@okta.com e-mail alias and it is not monitored, therefore the alias no longer appears on the footer of the end user dashboard page.
To ensure your end users have a technical contact listed on the footer of their Okta dashboard, we recommend you change the technical contact to an admin within your organization as soon as possible. For more information about the technical contact setting, see the Account online help topic.
Effective July 17, 2017 Okta will be automatically removing System Log data older than 6 months. This pertains to application generated system logs available via /api/v1/events, /api/v1/logs, or Okta SDK (EventsAPIClient). Note that this 6 month log retention is only applicable for existing Okta customers. (Moving forward, log retention length for new customers will be 3 months per our Data Retention Policy). For the full data retention policy, see our Okta Data Retention Policy.
Customers wishing to retain their system log data for longer than 6 months can export the data to a SIEM (preferred method) or download their data from the old System Log user interface prior to the data removal date - here's how.
When is this happening?
June 7, 2017: Removal of the system log data older than 6 months on the Preview Sandbox will occur on June 7, 2017 as part of our 2017.23 release. After this date, System Log data from more than six months prior will no longer be accessible via the System Log interface, Okta API, or via SDK.
July 17, 2017: Removal of system log data older than 6 months on Production Cells will occur on July 17, 2017 as part of our 2017.28 release. After this date, System Log data from more than six months prior will no longer be accessible via the System Log interface, Okta API, or via SDK. Please make plans to export or download any Production data you wish to retain prior to July 17, 2017.
If you have any questions about the above security policies, policy changes, or have trouble retrieving your data, please reach out to Okta Support (email@example.com) and our team can assist.
The telephone number from which SMS messages are sent is changing in Okta Preview. SMS functionality, including multifactor authentication, is unchanged.
We are making orgThe Okta container that represents a real-world organization.-wide rate limits more granular and treating authenticated end user interactions separately. More granular rate limits lessen the likelihood of calls to one URI impacting another. Treating authenticated end user interactions separately lessens the chances of one user’s request impacting another. We’re also providing a transition period so you can see what these changes look like in your Okta System Log before enforcing them:
- We enforce new rate limits for new preview orgs. For these new orgs, the API calls exceeding the new rate limits return an HTTP 429 error.
- In mid-May, we’ll enforce these new rate limits for all preview orgs. Instead of alerts in your System Log, the API calls exceeding the new rate limits will return an HTTP 429 error.
As of May 8, we have enabled a System Log alert which lets you know if you have exceeded any of the new API rate limits:
Warning: requests for url pattern <url-pattern> have reached a threshold of <number> requests per <time-duration>. Please be warned these rate limits will be enforced in the near future.
In mid-May, we’ll enforce these new rate limits for all newly created orgs. For these new orgs, instead of alerts in your System log, the API calls exceeding the new rate limits return an HTTP 429 error.
In early June, we’ll enforce these new rate limits for all orgs, and instead of alerts in your System Log, the API calls exceeding the new rate limits will return an HTTP 429 error.
For a full description of the rate limit changes, see API Rate Limit Improvements.