The Cúram client application enforces security at two levels: the page and the field. Page-level security depends on securing the server interfaces that represent the functions of the server application. Any UIM page that declares a server interface will not be displayed if the authenticated user is not authorized to access all of the server interfaces invoked from that page. Field-level security is enforced when a property of a server interface is accessed. It is permitted for a user to access a page even though the page contains some fields connected to server interface properties that the user is not authorized to view. In this case, the values of those secured fields should not be shown to the user. For example, a user may be able to view the details of a person, but may not be authorized to view the salary of a person. The salary field may be presented on the person entity home page for all users, but if a user is not authorized to view the salary, the value of that field may be presented as a sequence of asterisks, **** instead of a monetary amount.
In the case of page-level security, the page is never rendered, so the renderers plug-ins will never be invoked. Therefore, page-level security is not a concern for the widget developer. In the case of field-level security, the renderer is invoked, so it is the responsibility of the widget developer to ensure that the renderer plug-in handles a field-level security violation appropriately. In the example given above, it is the renderer plug-in that produces the **** value instead of the monetary amount.
The field-level security violation is triggered when the renderer uses the DataAccessor to resolve a path to a server interface property that the active user is not authorized to access. The invoked method on the DataAccessor throws a DataAccessSecurityException instead of returning a value. If the renderer plug-in does not catch this exception and handle it, the rendering of the page fails and an error message is displayed. Where the required behavior is to display, say, **** instead of the secure value, the renderer must catch the exception and produce that value instead. The example below demonstrates this; the context is the render method and the DataAccessSecurityException class should be imported from the curam.util.common.path package.
String value;
try {
value = context.getDataAccessor.get(
field.getBinding().getSourcePath());
} catch (DataAccessSecurityException e) {
value = "****";
}
After the try... catch block, the value variable holds either the real value of the server interface property indicated by the field's source path, or ****, depending on whether or not the current user is authorized to access that server interface property. In either case, the value can be appended to the renderer's DocumentFragment to include it in the HTML response. The system is fail-safe. If the developer neglects to catch the security exception, then the page will not be rendered. If the developer catches the security exception, the secure value is never made available to the renderer class, so it is not possible for the developer to write code that would display the value accidentally.
The application security design should not expect to enforce field-level security on form pages. For example, a user may attempt to modify a person entity, but the user is not authorized to access the salary field. The user may see the salary text field on the person modification form initialized with the **** value. If the user submits the form, this literal value will overwrite the real salary value on the database. More likely, the user will see a validation error stating that **** is not a number. In that case, the user could enter any valid number and save it as the new salary value. In an edit-renderer plug-in, therefore, the developer should not catch the DataAccessSecurityException and simply allow the rendering of the page to fail. No secure information will be revealed in this case and the page can be secured at the page-level instead, preventing the user from viewing the page at all. If the user must be allowed to modify some of the details of the person, then the option to modify the secured salary field should be presented on a different from from the one that provides the option to modify the unsecured fields. Field-level security, then, is a concern for view-renderer plug-ins, not edit-renderer plug-ins.