Preview

December 2018

2018.12.0: Monthly Preview release began deployment on December 5

* Features may not be available in all Okta Product SKUs.

Content

Generally Available Features

New Features

Group Push enhancements

Group Push now supports the ability to link to existing groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. in the following application integrations:

  • Slack
  • Dropbox for Business
  • ServiceNow UD

You can centrally manage these apps in Okta. For details, see Enhanced Group Push.

PIV Support for MTLS

Authentication for PIV (Personal Identification Verification) now supports the MTLS protocol and may be used once you have whitelisted the following domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https).: *.mtls.okta.com. For more information about IP whitelisting and Okta domains, refer to Configuring Firewall Whitelisting.

Automatically send an email to locked-out end users

You can automatically send your 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. an email if their account becomes locked due to too many failed sign-in attempts. You can insert a link in the email to let users unlock their account. For details, see Configure lockout settings.

Email notifications for Factor Enrollment and Factor Reset

Admins can enable two new settings for email notifications that are sent to 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.. When enabled, end users will receive an email confirmation if the end user or an 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. enrolls in a new factor or resets an existing factor for their account. For more information on end user email notifications, see General Security.

Okta Windows Credential Provider agent, version 1.1.3

This release contains general bug fixes. For version history, see Okta MFA Credential Provider for Windows Version History .

Enforce Device Trust for managed Windows computers

Okta Device Trust for Windows allows you to prevent unmanaged Windows computers from accessing enterprise services through browsers and native applications. For details, see Enforce Device Trust for managed Windows computers.

Generally Available Enhancements

Okta Verify Enrollment enhancement

When enrolling for Okta Verify using a QR code, the full orgThe Okta container that represents a real-world organization. subdomain is now specified as part of the enrollment process. For end users that have multiple okta accounts using the same Okta Verify mobile 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., the full org subdomain will be displayed for each account in the Okta Verify app. For more information about Okta Verify, see Okta Verify.

Admin Console update

We have updated the release number displayed in the Admin Console to the YYYY.MM.U format that we are officially adopting with the December Monthly Release. For more information, see Release Notes.

Okta User Communication improvement

We have improved the Okta User Communication message in Settings > Customization to clarify the scopeA scope is an indication by the client that it wants to access some resource. of end user communication.

Early Access Features

New Features

Support for Salesforce Government Cloud

You can create instances of the Salesforce app that can integrate with Salesforce Government Cloud. For more details, see the Salesforce Provisioning Guide.

Okta Active Directory agent, version 3.5.5

This release includes:

  • A bug fix for errors when importing a group with more than 1,500 users.
  • Internal bug fixes

For version history details, see Okta Active Directory agent version history.

PIV Card authentication option added to identifier first Sign In page

A PIV Card authentication option is now provided on the identifier firstInstead of presenting both a Username and a Password field, "identifier first" sign in pages present only a Username field. As used in Okta IdP Routing Rule scenarios, "identifier first" sign in pages submit usernames to Okta for determining which IdP should be used to authenticate an end user. Sign In page when you configure a Smart Card Identity Provider and a corresponding IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. Routing Rule in the Okta Admin console. For more about Okta's support for PIV card authentication, see Add a Smart Card/PIV Card.

IdP Routing Rules shows inactive IdPs

To make it easier to distinguish between active and inactive IdPs (Identity Providers) in IdP Routing Rules, inactive IdPs are now indicated as such in the IdP Routing Rules list. For more about IdP Routing Rules, see Identity Provider Discovery.

Early Access Enhancements

ASN Support for Dynamic Zones

Admins can now enter ASNs (Autonomous System Numbers) when creating or editing a dynamic zone. For more information about using ASNs, see Dynamic Zones.

FIPS-mode encryption enhancement

We have updated the Okta Verify configuration UI label for the FIPS-Mode encryption setting. For more information, see Enabling FIPS-mode encryption.

Fixes

General Fixes

OKTA-185031

Recreating group push mappings for previously existing groups would cause group memberships to not be mastered by Okta.

OKTA-187881

An LDAP directory could not be assigned to an Okta group when Sync password was enabled and Create users was disabled.

OKTA-193192

