Novell Home

AppNote: iChain Authentication Process

Novell Cool Solutions: AppNote
By Martin Day

Digg This - Slashdot This

Posted: 24 Nov 2004
 

Martin Day
mday@novell.com

iChain 2.3 can authenticate users in different ways. Not only can it accept user credentials using different methods but it can also validate the credentials using different methods. At the end of the authentication process, iChain must be aware of the user's distinguished name (DN) so that access control rules can be found for that particular user as well as any user attributes required for injection. The credentials required may restrict the options for submitting and validating them as will be seen below. There are 3 generic authentication profiles: two of which (LDAP and RADIUS) refer to the protocol used to validate the credentials; the third profile (mutual authentication) makes use of an optional feature of SSL where iChain can prompt the client for a user certificate.

The Admin guide describes how these profiles can be combined for multi-factor authentication. This article attempts to clarify the authentication options.

Password Authentication with LDAP

Prompting for Credentials

There are three general ways for iChain to ask a user for username/password credentials with the LDAP profile. These 3 can be modified slightly as will be seen.

  1. Form-based authentication

    This is the default method which happens over an SSL connection. When a client issues a request via iChain the proxy performs various redirections but ultimately issues a "302" redirect to the login page. Depending on how the LDAP profile is set to validate the credentials, different login pages are presented:

    • caloglnc.htm. This is used when the LDAP login method is set to "Build distinguished name" and no default contexts are provided. The login page consequently has no drop down box containing contexts.
    • calogldp.htm. This is as above except one or more default contexts have been defined so that the login page can present a drop down box containing contexts.
    • caloglfn.htm. This is used when the LDAP login method is set to either of the LDAP search methods available.

    a) Without SSL. When this LDAP authentication profile is associated with a particular accelerator (within the "Enable Authentication" tab of the individual accelerator), there is a tick box option to "Prompt for username/password over HTTP". In this case, initial user requests are redirected (via a "302" redirect as above) without first performing a redirect for HTTPS (HTTP over SSL). This approach means that user credentials are POSTed in the clear with obvious security concerns attached.

  2. Basic Authentication via a dialog pop-up.
  3. This approach is enabled within the authentication profile via the "Allow authentication via HTTP Authorization header". When a HTTP Authorization header is used, user credentials are not POSTed in response to an HTML form, but are instead included in a HTTP header sent by the client. The authentication scheme used is "Basic" which means that the username and password are concatenated with a colon separator and then Base64 encoded -- WHICH IS NOT ENCRYPTION. Although the default behaviour is to use SSL for the authentication, the nature of the HTTP Authorization header means that the client includes the header for subsequent requests. If Secure Exchange (SSLizer) is not used, then the credentials can be observed on the wire which is an obvious security concern.

    This option is subdivided into two implementations. To understand the reason for this, it is necessary to understand the primary reason for allowing the HTTP Authorization header at all. There may be situations where an automated process (with no user operator sat at a web browser) is used to access iChain-protected resources. Such processes would not typically be able to respond to a customizable form by inserting correct credentials. Instead they are usually able to build a Basic HTTP Authorization header (from stored credentials) which is included in the initial and all subsequent requests. Alternatively, they may issue the initial request without the HTTP Authorization header but be able to recognise a "401" response from iChain (which also includes a "WWW-Authenticate" HTTP header) and so provide the HTTP Authorization header in subsequent requests.

    However, the same iChain protected-resource may be accessed by users from a browser as normal. When a browser issues a request and receives a "401" response, it pops up its own dialog box prompting for credentials. Such standard access is best performed via a HTML form instead as it can be customised with corporate logos as well as provide additional information beyond a simple pop up. Hence there is an option for iChain to accept a HTTP Authorization header for authentication purposes but still revert to a standard "302" redirect and Form-based login when the HTTP Authorization header is NOT present in the initial request. The following settings in the LDAP authentication profile determine this behaviour:

    • "Use basic/proxy authentication". This option accepts initial requests containing HTTP Authorization headers, but if not present, issues a "401" response resulting in pop up boxes with browsers.


    • "Use iChain login page". This option accepts initial requests containing HTTP Authorization headers, but if not present, issues a "302" redirect and presents the normal HTML form to browsers.

    Current versions of the iFolder client can only authenticate to iChain using HTTP Authorization headers (typically known as Basic Authentication).

    a) Without SSL. When this authentication profile is associated to a particular accelerator (within the "Enable Authentication" tab of the individual accelerator), there is a tick box option to "Prompt for username/password over HTTP". As previously discussed, iChain does not redirect HTTP requests to HTTPS before commencing the authentication process above.

  4. NetIdentity authentication
  5. Clients with the NetIdentity agent installed can benefit from single sign on to iChain if the NetIdentity wallet contains the login credentials. Typically, this means that the user must already have logged into eDirectory which populates the wallet. If the wallet does not contain the credentials then when iChain prompts for NetIdentity authentication, a pop-up authentication dialog will appear. This pop-up is presented by the NetIdentity client rather than a browser pop-up.

    This authentication process is very similar to the HTTP Authorization header authentication discussed earlier. When the NetIdentity client is installed, all browser requests include an additional HTTP header called "Novinet". iChain will recognise this and change its authentication behaviour if "Allow authentication through NetIdentity" is enabled. In this case, iChain will issue a "401" response and include a "WWW-Authenticate" header as before. However, this latter header will indicate that a custom authentication scheme be used instead of Basic. This scheme involves iChain sending a challenge. The NetIdentity client will take the user credentials from the wallet (or from the pop up dialog it presents) and effectively encrypt them with the challenge sent by iChain. This encrypted authentication data is sent back to iChain in a HTTP Authorization header allowing iChain to authenticate the user.

    If the client does not have the NetIdentity client installed then browser requests will not include the "Novinet" header and so iChain will fall back to a standard LDAP authentication mechanism where it issues a "302" redirect and presents the HTML form as discussed earlier. A benefit of this authentication method is that recent client versions of Zen for Desktops can access the MidTier service for application delivery within a browser via iChain which can authenticate the connection.

    a) Without SSL. When this authentication profile is associated to a particular accelerator (within the "Enable Authentication" tab of the individual accelerator), there is a tick box option to "Prompt for username/password over HTTP". As previously discussed, iChain does not redirect HTTP requests to HTTPS before commencing the authentication process above.

