| |
This section discusses the format and functionality of the iChain Form Fill Policy file, which controls which forms are identified and filled. The form fill file contains any number of URL policies encoded in XML.
The following is an example of what a simple policy looks like:
Figure 14
Simple Policy
The bounds of a policy are delimited by the start tag <urlPolicy> and the end tag </urlPolicy>. This sample has a <name> of Test, which can be anything the user chooses, as long as it is unique within the policy file. The <name> is optional, except in a few cases, which will be discussed later in this section. The policy's <url> value of www.test.com/login.htm matches an exact page so that whenever this URL is requested by a browser, it will match this policy.
When a policy matches on a given page, certain actions are performed. These actions are specified by the <actions> tag. The example above designates two actions: <fill> and <post>.
The <fill> action identifies the page as a form that needs to be filled, and the <input> tags that follow describe the fields in the form that have values to insert. The first <input> tag has a name of userid and a value of ~dn, which instructs the policy to find the <input> tag in the form that has the name of userid and insert the user's dn (LDAP distinguished name) as the value of the field. The "~" in ~dn is a flag to the parser that this input field has a value that needs to be filled in.
Note that the name that follows the ~ is the name of the attribute in LDAP, not in NDS®.
The second <input> tag is a special case because password is not an LDAP attribute. It instructs iChain to use the same password that the user gave when he or she logged in to iChain.
Since it is possible to have more than one <input> field in a form by the same name (or <input> fields without a name, the <input> tags given in the <fill> action are order-dependent. They must be specified in the order they will be seen in the form. Only those <input> fields that need to be filled in need to be specified.
The second action, <post>, instructs iChain to proceed and post the form without sending it back to the user for confirmation. This logs the user in automatically and gives the illusion of single sign-on. Care should be taken when using this action so that all login failures are handled properly. Handling failures is explained later in this section.
The following is an example of what a more complex policy looks like:
Figure 15
Complex Policy
In the above example, the <url> value, www.test.com/abc/*, does not match a single URL, but rather all URLs below abc in the tree. There are some Web applications that don't have a specific login page; they simply return a login form from any of their URLs anytime they determine the user is not logged in.
In this case, there is no specific URL to match; any one of a set of URLs may be (or may not be) a login form. The only way to know is to look in the HTML being returned.
When deciding on a policy, iChain first matches the URL of the page with the <url> value or pattern. If that matches, iChain then searches for whatever is placed between the form criteria on and off tags. If more than one line of text is given as criteria, iChain searches for each line individually. Criteria must match exactly, so it is a good idea to cut and paste a line directly from the login form. It should also be unique to the form, and as small as possible, because the larger the criteria, the more time-consuming the searches will be.
Figure 15 shows some new uses of <input> tags.
Notice the values of "~". This instructs iChain to remember this value the first time the user enters it and to supply it automatically thereafter. The last <input> tag refers to a check box. Since check boxes and radio buttons behave differently than ordinary input fields, their types must be explicitly specified.
This policy also specifies the <post/> action so each user will be prompted once for a user ID, password, and with a check box titled useJava. Once the user has supplied these values, the values will be remembered and single sign-on will be simulated from then on (or until the login fails).
The following is an example of a simple login failure policy:
Figure 16
Simple Login Failure Policy
This example shows the normal way to handle a login failure and introduces two new actions: <deleteRemembered> and <redirect>. When a login fails, it usually means that iChain has remembered values that are incorrect. <deleteRemembered> gives a way to remove those values from iChain's memory. It is necessary to tell iChain the name of the form that remembered the values to be deleted.
The above example instructs iChain to delete the remembered values of a policy called test2. This is a case where the <name> value is not optional. A form-fill policy that has login failure policies needs to be named so those policies can reference it.
The other case is when more than one policy matches a given URL. Suppose you have a policy with a <url> of www.a.com/b/* and another policy with a <url> of www.a.com/*. The actual URL of www.a.com/b/c.html matches both policies. In this case, both policies must be named to avoid ambiguity. It is recommended that you name all policies to avoid potential problems later on.
When deciding on a policy to use for filling a form, iChain uses the first matching policy in the policy file. For this reason, it is a good idea to put more specific policies first in the file, and more general ones after.
The <redirect> action takes a URL that instructs iChain where to redirect the user's browser. Usually this is the original login page where the user will have the chance to try logging in again.
The following example is a login failure policy that also does form fill:
Figure 17
Login Failure Policy with Form Fill
The <url> tag specifies a range of URLs to match so it has <formCriteria> to note when the failure actually occurs. In this case, it searches for the text Login failed. When this policy matches, it deletes the remembered fields of the policy called test2, but instead of redirecting to a login form, it fills the current form. Some Web applications return an error and another login form as part of the same response. This case is handled as shown in Figure 17. Note that the fields remembered as the result of this policy are actually remembered in behalf of test2, the normal form-fill policy for which this policy is the login-failure policy. As previously mentioned, this association is made via the <deleteRemembered> action.
Most applications will present a logout or exit link to allow the user to exit the application. In most cases, an HTML page is returned, indicating the session status and also offering the user the chance to log in again via a link to the original login page. In some rare cases, a page is sent back, redirecting the user's browser to retrieve the original login page. Both scenarios would cause confusion to the user when automatic form fill is enabled. A false sense of security is implied in the first case: anybody who takes over the workstation can hit the re-login button and log in (automatically done by form fill) as the previous user because the browser session is still valid.
The second case would create the impression that the user will be re-logged in (automatically done by form fill) again when the logout/exit button is selected.
A logout mechanism resolves the above issues. A form fill policy needs to be configured to intercept the logout/exit page and redirect the user to a customized page which allows him or her to log out of iChain.
The following is an example of a policy with a logout mechanism in place:
Figure 18 
The page (ilogout.htm) and its associated image files that the logout/exit action is redirected to should be deposited in the SYS:\ETC\PROXY\DATA directory on the iChain proxy server. Remember to use the IP address of the iChain proxy server to complete the path to the page.
A sample page for the above policy might look like the following:
Figure 19 
The key to the actual iChain Proxy Server logout action lies on the reference link associated with the logout button: http://accelar.provo.novell.com/cmd/BM-Logout, replacing the URL with the proper domain name associated with the link (accelar.provo.novell.com in this case).
User-entered data in form fields will be stored in the user object's ichainFormFillCrib attribute by default. To make the storage of these credentials more secure through double encryption, you can use Novell SecretStoreTM.
SecretStore is a service in eDirectory that allows applications to store sensitive data securely. This service guarantees protection for integrity and confidentiality of application data in storage and during transmission between client and SecretStore.
In order to use SecretStore, you must upgrade to NICI version 2.0.2, install SecretStore, and then enable SecretStore. These procedures are explained in the following sections.
Insert the iChain Authorization Server CD.
Run Nici/wcniciu0.exe.
Follow the screen prompts to complete the install.
Run sso/NT/setup.exe.
During the SecretStore install, you will need to log in to your tree as Administrator in order for the schema to be modified.
Start the NDS Services Console.
Configure each of the following services to start up automatically:
Continue with Enabling SecretStore.
Insert the iChain Authorization Server CD into the CD drive on the server.
From a remote console prompt, enter CDROM to mount the iChain Authorization Server CD.
The server mounts the CD as ICHAIN_AUTH_SR.
To upgrade NICI, enter NWCONFIG. Choose Product Options > Install a Product Not Listed.
Press Esc and then F3, > enter the path to the NICI upgrade: ICHAIN_AUTH_SR:/NICI/NWSERVER > press enter.
Accept the license agreement to complete the NICI upgrade.
To install SecretStore, enter NWCONFIG. Choose Product Options > Install a Product Not Listed.
Press Esc and then F3, > enter the path to the SecretStore installation:
ICHAIN_AUTH_SR:/SSO/NETWARE/INSTALL > press enter to complete the SecretStore installation.
Continue with Enabling SecretStore.
After SecretStore has been installed, you must enable it to work with Form Fill as explained in the following procedure.
Log on to the LDAP server.
Export your trusted root for the LDAP server.
View the properties of the ISO object.
From ConsoleOne, select the Form Fill Policy tab > mark Use Novell Secret Store for Form Fill > click OK.
From the iChain Proxy Services Admin GUI, import the trusted root.
Select Configure (this icon is in the bottom left corner) > select the Access Control tab > mark Enable Secure Access to LDAP Server.
Select Import Trusted Root and enter a name for the imported file.
The file name must adhere to 8.3 naming conventions.
Using a text editor, open the file that was exported from the LDAP server to a local drive > copy all the contents of the file to the text field in the Trusted Root dialog > click OK.
Mark Enable Form Fill Authentication and click Apply.
NOTE: If you already had Form Fill enabled, you need to refresh Form Fill from the Access Contol tab.
| |