Some end users were still prompted to authenticate with MFA despite successful enrollment with Okta Verify or Duo within the same session.

OKTA-194472

The API Access Management Admin role was not returned for the user when performing a GET on api/v1/users/${userId}/roles endpoint. 

OKTA-195092

When using browsers other than Internet Explorer, Agentless Desktop SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. was performing two authentication requests for each user, increasing the authentication time.

OKTA-196220

Push Groups functionality only worked for admins with Super Admin rights.

OKTA-197099

Provisioning operations for the Coupa app failed.

OKTA-197991

The MFA Usage Report listed Okta Verify with Push as an enrolled factor even if the factor was reset by an end user from their dashboard making it no longer enrolled. 

OKTA-198258

There was a minor grammatical error in the app approval admin notification message.

OKTA-198556

IdP Discovery rule with a Sharepoint On-Premise specific app instance condition was not routing properly on SPAn acronym for service provider. Generally, an SP is a company, usually providing organizations with communications, storage, processing, and a host of other services. Within Okta, it is any website that accepts SAML responses as a way of signing in users, and has the ability to redirect a user to an IdP (e.g., Okta) to begin the authentication process.-initiated login flows.

OKTA-198797

After creating an ASN dynamic zone via the API, then viewing via the UI, the default proxy type was Unchecked instead of Any proxy. 

OKTA-201054H

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. IdP flow broke down with a 404 error if the ACS URLACS Endpoint – Assertion Consumer Service URL – often referred to simply as the SP login URL. This is the endpoint provided by the SP where SAML responses are posted. The SP needs to provide this information to the IDP was in {{org}}/auth/saml20/{{IdP name}} format.

App Integration Fixes

The following SWA apps were not working correctly and are now fixed

  • Alibaba Cloud (Aliyun) (OKTA-198076)
  • Anaplan (OKTA-198239)
  • Apple Business Manager (OKTA-198241)
  • Dell Boomi (OKTA-198237)
  • Egencia UK (OKTA-198487)
  • Linux Academy (OKTA-198691)
  • PacificSource InTouch (OKTA-197597)
  • Perfode (OKTA-198238)
  • Rival IQ (OKTA-190557)
  • Salesforce: Marketing Cloud (OKTA-197948)
  • Web Manuals (OKTA-199509)

Applications

Application Updates

The following partner-builtPartner-Built Provisioning: The Provisioning features of some OIN apps are built by a third-party, typically the vendor of the app product or service. These features are Okta Verified through a rigorous Okta review process. Partners-Built EA: Partner-Built EA application features have been verified and tested by Okta but may not have been deployed or used by a customer in an Okta production environment. We recommend that you fully test these integrations for your own provisioning use-cases before deploying in production for your end users. Okta Verified: A Partner-built EA application becomes Okta Verified after a customer has verified the integration in production. provisioning integration app is now Generally Available in the OINAn acronym for the Okta Integration Network. The OIN is comprised of thousands of public, pre-integrated business and consumer applications. As an on-demand service, OIN integrations are continuously validated, always up to date, and constantly growing both in number and capability. Okta performs a single integration with an ISV or SP, providing thousands of end users with point-and-click customization for their orgs. as partner-built:

New Integrations

New SCIM Integration Application

The following partner-built provisioning integration app is now available in the OIN as partner-built Early Access:

SAML for the following Okta Verified applications

  • Abstract (OKTA-192587)
  • BambooHR (OKTA-199943)
  • CloudBees (OKTA-191171)
  • SAP Concur Solutions (OKTA-198484)
  • Workable (OKTA-198491)

SWA for the following Okta Verified applications

  • Acronis Cloud (OKTA-189384)
  • Ameriflex Wealth Care Portal (OKTA-197201)
  • Autodesk BIM 360 (OKTA-194354)
  • buildpulse (OKTA-196661)
  • Business Insider PRIME (OKTA-196625)
  • Drift (OKTA-192116)
  • Forum: Business Online Banking (OKTA-195330)
  • HigherGear - (OKTA-196158)
  • HomeDepot Vendor Portal (OKTA-190428)
  • HP DaaS (OKTA-196207)
  • Insperity Premier (OKTA-191066)
  • Kayak (OKTA-74699)
  • TrendKite (OKTA-197199)
  • WealthEngine (OKTA-198240)
  • Zywave Home (OKTA-193830)