Validating Credentials

Regardless of how iChain receives the user credentials, there are two distinct ways that iChain will interact with the LDAP server in order to validate them. This behaviour is controlled by the LDAP login method setting:

  1. Build distinguished name
  2. With this method, the exact behaviour depends on whether iChain is aware of the user's "dn" or whether the user has just supplied their common name ("cn"). The former is possible if the user actually entered their full "dn" (in LDAP syntax) or if they entered their "cn" and selected one of the pre-configured contexts from the drop-down box on the login page.

    • iChain has "dn". In this case, iChain connects to the LDAP server (with or without an SSL connection depending on the relevant configuration setting in the profile). Once the session is established it issues a LDAP BIND request using the credentials provided by the user as the BIND credentials. If the BIND is successful (i.e. an error code of "null") then iChain can be assured that the credentials are valid and the user is authenticated. Of course, if the BIND fails, then the user login attempt has failed and this will be reported to the user via the HTML form (along with a prompt to re-enter the credentials).


    • iChain has "cn" only. In this case, iChain concatenates the user-supplied "cn" with the first pre-configured context defined in the profile in order to make a "dn". It then makes the BIND request as above. If the BIND fails, then instead of failing the login completely, it builds a new "dn" from the user-supplied "cn" and the next context in the list and tries another BIND. This continues until either there is a successful bind or all contexts have been exhausted in which case the login fails. Of course, the more contexts listed, the greater the overhead (and time delay) in validating the credentials if the user in question belongs to a context towards the bottom of the list.

    This validation approach does not make use of the LDAP service account defined in the profile -- only the user's own credentials are used.

    As an aside, the LDAP error code returned from the BIND can provide useful information on which iChain can act. For example, the code may indicate password expiry, account disabled, account locked, time restrictions etc.

  3. Search...
  4. In this case, iChain does not know the user's "dn". There are actually two search methods. In most cases a single attribute is used. However, a complex search query can be used which searches for multiple attributes associated with a user. (Note; the login pages must be modified to prompt the users for the attributes which are to be searched on.) It should be apparent that if complex LDAP searches are required (e.g. it is required that users must enter both their username and employee ID for identification) then this restricts the authentication to be via a HTML form only -- the HTTP Authorization and NetIdentity authentication methods are not flexible enough for this. For the purposes of this discussion, credential validation via a single attribute is considered.

    The behaviour here involves a two step process. Although this suggests a greater overhead, it is certainly more flexible than the previous method. Furthermore, if there are numerous user contexts the overhead can actually be significantly less than the previous method.

    • Step One -- Search for the user's "dn" given one (or more) attribute(s). By default, the attribute used is "cn" but this can be pretty much any suitable attribute (e.g. email, employee ID, payroll number etc.). Here, iChain performs an LDAP BIND using the LDAP service credentials entered in the profile. This service account must have rights to search for the required attributes.

      Once the BIND is made, iChain then issues an LDAP search from the defined searchbase in order to find user objects for which the relevant attribute is true e.g. cn=MDAY. The LDAP server will search eDirectory for matching users. It is important that unique attributes are used so that there is only one matching user object. The LDAP server then returns the user's "dn" to iChain in the search response. Note; any attributes searched for should be indexed to improve performance -- several attributes, including "cn", are automatically indexed by eDirectory.
    • Step Two -- Perform an LDAP BIND using the discovered "dn" and the user-supplied password. This step is then the same as for the distinguished name method -- a LDAP BIND is made using the discovered "dn" and the user-supplied password.

    Hence, this method uses both the user-supplied credentials AND the service account credentials configured in the profile.

    As an aside, there is some confusion between the LDAP service account defined in Authentication profiles and the the account defined within the Access Control tab of the iChain GUI. Although it is common for the two accounts to be the same user, this is by no means a requirement as they perform different functions. The LDAP service account in the Access Control tab is used by iChain to read policy information from eDirectory. For example, it is used to perform LDAP searches in order to find the Protected Resources (PRs), how the PRs are defined (public, restricted, or secure), any attribute injection requirements (OLAC), FormFill policies, and Authorisation rules (commonly called access control rules).

