Enhanced Security and Authentication-related Features

New user-level security settings

This release introduces user-level security settings. These include:

• My Security Settings option on the My Profile screen where users can allow/disallow administrators to log into their accounts to provide support.
• User Permissions settings for roles that gives administrators control over access that was not previously configurable, such as personal settings and preferences, including the new security setting.
• Support Access screen supports enabling and disabling of the two types of support logins (as an administrator or as a particular user). It also allows administrators to set a duration for the access.

One result of these changes is that the Administrator of a tenant can enable one or both of the two types of support logins, and each user can control support access to their own account (unless it is disabled by the administrator for their role).

My Security Settings option on My Profile screen

The My Security Settings option now appears on the My Profile screen:

It opens the My Security Settings screen, where users can enable or disable support access.

User Permissions settings for roles

A new set of User Permissions is now available on the Permissions screen for roles. While they appear on the user Permissions screen, administrators can only edit them for a role.

These permissions are all enabled by default for every role. Administrators can disable/enable each of these permissions for a role.

User Permissions include:

• My Settings — When disabled, users with that role cannot manage the settings on their My Settings screen. My Settings will not appear on the My Profile screen.
• My Third Party Settings — When disabled, users with that role cannot manage the settings on their My Third Party Settings screen. My Third Party Settings will not appear on the My Profile screen.
• My Localization Settings — When disabled, users with that role cannot manage the settings on their My Localization Settings screen. My Localization Settings will not appear on the My Profile screen.
• Recycle Bin — When disabled, users with that role cannot manage their recycle bin. Recycle Bin will not appear in the Platform menu or on the My Profile screen. See New Recycle Bin option on My Profile screen
• My Security Settings — When disabled, users with that role cannot manage the settings on their My Security Settings screen. My Security Settings will not appear on the My Profile screen.
• My Theme — When disabled, users with that role cannot set the theme on the My Preferences screen. The My Theme area will not appear on the My Preferences screen.
• Notifications — When disabled, users with that role cannot edit Notifications on the My Preferences screen. The Notifications area will not appear on the My Preferences screen.
• Landing Page Configuration — When disabled, users with that role cannot set the Landing Page Configuration on the My Preferences screen. The Landing Page Configuration area will not appear on the My Preferences screen.

If My Theme, Notifications, and Landing Page Configuration are all disabled for a role, My Preferences will not appear on the My Profile page for users with that role.

The following screen shows the My Profile screen for a user whose role does not have permission for Recycle Bin, My Theme, Notifications, and Landing Page Configuration:

Support Access screen

The Support Access screen, accessed from the Setup Home screen by clicking Support Access from the Administration Setup area, previously supported only one option, Support Access. In this release, there are now two options on this screen:

• Login — When enabled, allows administrators from the master tenant to log in to the tenant as an administrator
• Login As — When enabled, allows administrators from the master tenant to log in and view apps as a particular user would see them, that is, with the same Role and permissions.

For hosted Platform, Infinite Blue administers the master tenant. On Private Cloud, login permission applies to master tenant administrators, but might also apply to ISV Partners and those with custom roles.

Edit the Give Access for fields to set the duration for which to allow enabled access.

Change to authentication fallback behavior

In this release, the way Platform handles fallback for an authentication failure has changed.

In a Private Cloud installation, administrators can configure Platform to use an external authentication method instead of the default password authentication. In previous releases, if authentication with external authentication method failed, Platform would fallback and use the default password authentication. This fallback behavior only applied to administrative users.

In this release, a user can choose to fallback to the default password authentication if one of the following applies:

• The user provides the URL parameter adminFallback. When set to true, it enables fallback behavior. This is only available to administrative users. The following example shows the URL with this parameter:

  myrbhost:8830/router/login/loginPrivate.jsp?adminFallback=true

• The tenant uses a custom authentication method and the code from that implementation throws a FallbackException. This is not restricted to administrators; restrictions depend on the implementation of the custom authentication method specified by the shared property CustomAuthClass. The following code shows a custom authentication method that throws FallbackException:

  public boolean authenticate(ICustomer cust, String loginName, String password, String ipAddress,
  							boolean isAPI,  Map<String, Object> additionalData) throws Exception {
  							...
  							} 

The REST login method has a new URL parameter, adminFallback, that provides the same fallback behavior for administrative users as the adminFallback URL parameter in the user interface. This parameter defaults to false; set it to true to enable fallback behavior.

Change to conditional field-level permissions when creating records

Previously, fields with conditional view or edit permissions were hidden on pages where users create records. In this release, these fields are no longer hidden and Platform uses formulas for conditional view and edit permissions for those fields.

This applies to both view and edit conditional formulas. If the view conditional formula returns true and the edit conditional formula returns false for a field on a page, the page displays the field but does not allow the user to enter a value in the field. If the view conditional formula returns false, the field does not appear on the page.

This change might require changes to existing formulas for conditional field-level edit permissions, because the current record context is empty during record creation. This means that all tokens for the current record evaluate to null. If you have formulas that use the current record context, for example, the {!id} token, they will not work during record creation. Other tokens, such as Current User, Current Customer, Settings, and Helpers, still work.

See Setting field-level permissions for more information and example patterns for conditionalizing formulas.