When ViewsFlash runs in J2EE compliant application server, it can use declarative and programmatic security to provide very fine-grained access control by users and roles to different functionality. When such security is not available, password security and port security can provide less fine-grained access control. The methods to be used are summarized in the table below. The most sophisticated methods are listed first.
|How it is implemented
All ViewsFlash users must be authenticated by the application server. Optionally, they can also be required to belong to an established role or group.
The ViewsFlash Administrator grants specific access rights to other users and groups or roles. Different users are assigned rights to their own places and specific functions. For example, in a health care organization, a Research place can authorize certain users to create surveys, while other users can analyze survey results and yet other users can examine the raw survey data.
A web or application server with User Authentication.
Groups and roles can be defined by the application server or directly in ViewsFlash.
Two servlets (viewsflash and vfadmin) are set up in the application's web.xml file, with different access controls.
Additional fine-grained access rights are administered internally by ViewsFlash.
All ViewsFlash users must be authenticated by the application server, and can be required to belong to an established role or group.
User security is a superset of servlet security.
|A web or application server with User Authentication.
|Two servlets (viewsflash and vfadmin) are set up in the application's web.xml file, with different access controls.
|The ViewsFlash administrator has a password that grants access to the entire application. Each place can set a password to restrict access to it
|This option can be used with all other forms of security except User security.
|The ViewsFlash application verifies the passwords.
|The ViewsFlash application can be required to use a different TCP port for its administrative functions.
|This option can be combined with all other forms of security.
|The network topology makes sure that only computers at authorized IP addresses have access to the application's servlets.
User and Servlet security are described in Application Server Security. If one of these methods is not used, a WARNING will be present in the Administration page. Using these forms of application security is highly recommended.
An administrative password is specified as a ViewsFlash servlet parameter:
This will protect the more sensitive areas of the application with an Administrator Password. Individual places can also be protected with their own passwords, and all polls or surveys in password protected places will require that password to access their user interface. A complementary servlet parameter, "admintimeoutminutes", makes the cookie expire after the indicated number of minutes, so that a user will need to enter the password again after that time. This guards against someone inadvertently leaving their ViewsFlash application unattended in a browser. This is the minimum amount of security that is recommended.
ViewsFlash can be configured so that the application's administrative interface can be accessed only on a particular TCP port. To do so, use the following ViewsFlash servlet parameter:
With this, the URL for the ViewsFlash application will then become:
If someone attempts to access the application through another port, the response will be a 404 Not Found or other rejection code.
Similarly, the HTTP ViewsFlash commands used in the Web Services APIs can be protected by requiring another TCP port in their URLs. To do so, use a ViewsFlash servlet parameter such as "apiport=8089". By default, this parameter is set to a port that is normally unavailable, and it must be set explicitly to an available port in order to use these APIs. See How to use the Web Services API to enable it when using it from JSP pages. Setting apiport=80 allows public use of these APIs and is not recommended.
Both Apache and IIS allow receiving requests from more than one TCP port. If this is not possible and your are running on a database, a ViewsFlash instance can be installed in two instances of the web server instances that allow access on two TCP ports.
When using these alternate ports, consider configuring router ACLs so that only selected people or servers are allowed access. For example, only a certain set of users could be allowed access to the administrative user interface on port 81. A results server that requests ViewsFlash data in real time for analysis or display using the Web Services API can access it on port 1999, but no other servers would be granted that privilege.
Next: Application Server Security