Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

16.10 Highlights: Improved App Policy and Administrative Features

11 April,19 at 11:50 AM

In case you hadn't heard, we will be upgrading our platform (Centrify Identity Service and Centrify Privilege Service) to version 16.10 this weekend (Saturday, October 29th).   The complete list of new features is available in the release notes, but as always I will tell you about my favorites here:


Improved App Policy

In this release we've made significant improvements to:


  1. The way Admins configure per-app policies, and
  2. The interactions between per-app policies and login authentication policies (used to access the portal).

First, let's look at the improvements to the configuration in per-app policies.  In the past, if you wanted to set an application specific policy, you could easily enable 2 policies via checkboxes (restricting access to clients within the Corporate IP range, and/or to always require strong authentication), or you could use the scripting engine to write your own per app policy.  With this new release, we are adding the rules builder UI that is currently available under Policies for setting Login Authentication policies to Apps!


App Rules Builder.png

This makes building policies for apps much simpler.  While we've made it simpler to setup rules for app access for most use cases, we did not remove access to the scripting engine so more complex rules can still be created. 


Most importantly, we've made a significant change to the interaction between application policy, and the more general login authentication.  In the past, we treated the login flow separately, and if the user logged in using MFA, we considered the user to be "highly authenticated" for the entire platform.  This meant, if the user then logged into an application that also required strong authentication, the user would not be asked to provide additional credentials to authenticate into the application.  With 16.10, we've done away with the concept of high auth for the platform and now honor the app policy regardless of how the user authenticated to access the platform.  We've also made a couple of changes to the login authentication policy to better support this.  Specifically, in the past, we had policy settings for IWA and certificates to "consider those logins as strongly authenticated".  Those policies have been changed to  indicate that IWA or certificates "satisfy all MFA mechanisms".   Of course, we've also removed the login authentication policy to set the authentication profile to use for strong authentication for applications (since that can now be set independently for each app that requires strong auth).


Administrative Features

In this release we've also added two new features to improve the Admin experience. Specifically, we've improved the people picker for SAML app script testing.  With this release, when you need to test a SAML script, the people picker will default to the logged in user.  If you change that user to someone else, and then modify the script, when you come back to test the script it will remember who you tested as previously.  We also took this time to replace the people picker widget with our standard people picker used throughout the product.


SAML People Picker.png 


In addition, we added a safety feature to prevent admins from setting policies that would lock themselves out of the platform.  In the past, we've had customers call us to help unlock their accounts because they could no longer login as the system administrator for their tenant.  Typically this happens when the admin sets up an authentication profile that requires an MFA mechanism that the admin can't provide.   With 16.10, whenever the admin makes changes that affect the login flow, we will validate that those changes will not prevent sysadmins from being able to login.  If the changes would result in a lockout condition, we now pop a warning message.


We hope you enjoy these new features and look forward to hearing your feedback!