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.05.1||2019.05.2 Production release is scheduled to begin deployment on May 28|
2019.05.3 Preview release is scheduled to begin deployment on May 29
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.
This version includes updated instructions to integrate Office 365 in your Okta orgThe Okta container that represents a real-world organization.. We've moved from the existing URL. Please update your bookmarks to Microsoft Office 365 Deployment Guide.
We have disabled the creation of new LinkedIn identity providers until further notice due to the upcoming LinkedIn API V1 deprecation.
The On the fly 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. addition for all supported browsers is re-enabled for all orgs.
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.
In alignment with Microsoft's End of Support for Windows Phone 8.1, Okta Support will no longer investigate issues related to version 8.1. Okta recommends that you advise 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. with eligible Windows Phones to upgrade to Windows Phone 10 as soon as possible.
The password policy soft lock feature for users of the Okta Universal Directory 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).
Starting with Okta Mobile 2.18, OMMAn acronym for Okta Mobility Management. OMM enables you to manage your users' mobile devices, applications, and data. Your users enroll in the service and can then download and use managed apps from the Apps Store. Managed apps are typically work-related, such as Box or Expensify. As an administrator, you can remove managed apps and associated data from users' devices at any time. You can configure policies, such as data sharing controls, on any of your managed apps. See Configuring Okta Mobility Management for more information. won't collect IMEI information for new users enrolling their Android devices using the Native Android enrollment type. This does not affect existing enrolled users, nor Samsung or Android for Work enrollments. For more details about Device Attributes, see the Devices page.
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 (firstname.lastname@example.org) 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 org-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.