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.