| |
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, www.c.com, www.l.com, and www.lc.com). Inside this CDA, same types of authentication method will only login once.
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:
www.l.com --- LDAP authentication
www.c.com --- Certificate (Mutual) authentication
www.lc.com --- 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 www.lc.com first, he or she will be asked to log in twice; once for certificate and again for LDAP. After the user accesses www.lc.com, he or she can access www.l.com (or www.c.com) without any login.
Graded Authentication Example 2 (from grade low to high): If a user accesses www.l.com (or www.c.com) first, he or she will be asked to log in for an LDAP (or certificate). if the user wants to access www.lc.com, 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 www.l.com first and then later accesses www.c.com, he or she will be asked to log in twice; once for www.l.com with LDAP and again for www.c.com with certificate (then the user can access www.lc.com 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.
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:
Security is the first concern. For example, if you have www.c.com and www.lc.com with certificate authentication for both accelerators, if the certificate for www.c.com is not trusted by www.lc.com, 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, www.lc.com uses Radius authentication, www.l.com uses LDAP, and www.c.com uses certificate. In this example, there are no common authentication methods among www.l.com, www.c.com, and www.lc.com.)
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:
NOTE: Criterion 1 is required. If Criterion 2 is difficult to meet, you can select any CDA member to be the DB.
You can configure the CDA by following these steps:
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
At the Cross Domain Authentication Settings screen, select the boxes of accelerators you want to be CDA members.
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).
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.
| |