Previous Page: Using Multi Certificate Authorities  Next Page: Using Token Authentication with iChain

Using Cross-Domain Authentication

In iChain 2.1, Cross-Domain Authentication (CDA) provides a graded authentication feature that allows an iChain server administrator to build a trust relationship (CDA) among different domain types (for example,,, and Inside this CDA, same types of authentication method will only login once.

CDA Scenario and Examples

The following scenario and examples can be used to clarify how CDA works:

These accelerators are CDA-enabled and their authentication methods are as follows: --- LDAP authentication --- Certificate (Mutual) authentication --- Certificate (Mutual) and LDAP authentication

Single Sign-on Example (same grade with same authentication methods): If authentication methods of all accelerators are the same (for example, all LDAP/certificate, or all certificate and LDAP), once a user logs in to a domain, he or she can access any other domains without having to log in to them.

Graded Authentication Example 1 (from grade high to low): If a user accesses first, he or she will be asked to log in twice; once for certificate and again for LDAP. After the user accesses, he or she can access (or without any login.

Graded Authentication Example 2 (from grade low to high): If a user accesses (or first, he or she will be asked to log in for an LDAP (or certificate). if the user wants to access, he or she will be asked to log in for a certificate.

Graded Authentication Example 3 (same grade but with different authentication methods): If a user accesses first and then later accesses, he or she will be asked to log in twice; once for with LDAP and again for with certificate (then the user can access without logging in).

These four examples show that with CDA-enabled accelerators, the same type of authentication will require logging in only one time. By doing so, CDA provides the user-friendly features of Single Sign-on.

Selecting Accelerators as Members of CDA and the Cross-Domain Broker

In Cross-Domain Authentication, only one accelerator can be chosen as a Cross-Domain Broker (DB), while other accelerators are non-DBs. The DB will work as a coordinator to see whether a successful authentication (login) has been performed. The CDA feature should only be enabled when there is more than one accelerator with authentication turned on and users want to use Single Sign-on and graded authentication among these accelerators.

Before choosing accelerators as members of CDA, consider the following criteria:

  1. Security (trust and single cookie)
  2. Graded authentication (with Single Sign-on)
  3. Performance

Security is the first concern. For example, if you have and with certificate authentication for both accelerators, if the certificate for is not trusted by, one (or both) of them should not be CDA-enabled. If both accelerators are CDA-enabled, a user can log in to one of the accelerators but will not be prompted to log in again when he or she accesses the other accelerator. Because CDA uses a single session cookie for all CDA-enabled accelerators, if a user logs out or times out from one of the accelerators, he or she will be logged out from all CDA-enabled accelerators.

CDA provides a Single Sign-on feature by allowing accelerators with the same type of authentication to require log in only once.

NOTE:  For accelerators that use different authentication methods, it is not recommended to use CDA unless one session cookie is important for these accelerators. (For example, uses Radius authentication, uses LDAP, and uses certificate. In this example, there are no common authentication methods among,, and

CDA uses redirection to set and get the session cookie between DB and non-DB accelerators. The overhead for these additional redirections had little performance impact because it reduces the total number of logins that involve manual interaction. There is no extra redirection when accessing a DB-enabled accelerator.

The selection of a DB is critical in CDA. Selection of a member of CDA as the DB should be based on the following criteria:

  1. You must never disable a DB-enabled accelerator. (You must never disable its authentication, either.)
  2. Because there is no extra redirection when accessing a DB-enabled accelerator, we recommend that you select the most frequently accessed accelerator to be the DB.

NOTE:  Criterion 1 is required. If Criterion 2 is difficult to meet, you can select any CDA member to be the DB.

Configuring CDA

You can configure the CDA by following these steps:

  1. At the iChain Proxy Server GUI, click Configure > Web Server Accelerator > Domain.

    The Cross Domain Authentication Settings screen will appear (see Figure 17).

    Figure 17
    Cross Domain Authentication Settings

  2. At the Cross Domain Authentication Settings screen, select the boxes of accelerators you want to be CDA members.

  3. Select Domain Broker from the enabled CDA members by checking the radio button among these members.

NOTE:  You should use the same authentication profile for the same type of authentication (for example, you should only use the "ldapx" authentication profile for all LDAP authentication of all CDA accelerators).

CDA and Session Broker

When using Session Broker, all groups of accelerators participating in CDA should be configured identically. Session Broker relied on the fact that groups of accelerators are a single entity. Therefore, if an accelerator is participating in CDA on one machine, then is should be participating in an identical CDA on all other machines with that accelerator. For security reasons, when using CDA with Session Broker, the browser must be closed in order to enforce logouts.

  Previous Page: Using Multi Certificate Authorities  Next Page: Using Token Authentication with iChain