iChain 2.1 and higher provides the ability to create a custom login page per accelerator. For example, iChain could be fronting three different sites: novell.com, ctp.com, and silverstream.com. With the custom login page feature, each page could have its own unique login page.
To help you implement the custom login page feature, a brief explanation of iChain login, logout, and error pages is presented.
When an accelerator is set up, the user has the option of enabling authentication. When this is done, the user must specify an authentication profile. If the profile is an LDAP authentication profile, it will have three options for login name format:
Each login name format is presented to the user via a designated login page.
As an HTTP request comes in to be serviced by the accelerator, the proxy will first check the servicing accelerator to see if it has authentication enabled. If so, the proxy will first present a designated login page, contingent on the type of authentication profile specified for the servicing accelerator.
For example, assume there is an accelerator with an LDAP authentication profile where a distinguished name is the specified type of login name format. If a new HTTP request comes in to be serviced by this accelerator where no prior connection has been established, the proxy will first present the login page to the user:
SYS:\ETC\PROXY\DATA\CALOGLDP.HTM
If the login name format was the user's e-mail, the login page that will be presented is:
SYS:\ETC\PROXY\DATA\CALOGLMA.HTM
In order to be able to allow an administrator to specify a custom login page, in the iChain 2.2/iChain Proxy Server Web Administration tool, a field in the setup window exists to specify a subdirectory where the login page for that accelerator can be found. The actual file name will continue to be predetermined by the profile and login name format.
For example, if the user specifies the subdirectory NIKE and specifies an LDAP authentication profile where the login name format is user's e-mail, the proxy will attempt to find:
SYS:\ETC\PROXY\DATA\NIKE\CALOGLMA.HTM
Currently the designated login pages are:
To modify a login page specific to an accelerator:
Add the subdirectory to SYS:\ETC\PROXY\DATA\.
Copy in the appropriate HTML and graphics files.
In the accelerator setup field, specify the name of the directory.
Apply the changes.
The designated error pages are the same as the ones above, but different text is placed in certain fields in these files to indicate an error has occurred. Since PROXY.NLM currently hard-codes strings into designated HTML pages, it is best to allow for the specification of a unique error login page per accelerator.
The same mechanism that is described in Custom Login Pages is provided for child accelerators that are part of either path-based or host-based multi-homing.
Because the login pages are serviced from memory, this limits the types of graphics that can be supported. All streaming types of graphical/sound widgets (that is, avi, wav, mpeg, Quicktime, etc.) are not supported; however, BMP, JPG, GIF, and other types of clipart graphics are supported. Login pages and links referenced by the login pages should follow the 8.3 naming convention. Failure to do so will result in broken links and possible authentication problems.
Default login pages are contingent on the type of authentication profiles that are being employed for the accelerator. Coding of specific login pages is most readily accomplished via modifying copies of these files but the following describes significant portions of the specific login pages:
The requirements for an LDAP profile login page for login name formats of distinguished with LDAP contexts can be found in CALOGDP.HTM:
The same attributes as explained for CALOGLDP apply to accelerators using profiles with login name formats of distinguished without LDAP contexts (fully distinguished). The difference is that there is no context and the username should contain a fully distinguished LDAP name for the value.
The same attributes as explained for CALOGLDP apply to accelerators using profiles with login name formats of field name. The difference is that there is no context and the username should contain the field name value for the value.
The same attributes as explained for CALOGLDP apply to accelerators using profiles with login name formats of e-mail address. The difference is that there is no context and the username should contain an e-mail address for the value.
The same attributes as explained for CALOGLDP apply to accelerators using RADIUS profiles. The difference is that there is no context and the username should contain a RADIUS username for the value.
If you want to set up a custom logout page, you will need to provide a link in your respective HTML/XML page that reads as follows:
href="/cmd/BM-Logout"
or
href="/cmd/ICSLogout"
When this is completed, the following logout page will be presented to the user:
SYS:ETC\PROXY\DATA\CALOGOUT.HTM
Custom logout pages are similar to custom login pages.
When the user specifies a subdirectory for login/logout pages, either through the GUI or at the iChain Proxy Server command line
set accelerator <acc name> loginpage=<subdir from etc proxy data>
For example:
set accelerator nike loginpage=nike
the proxy will then look for:
SYS:ETC\PROXY\DATA\NIKE\CALOGOUT.HTM
Due to the free space issues that can arise on the SYS volume, you can move your custom login/logout pages to the USERVOL volume if needed. (If you do not have issues with space, we recommend that you leave your custom login/logout pages on the SYS: volume.)
To move the pages to the USERVOL volume:
Copy all of the files (including the subdirectories) from sys:\etc\proxy\data to uservol:\etc\proxy\data.
For example, if you are using toolbox's commands, you would do the following:
Load toolbox at the iChain server console.
Change the directory to the sys:\etc\proxy\data directory (where all of your custom pages are located).
Copy all of the customized data to the USERVOL volume by using the following syntax:
copy *.* uservol:\etc\proxy\dada /s
Change the directory to the USERVOL and confirm that the files you copied now exist there. You can verify this by using the following command:
cd uservol:\etc\proxy\data
NOTE: If administrators do not want to copy the full list of customized pages, they can use the copy command to copy specific directories over. The directory format must remain the same as that on the SYS volume. For example, the custom files in the \etc\proxy\data <custom> directory under USERVOL.
Administrators with existing custom directories on the SYS volume (under the etc\proxy\data directory) must rename these custom directories to other names. For example, if the original custom directory is called NIKE, you could rename it to NIKE.sav.
The directories must be renamed because the PROXY.NLM reads the SYS volume first, and if it finds that a directory with custom pages exists, it will not read the custom pages from the similarly named directory in the USERVOL volume.
Reboot the server. This action is required in order for the proxy to be able to read the custom login pages from the USERVOL volume instead of SYS volume.