iChain 2.1 and later 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 useful.
When you set up an accelerator, you have the option of enabling authentication. When this is done, you must specify an authentication profile. If the profile is an LDAP authentication profile, it has three options for login name format:
User's e-mail
Distinguished name
Field name
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 first checks the servicing accelerator to see if it has authentication enabled. If so, the proxy first presents 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 first presents 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 is presented is:
sys:\etc\proxy\data\caloglma.htm
In order to allow an administrator to specify a custom login page, in the iChain 2.3/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 continues 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 attempts to find:
sys:\etc\proxy\data\nike\caloglma.htm
Currently the designated login pages are:
Sys:\etc\proxy\data\calogldp.htm: Login page for LDAP profile based on a login page with a login name format of distinguished name or field name.
Sys:etc\proxy\data\caloglma.htm: Login page for LDAP profile based on a login name format of user's e-mail.
Sys:etc\proxy\data\calograd.htm: Login page for RADIUS authentication profile.
IMPORTANT:When you create or modify a custom login page, you must save the page in the UTF-8 format. You can also use <FORM.... ACCEPT-CHARSET=”UTF-8”> as the form statement on the login page. This is important because the decoder for the iChain login pages now assumes that the post data coming back from the browser is UTF-8. The HTTP/HTML specifications have no other mechanism in place to ensure that this is the case. This is necessary to support any usernames not falling into the 7-bit ASCII set.
For more information about this issue, see TID 10099466.
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 Section 4.8, 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 clip-art graphics are supported. Login pages and links referenced by the login pages should follow the 8.3 naming convention. Failure to do so results 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. The following information describes the specific login pages:
Sys:\etc\proxy\data\calogldp.htm: Used for accelerators that have an LDAP profile with login name formats of distinguished with LDAP contexts.
Sys:etc\proxy\data\caloglnc.htm: Used for accelerators that have an LDAP profile with login name formats of distinguished without LDAP contexts (fully distinguished).
Sys:etc\proxy\data\caloglfn.htm: Used for accelerators that have an LDAP profile with login name formats of field name.
Sys:etc\proxy\data\caloglma.htm: Used for accelerators that have an LDAP profile with login name formats of e-mail.
Sys:etc\proxy\data\caloglma.htm: Used for RADIUS-based authentication profiles.
The requirements for an LDAP profile login page for login name formats of Distinguished with LDAP contexts can be found in calogdp.htm:
The attribute name context needs to be present.
The attribute name username needs to be present and be of Type TEXT.
The attribute name password needs to be present and be of Type PASSWORD.
The attribute name url needs to be present and be of Type TEXT.
The same attributes as explained for calogldp.htm 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.htm 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.htm 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.htm 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 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 is 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, as follows:
set accelerator accelerator name loginpage=subdir from etc proxy data
(for example: set accelerator nike loginpage=nike)
then the proxy looks for:
sys:etc\proxy\data\nike\calogout.htm
Because of 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\data /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 you do not want to copy the full list of customized pages, you can use the copy command to copy specific directories. 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.