Field-Level Declarative Security

What is it?

The Declarative Security system allows you to declare security rules directly in your DataSources using XML attributes. While previous releases allowed for control of individual DataSource operations, Field-Level Declarative Security (coming soon in Smart GWT 3.0 and SmartClient 8.2) will enable role-based access control to specific operations on fields. This allows restriction of access privileges by role to ensure granular security at a per-field level. View, search, initialize or update DataSource fields requiring specific roles with automatic consequences in the UI.

How does it work?

To attach role requirements to a DataSource, DataSourceField, or individual OperationBinding, just add a requiresRole attribute as a comma-separated list. If the current user is assigned one of the authorized roles, they are permitted to invoke the operation. These rules are evaluated as the DataSource is loaded, so that at the field-level:

• If a user is not allowed to see a field, that field is omitted entirely from the DataSource definition, and automatically omitted from data delivered to that client
• If a user is not allowed to edit a field, that field is shown as read-only by all DataBoundComponents that support editing, and any attempt to modify the field will be rejected automatically by the server

This will allow you to quickly and declaratively address use cases such as fields that can only be set when a record is created and can only be changed by an administrator going forward.

The current user’s roles are determined by calling the standard Java servlets method httpServletRequest.isUserInRole(). As a result, this API works automatically with both J2EE and JAAS security systems with no setup:  just start adding requiresRole attributes. This API can also be easily adapted to work with any security framework by calling RPCManager.setUserRoles() before requests are processed which is typically done as a subclass of the built-in IDACall servlet.

For more information, please see our Quick Start Guides (Smart GWT, SmartClient) or the reference docs.

Featured Use Cases

• Switch fields to read-only, or disable search based upon a user’s role.

• Create a “super user” role with access to all operations regardless of the requiresRole settings. This can be set with authentication.superuserRole in the server.properties file (see reference docs).

• Create an “admin” role that can see deleted records by combining Declarative Security with variations on core operations via Operation Bindings (see Quick Start Guides for example code).

• Restrict public access using the requiresAuthentication attribute to determine if a user must be authenticated in order to access a DataSource or Operation Binding.

• Configure a capability security system by using capability names (i.e. “canEditAccounts”) instead role names (i.e. “manager”) in the requiresRole attribute, and use RPCManager.setUserRoles() to provide the current user’s list of capabilities.

To get started even faster, we’ve also created a pre-built administration console and login process available as a preview in the Enterprise edition. Take advantage of our Jump Start program for training and starter code to begin using this functionality today!

Pre-requisites

• Field-level Declarative Security will be available in the Pro and above editions of Smart GWT 3.0 and SmartClient 8.2 (coming soon).

• Note to existing Smart GWT 2.x Users: 3.x will be a paid upgrade for 2.x license holders. If you just bought a 2.x Smart GWT license, don’t worry, upgrade costs are based on how recently you bought. If you bought very recently, you’ll get access to the entire 3.x series for a fraction of the license price. In addition, our upcoming release sale will stack a 30% discount is on top of the discount you receive for owning a 2.x license. For a quote please contact sales.