Weekly Updates

Closed2018.12.1: Update 1 started deployment on December 12

Enhancements

Temporary Passwords for Pending Users

Temporary passwords can now be created for users who are in the Pending user action state and cannot access their activation email. Creating a temporary password for a user in this way will activate the user and require them to change the password during their next successful sign-in attempt. For more information see Manage people.

Fixes

General Fixes

OKTA-155477

AD-mastered users logging into Okta with a temporary password were not asked to create a new password.

OKTA-156155

Requests to the same Okta Org Authorization Server’s keys endpoint failed if the requests originated from different domains in the same browser.

OKTA-177142

Inbound delegated authentication failed in application when the application username and Okta username were different.

OKTA-182115

As a result of multiple redirects, URLs became too long when a SAML app was used in conjunction with IWA and multifactor authentication.

OKTA-188067

When adding a user to the source user group, if the target user group did not exist, group push mappings did not display an error.

OKTA-189754

The Sign On policy did not show a warning after reaching the limit of 20 rules per policy in the UI. The limit has now been increased to 50 before showing the warning.

OKTA-190684

The OpenID Connect ClientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. ID Token settings form was missing a link to the reference documentation about the groups claim, also the the Sign On mode tab was missing a link to the profile mappings. 

OKTA-191321

In some cases, the LDAP search filter did not allow using "<" and ">" simultaneously. 

OKTA-191398

The System Log did not include hostname in the Debug Context for Windows events.

OKTA-195890

IdP Discovery routing rules with an application condition and without a user identifier condition were not routing to social IdPs.

OKTA-195916

Resetting the password for one account while a different user was signed into another account in the same browser generated a successful System Log event for the wrong account, and the UI showed a failure message although password reset was successful.

OKTA-196579

The WebEx app did not update sessionType attributes for users.

OKTA-199133

The System Log did not report enrollment failures that occurred when the relevant Device Trust setting was not enabled in the Okta Admin Console.

OKTA-200176

The Application Usage report returned a server error instead of a bad request message when an invalid date was entered to generate the report.

App Integration Fixes

The following SAML app was not working correctly and is now fixed

  • IntraLinks (OKTA-198125)

The following SWA apps were not working correctly and are now fixed

  • Crunchbase (OKTA-198994)
  • Dashlane Business (OKTA-199046)
  • Shopify (OKTA-200163)
  • Thycotic Force (OKTA-198995)

Applications

New Integrations

The following partner-built provisioning integration app is now available in the OIN as partner-built Early Access:

SAML for the following Okta Verified applications

  • Expiration Reminder (OKTA-200470)
  • RecruitBot (OKTA-196618)

SWA for the following Okta Verified applications

  • Haivision Support (OKTA-191530)
  • ONE by AOL: Video (OKTA-196063)

Extended Client Access policy capability for apps

When you create App Sign on Policy rules, you can now specify platform types with greater granularity. For details, see Add Sign On policies for applications.  

Modern authentication support

We have extended our Office 365 Sign On policies to include the ability to distinguish between web browser and modern authentication clients, giving you even more granularity in controlling how users are accessing corporate data. You access this functionality by creating a new App Sign On Rule.

Enhanced provisioning for Office 365

With additional enhancements to Microsoft Office 365 integration admins can now synchronize identities from on-premises to cloud-based Office 365, provision a user profile that is extended further to include over 100 attributes, as well as synchronize distribution groups, contacts, and resources such as conference rooms.

Admins can also manage user licenses and roles, independent of other provisioning flows. The new provisioning type for Office 365, License/Roles Management Only, allows admins to manage user license assignment and role delegation for existing Office 365 users and for users provisioned to Office 365 with third-party tools. For more details, see Okta Enhancements with Microsoft Office 365 Integration.

Multifactor Authentication for admins

MFA for Admins allows Super admins to enable mandatory multifactor authentication for all administrators accessing admin functionality. For details see Authentication. This feature is currently available for new orgs only.

Location-based network zones

Zones can now be defined based on geo-location. For more information on location zones, see Networks.

Top

© Copyright 2018 Okta, Inc