Application Server Security

 

Overview
In a J2EE compliant application server, ViewsFlash can use declarative security to provide access control to the application; this is referred to here as "servlet security". ViewsFlash can enhance this with additional programmatic security to provide fine-grained access control to different functionality within the application to users and roles; we refer to this as "user security".

Windows note: In the J2EE specification, users belong to Roles. In Windows, users belong to Groups, and application servers implement J2EE roles as Windows groups. When we use the word Role we refer to Roles or Groups interchangeably.

To use Application Server security, the ViewsFlash application's WEB-INF/web.xml file must include a security-constraint element that requires users to be authenticated before accessing the vfadmin servlet, which is the ViewsFlash user interface. This element also requires that users belong to one or more Roles. For a complete explanation of security-constraint see the Servlet Specification 2.2 and your application server documentation. Some application servers that implement Servlet Specification 2.3 may allow using * for role-name; this allows anyone in any role to access the application, but roles still have to be defined and users must belong to one or more roles.

Difference between servlet security and user security

Both methods provide the ViewsFlash administrative interface at /servlet/vfadmin and survey and poll taking at /servlet/viewsflash, and require authentication by the application server.

Servlet security, which can be combined with password and port security, adds another layer of protection to the ViewsFlash application.

User security, in addition, provides fine-grained access control to resources, and is well suited to enterprise environments where access needs to be carefully doled out to specific users. The ViewsFlash administrator acquires the responsibility for managing access control. Different options allow for fully secured and trusted security environments. Password security is not available when using user security and is automatically disabled if requested.

Access Rights are granted to individual users by listing their login user IDs, or to roles by listing their names, prefixed by an @ sign. For example, tom.jones,@HospitalPersonnel refers to user ID tom.jones and to anyone belonging to role HospitalPersonnel.

Whether a user belongs to a Role or Groups is determined by the application server. Any role or group names described to ViewsFlash will be automatically mapped by the application server through the standard Role Mapping mechanism, if active. It is possible to bypass the application server's role mapping and provide your own mappings between users and roles, as described in Extensible Authentication.

Installation for both Servlet and User security

1. Install ViewsFlash normally, using the default web.xml file provided, and check that the application is installed properly. This installs ViewsFlash as a web application at
http://www.yourcompany.com/ViewsFlash

2. Review /ViewsFlash/WEB-INF/web.xml. The <web-resource-collection> element for /servlet/vfadmin requires that application users must be authenticated by the application server. The <auth-constraint> element specifies that those application users must also be in the role of "ViewsFlashUser", and the <security-role> element defines that role. Instead of ViewsFlashUser you can use any role you like.

The <web-resource-collection> element for /servlet/vfauth requires that respondents who fill out questionnaires where basic authentication is specified in the questionnaire's the Settings / Security page must be authenticated by the application server, at the role of ViewsFlashRespondent.

The <login-config> element specifies that authentication will use the login form located at /ViewsFlash/WEB-INF/vflogin.html. Other standard methods may be used, of course, such as BASIC, DIGEST, or CLIENT-CERT, with appropriate parameters.

3. Add to the viewsflash.properties file an "appsecurity" parameter. This enforces sending survey and poll form submissions to the /viewsflash servlet and administrative UI form submissions to the protected /vfadmin servlet. Add one of the following:
appsecurity=servlet
appsecurity=user

Also add:
administrators=<list>
This parameter designates the ViewsFlash administrator(s). Its format is a list of names and roles prefixed by an @ sign. For example:
administrators=Tom.Jones,Nancy.Drew,@ViewsFlashAdministrator,@LawFaculty
This example appoints logged in users Tom.Jones and Nancy.Drew as ViewsFlash administrators, as well as any logged in user who has the role ViewsFlashAdministrator or LawFaculty.

The adminpw servlet parameter is not needed when using the appsecurity parameter.

4. If configuring for servlet security, installation is complete. Restart the ViewsFlash application and use it.

5. If configuring for user security, continue installation by adding the following parameters to viewsflash.properties:

appsecurity=user
administrators=<list>

In <list>, use a series of names and roles (or groups) prefixed by an @ sign. For example:
administrators=Tom.Jones,Nancy.Drew,@ViewsFlashAdministrator
Users Tom.Jones and Nancy.Drew are now ViewsFlash administrators, as well as any user with the role ViewsFlashAdministrator.

Additional keywords can be used with appsecurity=user, by entering on the same line, separated by a comma. These options change significantly how security is enforced. For example:
appsecurity=user,closed,trustadmin

appsecurity=user,closed (the default) requires that Access Rights be assigned to places, styles, or invitation lists before they can be accessed.
appsecurity=user,open allows using, and changing settings in, any place, style or invitation list until their Access Rights are restricted explicitly.
So, in general, "closed" provides a system where Access Rights must be explicitly granted, and "open" provides a system where Access Rights must be explicitly restricted. Open is recommended for small groups of users who work on a single project, for example. Upgrade considerations are covered in Using User Security.

appsecurity=user,notrustadmin prevents the ViewsFlash Administrator from assigning himself Access Rights, either directly or through a Role he belongs to. The default is appsecurity=user,trustadmin, which allows him to assign himself Access Rights to places, styles, and invitation lists.

appsecurity=user,adminuionly allows application access only to ViewsFlash Administrators, and only to those functions that they can perform, namely changing Access Rights. This option can be used in combination with Staging to secure a production server.

appsecurity=user,noui prevents any access to the application at all. This option can be used in combination with Staging to secure a production server.

Password security is ignored when using User Security. If existing places use passwords, they will not be required any longer.

6. For additional security, you may want to protect the documentation and the upload servlet by adding these XML security constraints to web.xml.

7. Restart the ViewsFlash application.

 

Next: Using User Security