This section highlights iChain's core features:
iChain sits between your Web applications (servers, portals, etc.) and your users. iChain acts as an HTTP proxy with support for both HTTP 1.0 and HTTP 1.1 features. Data that is marked as cacheable is cached in an iChain Web cache, significantly reducing the load on the Web application server.
To guard against unauthorized user access, iChain supports a number of authentication methods, including user identifiers (name, e-mail address, and other LDAP attributes), passwords, token-based authentication, and X.509 digital certificates. The following authentication mechanisms are supported:
LDAP Authentication: This is a way to log in a user based on criteria used to locate a unique user and the user's password. There are many options that refine how a unique user is found within an LDAP directory. iChain supports contextless logins, as well as administrator-defined searches.
Mutual Authentication: This applies when the user is issued a certificate from a trusted source. The certificate identifies the user in some way. To ensure the validity of X.509 certificates, iChain supports both Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) methods of verification.
RADIUS Authentication: To accommodate secure, token-based authentication, iChain uses the Remote Authentication Dial-in User Service (RADIUS) protocol. RADIUS enables communication between remote access servers and a central server. Secure token authentication through RADIUS is possible in iChain, out of the box, because iChain includes Novell Modular Authentication Service (NMAS™) RADIUS software that can be run on an existing NetWare® server. iChain supports both PIN and challenge and response methods of token-based authentication. In other words, RADIUS represents token-based authentication methods used to authenticate a user, based on something the user possesses (for example, a token card). Token challenge-response is supported for two-step processes that are necessary to authenticate a user.
Multi-Factor Authentication: This method combines several authentication methods to produce an even higher level of security. For example, a company might require that a user present a valid User ID and password, as well as an X.509 certificate, before access is granted. Different levels of access can be required for different Web servers.
Secure Cookie: iChain requires at least 48 bits of random data to be matched for authentication. You set up the secure cookie in the command line interface. See Section 18.3.3, Setting Up Enhanced Security Within the Authentication Cookie.
NOTE:An old version of session broker can handle the new secure cookie. However, all iChain boxes that are connected to a session broker must use the same cookie version. There cannot be mixed mode support for old and new cookies, which is why the new cookie version is not the default. For more information about Session Broker, see Section 10.1, What is Session Broker?.
The iChain Proxy Server is the gatekeeper to your Web-based applications. If a user is not permitted to access a particular Web page or application, the Web server/application server will never receive the request. iChain manages access to services through “protected resources,” which are defined in eDirectory. A protected resource can be defined as:
Public: Access is granted with no security checks
Restricted: Requires only user authentication
Secure: Requires authentication and association to an access control object (see Identity-Based Access Control for more information)
To add flexibility when defining these protected URLs, iChain offers wildcarding (*) and entire folder (?) options.
iChain's formidable security infrastructure begins with the iChain Access Control object. This object contains a list of iChain protected resources or URLs and a list of users, groups, or containment (O, OU) objects that can access these resources. Multiple iChain Access Control objects can be configured to provide maximum flexibility to meet an organization's security policy. Without an association to an Access Control object, a user is denied access to any protected resource that is defined as secure.
In addition to a user being granted access based on his or her association to an iChain Access Control object, iChain also provides a dynamic access control process that looks at specified details of a user's identity (for example, jobTitle=manager) and grants access based on that information.
Whether the user of your Web application is an employee or a potential customer, the experience that person has with the Web application is often determined by convenience. To enhance each user's experience, iChain incorporates an innovative service called Web single sign-on, where users need to log in only once to gain access to multiple applications and platforms.
Single sign-on is possible because iChain authenticates the user from a centralized eDirectory profile. When the user requests access to a specific server, iChain retrieves the appropriate user credentials and transparently submits them to the Web server, usually in the form of username and password. The user does not see a login request, but is immediately granted or denied access based on the single sign-on policy.
iChain also offers users a convenient form-fill authentication feature that simplifies access to Web applications. With the form-fill feature, the user first authenticates to iChain before accessing the Web-application's authentication form. As the user enters his or her credentials, the information is automatically stored securely to the user's object in eDirectory using Novell SecretStore™ technology. From then on, when the user connects to that Web application, iChain automatically retrieves the user's credentials and completes the form on the user's behalf.
By making your services more readily available, you can strengthen customer loyalty and offer employees convenient access to business-critical information. Single sign-on also lowers the overhead costs associated with maintaining many different tables of usernames and passwords on numerous servers.
When organizations want to ensure the confidentiality of data as it crosses the Internet, they usually implement SSL services for the Web servers, which increases management (certificates must be installed on each Web server), can increase costs, and can reduce the performance of content delivery (Web server processing power is dramatically reduced when it needs to encrypt data).
To address these issues, iChain provides Secure Exchange, which can dynamically encrypt the data channel between the browser and the iChain Proxy Server. The content between the iChain Proxy Server and the Web server can be either HTTP (non-encrypted) or HTTPS (encrypted), depending on specific requirements.
Secure Exchange provides a single place to manage SSL certificates (iChain proxy), and allows Web servers to do what they are designed to do: deliver content as quickly as possible. When combined with the caching technology on the iChain proxy, the speed of the overall service is greatly increased.
This feature not only performs on-the-fly encryption of data, but it also rewrites the HTML links from HTTP to HTTPS, meaning that there is no need for an administrator to change HTML content, a task that must be performed when SSL is implemented at the Web server.
The combination of iChain's multi-homing and Secure Exchange features means that content from many Web servers can be encrypted over the network using a single SSL certificate, further reducing management and deployment costs.
iChain provides secure access to Citrix* thin-client services that use the Citrix ICA protocol. This includes single sign-on to Citrix Nfuse* and iChain-authenticated access to Citrix MetaFrame* servers.
Before a session can be established through iChain to a protected Citrix MetaFrame server, the user must have an iChain authentication token. The only way for the user to receive this token is to be authenticated to iChain at the time the Citrix client attempts to connect to the MetaFrame server.
iChain's secure access for the Citrix thin client also provides the additional benefit of supporting Citrix client connections over standard port:80 (client to iChain proxy). iChain relies on the Citrix client's own encryption capabilities.