In ViewsFlash, User Authentication is done by the Application Server, using Java's getRemoteUser() method, which normally enforces authentication and provides single sign-on.
When this is not feasible or practical, as for example when using Site Minder for authentication, ViewsFlash can be configured to use an alternative authentication method using its Extensible Authentication architecture.This allows specifying a class in the servlet parameters that will perform the same function as getRemoteUser(). The built-in OtherAuthentication class can be used, or you can even write your own.
Using the OtherAuthentication class
Include the following parameter in the ViewsFlash servlet parameters:
Include one of the following in the ViewsFlash servlet parameters. Do not include both
Use OtherAuthentication.HeaderName if the authentication system and the web server create an HTTP header that includes the user ID, and set this parameter to the name of that header.
Use OtherAuthentication.SessionAttributeName if the authentication system and the application server create a session attribute that includes the user ID, and set this parameter to the name of that session attribute.
The OtherAuthentication class looks for the user ID as directed above. If no user ID information is present, it redirects the user to a URL specified by this servlet parameter:
Set the value of this parameter to a URL. In the URL, include the values that are appropriate the authentication agent. The values %1, %2 and %3 are replaced by:
With this class, the ViewsFlash application can be protected using User Security. However, it's probably not necessary to secure the URL pattern /servlet/vfadmin with a security-constraint in ViewsFlash web.xml. It may be desirable to set up the authentication agent so that the /ViewsFlash/servlet/vfadmin URI requires authentication by the agent.
When setting up questionnaires, if the Basic Authentication is selected,this class will authenticate respondents instead of J2EE's getRemoteUser. In web.xml, it's probably not necessary to secure the URL pattern /servlet/vfauth, and it may be desirable to secure /ViewsFlash/servlet/vfauth with the authentication agent.
Extensible Authentication allows using an authentication mechanism as well as looking up Roles independently from the Application Server.
Writing your own Authentication class
The RequestNotifier Extension mechanism can be used to verify whether a user is authenticated. When using this, be sure that web.xml does not protect the ViewsFlash application or its servlets. In surveys, use Basic Authentication as the authentication method. See AuthenticationSkeleton.java for sample code.
1. Create a class com.cogix.vwf.YourExtensionClass that extends RequestNotifier, and override its OnRequest method as follows:
If the user is successfully authenticated, set:
thiscall.userid = theUserID; // a String with the User ID.
If the user is not authenticated,
If browser redirection is needed to delegate authentication
to an authentication
thiscall.bRediraftersetattribute = true;
thiscall.rediraftersetattribute = reqURL; // usually will contain the original ViewsFlash query string
2. Add to viewsflash.properties:
3. If there is a severe internal error, throw new vwfException(String message). The message WILL be visible to the visitor. It is better to simply set thiscall.userid=null and use a logging function to record the error.
The Role Lookup Extension mechanism can be used to verify whether an authenticated user is in a particular Role. When using this, the Application Server's role lookup method, if any, will be ignored. To activate it, add the appropriate lookuprole parameter to viewsflash.properties, as follows:
1. To use an LDAP server,
see Using LDAP and add:
2. To look up roles in a properties file, add:
This will look for a servlet parameter
filelookuproleproperties=<path to a file>
If this parameter is not present, the file will default to /etc/cogix/fileroles.properties
This file has the following format:
user=role,role,role,role,role (no limit on how many)
Spaces are ignored.
Role names are arbitrary. They do not need to correspond to any role or group names in the Application Server.
3. To look up user roles in a database table, add:
See DBLookupRole.java for sample code.
These role names are arbitrary. They do not need to correspond to any role or group names in the Application Server.
4. To use your own extension, use FileLookupRole.java as an example, and create
your own class, and activate it with servlet parameter:
Next: Database Storage