This page describes WebAccess’s support for the VASCO (aka Mainframe) hardware tokens. For information about the newer, and preferred, 2FA support, see WebAccess 2FA Feature.
The Security Token feature in WebAccess allows a Cosign-protected web site to request that a user input the current value from their assigned Security Token (in addition to their password) to gain access to that web site. The feature is contained within your Cosign software and enabled through that configuration: no other changes or additions to your website are needed.
To support this, the WebAccess servers use the Generalized Interface (GI) with the AIS mainframe: correct functioning is subject to both mainframe and GI availability.
Since it uses the GI, both VASCO and RSA tokens registered with AIS can be used.
- Tokens can only be associated with Access Accounts, so your web site cannot make use of FPS accounts.
- Since the feature applies to your entire web site, every person (Access Account) who should be able to use your site must have a token.
- This is a once-per-login session request, similar to the account password. I.e., if both web sites A and B are configured to request the token, and the user has already logged in and visited site A (inputting a token to WebAccess), then when they visit site B, no additional input for a token is done.
- Like the password, your Cosign filter does not have access to the actual token value.
Converting to 2FA
To convert your website from this to using 2FA, simply change the configuration references of “otp” below to “2fa”. See the WebAccess 2FA Feature page for examples.
To enable your web site’s Cosign filter to request the token, you must add a “factor” feature to your Cosign configuration. (The Cosign software calls authentication methods, including the initial password login, “factors”.) Please create backup copies of your Cosign configuration beforehand. Here’s how to enable the feature on the various platforms:
In the Apache httpd.conf configuration file (or included file) where you have your CosignService directive, add this line right after it
then restart httpd.
IIS 6 (IISCosign)
Modify your cosign.dll.config file, add this line
inside the <Service> element, after the <IISDescription> element, similar to:
<Service> <Name>cosign-www.dept.psu.edu</Name> <IISDescription>Our Web Site</IISDescription> <RequireFactor>otp</RequireFactor> <Protected>/protected</Protected> …
then restart IIS.
See the iiscosign.xsd file in your IISCosign distribution for the exact location of this element in relation to other lines in your config file (only use the <RequireFactor> element that’s inside <Service>).
IIS 7+ (CosignModule)
Your current <service> element is most likely a single tag similar to
<service name="cosign-www.dept.psu.edu" />
To add the token factor, you’ll need to split it into a start and end tag surrounding a new <add> element, like
<service name="cosign-www.dept.psu.edu"> <add factor="otp" /> </service>
then restart IIS.
Your cosignConfig.xml file will have a section for your web site similar to
<service name = "cosign-www.dept.psu.edu"> <protected>/cosign-secure/protected/</protected> <service>
Modify it similar to this
<service name = "cosign-www.dept.psu.edu"> <reqfactor> <factor>otp</factor> </reqfactor> <protected>/cosign-secure/protected/</protected> <service>
then restart your Java service.
If a site requires the token to be input, the WebAccess login pages display a
Token field after the
The help page linked from the WebAccess login pages documents the Token field and links to the AIS page about Tokens. However, you should probably inform your user community about the new requirement prior to your change.
If you want to enable the token requirement on your development/test system (perhaps to demonstrate the behavior, or test a configuration similar to your production one), but don’t want to require an actual token, you may configure Cosign for a “junk” token. In the Configuration section above, instead of requesting the “
otp” factor, request the “
When WebAccess prompts you to enter a token, the web page will look the same as for an actual security token. Instead of entering the current value from a token, however, enter the string “
junk” (without the quotes).
Determining if the token factor was satisfied
Your Cosign filter presents data to your application which can be used to verify if the token has been presented (the Cosign filter will not grant access to a URL until the requested factor is satisfied, so checking is not necessary), or to take different action for Cosign Public Access areas. Contact the WebAccess team if you’re interested in finding out how to do this.