|Production||2018.12.0||2018.12.1 Production release is scheduled to begin deployment on December 17|
2018.12.2 Preview release is scheduled to begin deployment on December 27
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 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. 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.
Okta has temporarily disabled this feature in Preview orgs for all supported browsers (Chrome, Edge, Firefox, and IE). We plan to re-enable this feature to all orgs in a few weeks.
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 feature by the IE plugin has been disabled temporarily, but this will be addressed soon. UsersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. wishing to add apps on the fly through the plugin can still do so on Chrome, Safari and Edge.
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.
Firefox plugin version 5.15.3 is now GA for all orgs.
This version provides support for the latest Firefox WebExtension framework. There is no UI impact for customers; however, they must have this version installed as of Firefox version 57 (released on November 14, 2017).
Note: When the Okta plugin version 5.15.3 is installed, Firefox version 53 or earlier does not support single sign-on to apps through Basic Authentication. If you have any questions or concerns following the upgrade, contact Okta Support. For version history, see Browser Plugin Version History.
This announcement is a follow-up to an earlier communication about changes to the iOS 11 native Mail app for Office 365 (O365) affecting customers who selected either Profile Sync or User Sync provisioning when setting up an O365 WS-Fed app instance in Okta. While testing the Beta version of iOS 11, we discovered an issue in which iOS devices that have been upgraded to the latest operating system and configured with a new Exchange profile in the native Mail application continually prompt users to return to Okta to authenticate approximately every 2 hours. Fortunately, by working closely with the Microsoft team, we have fixed this issue in time for the iOS 11 release.
What this means to you if you are using Okta to provision and authenticate (WS-Fed) users to O365. The native Mail app on iOS 11 now supports Modern Authentication for users with O365. This enhanced sign-on flow occurs when a new mail profile is created on the iOS 11 device. For customers using Universal Sync or User Sync provisioning, your users will be required to return to Okta to authenticate when they change their Okta password or their Office 365 token expires. If you are using Profile Sync provisioning, tokens expire every 14 days, or after an Okta password is reset, and users are required to reauthenticate with Okta. If you are using a provisioning solution from Microsoft or a third-party, authentication intervals are unaffected by this change.
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. 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 (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.