Token Authentication with RADIUS

As LDAP BINDs are used with above profile, this restricts the authentication options to just username and password. It is not currently possible to BIND to a Novell LDAP server using a token, for example. If tokens are required for authentication to iChain then a RADIUS profile must be used.

Prompting for Credentials

Unlike the LDAP profile, there is a very limited choice for sending credentials to iChain. A HTML form MUST be used -- it is called calograd.htm. The only option is whether or not the authentication process happens over SSL or not.

Note; the user only supplies a "cn" with the token code -- iChain does not know the user's "dn".

Validating Credentials

There is little flexibility when it comes to configuring iChain to validate credentials with a RADIUS profile. A single RADIUS server address and port is configured together with a secret that is shared by the RADIUS server. This shared secret allows encryption of the token credential. Note; the username appears in clear text in the RADIUS request.

Novell has its own RADIUS service which hooks into the NMAS framework. It can be thought of as providing a window to some NMAS methods without having to implement a NMAS client component. Token vendors supported are Vasco, ActivCard, RSA, and Secure Computing. Alternatively, any RADIUS server relying on any user data store can be used.

In the standard case, the validation step itself is very straight forward -- iChain sends a RADIUS Access Request message containing the credentials. The RADIUS server checks its configuration for how it should search for the user in question and then responds to iChain with either an Access-Accept or an Access-Deny.

The complexity surrounds how iChain derives the user's "dn". With versions of iChain prior to 2.3, there were 2 approaches:

  1. RADIUS server looks up and returns the user's "dn"
    In this case, the NMAS RADIUS server is usually used. A "Dial Access Profile" is configured with a single attribute-value (AV) pair. The attribute is FDN which will contain the user's DN. The RADIUS server returns the FDN in the Access-Accept packet.


  2. iChain performs an LDAP search for the user's "dn"
    This is generally necessary when the authentication store accessed by iChain RADIUS requests is not the eDirectory where the iChain Service Object (ISO) is located. In that case, iChain would use the LDAP settings in the Access Control profile in order to make an LDAP BIND to search for user "dn's" that correspond to the "cn" provided by the user in the login page. The ldap searchbase and ldap bindanonymous settings are the two settings that control this behaviour.

With iChain 2.3, the above behaviour has been modified. The preferred mechanism is to create an additional LDAP authentication profile with a reserved name of "ldaprad" which works very similarly to point 2 above. This profile merely must exist -- it does not have to be associated with a particular accelerator.

Certificate Authentication via SSL Protocol

The LDAP and RADIUS authentication profiles behave in a similar fashion when prompting for user credentials in that an SSL session is usually established first before requesting the user credentials. The form of SSL used for these mechanisms is referred to as "Server-Side SSL".This means that that the server will present its digital certificate which the client can validate and then use to set up the encrypted SSL session. In other words, the client is able to authenticate the server (i.e. confirm that the server really is what it claims to be (e.g. www.novell.com).

There is an optional extension of this behaviour where the server can request that the client should also present it with a client certificate. In this case, the server can authenticate the client's certificate. In other words, user authentication can be performed by virtue of the SSL session establishment. This form of SSL is known as Mutual SSL as both sides of the session authenticate each other.

iChain does NOT make calls to eDirectory to physically compare the user-supplied certificate to a certificate stored on a user object. Provided iChain trusts the signer of the user certificate and is able to validate the certificate, then the owner of the certificate can be authenticated.

iChain must match the supplied user certificate to a user object in eDirectory. In the default scenario, iChain will extract the "dn" from the Subject Name attribute of the user certificate and consider that user to be authenticated. However, when purchasing user certificates from public certificate service providers (such as Verisign), it is not usually possible to define the entire "dn" in the Subject Name attribute. As a result, iChain can be configured to use various matching rules to associate attributes in the certificate with a specific eDirectory user. The Admin guide gives additional information about these matching rules.

Additional Information

Novell iChain 2.3 Administration Guide


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell