Novell Documentation: Novell iChain 2.0 - Setting Up Object-Level Access Control

Setting Up Object-Level Access Control

The iChain service enables you to integrate and allow access to Web-based applications. Sometimes these resources or objects need additional access control or application information about the user to be passed into the application. This additional information about the user can be stored in NDS or some other database. Within iChain, these resources are called Protected Resources and access to them is set up through the Protected Resources tab of the iChain Service object. Refer to Creating an iChain Service Object for basic setup information.

To implement this feature, a special iChain object-level access control (OLAC) plug-in (an LDAP plug-in) is available to access the database and retrieve the additional information. By default, this plug-in allows you to define attributes that are embedded and passed within the HTTP request header. You can assign a name as the tag to the data.

The following table lists the LDAP plug-in's corresponding entries for the Data Source and Value fields in ConsoleOne.

Plug-in	Description	Data Source	Value
LDAP	Adds user attributes from a directory with LDAP support.	ldap (case-insensitive)	Any LDAP user attribute (for example, surname, givenName).

Because the LDAP plug-in is based on iChain APIs, you may customize iChain and create OLAC plug-ins to integrate your applications as needed. The APIs for customizing your iChain infrastructure are available in the iChain Novell Developer Kit (NDK). Novell NDKs are available for download at Novell Developer site.

NOTE: Only administrators familiar with programming principles and Java* programming syntax should attempt to customize OLAC plug-ins.

The settings for the OLAC framework and LDAP plug-in are stored in the OAC.PROPERTIES file, which is typically found in the SYS:/ICHAIN/OAC directory on the iChain Proxy Server. The configuration file contains a section for the framework as well as one for the plug-in. The following table lists the valid OLAC options for each section:

Name	Description	Required?	Default Value
Object-Level Access ControlOptions [OAC] section
Security Authentication	The method to use when authenticating to the LDAP server. Currently, only "simple" is supported.	No	simple
Server Port	The port on which the OLAC framework will listen for lookup requests from the proxy server.	No	4444
Worker Count	The number of worker threads to create.	No	10
Refresh Time	The number of minutes after which the OLAC configuration will be re-read from the ISO.	No	60
Value Delimiter	The delimiter used to separate multiple values assigned to the same name in the URL query string. For example, if Value Delimiter is specified as ";", the resulting query string might look like COLORS=blue;green; yellow;orange&SHAPES=circle;square;triangle.	No	, (comma character)
LDAP Plug-In Options [LDAP Processor] section
Security Authentication	The method to use when authenticating to the LDAP server. Currently, only "simple" is supported.	No	simple
Class Name	The name of the class implementing the LDAP plug-in. Must be com.novell.ichain.oac. ldap.ParamListBuilder.	Yes	None

OLAC Custom Header Variables

You can pass the OLAC parameters defined for a protected resource as a part of the HTTP header itself. Thus, if needed, you can forward more of the OLAC parameters/values to the Web or application servers than would be possible by sending them as a part of the query string.You can specify if the OLAC parameters needed to be passed either as a part of the query string or header variables while defining the protected resource in ConsoleOne (as shown by radio buttons at the Add New Protected Resource dialog).OLAC parameters in the header variables must be taken care of while parsing and are specified in the following format:

x-<olac-param name>:<olac-param value>

NOTE: The letter x- is prefixed for all of the OLAC parameters (custom variables) in the header. This is done to negate or minimize name collisions between OLAC and non-OLAC parameters residing in the header.

When sending an attribute value from NDS through OLAC using LDAP, the total length of the query string should not exceed 255 characters or the authentication header will fail to appear (or it will appear with the username and password instead of the attribute that was mapped by the ICHAIN_UID parameter). The HTTP headers will also fail to appear.- trying to send an attribute value from NDS through OLAC via LDAP.

Customizing the Authentication Header

Using iChain 2.0's OLAC feature, you can customize the authentication header as described below.

By default, iChain puts the fully qualified distinguished name and user-entered password in the authentication header. However, administrators might want to change the content of this header by changing the value of the username or password. This customization may be required because some Web servers (Microsoft IIS*) require the common name (CN) instead of DN as the username. Using OLAC, you can customize the authentication header.

For a particular protected resource, you can define special OLAC parameters, such as ICHAIN_UID and ICHAIN_PWD, to change the values of the authentication header. The values returned by OLAC will be placed in the authentication header as username and password, respectively.

For example, if you define the ICHAIN_UID=CN and ICHAIN_PWD=SSN OLAC parameters for a protected resource, OLAC will return the values of CN and SSN attributes of the logged-in user. iChain will use these values as the username and password to construct the authentication header and will send it to the Web server.

Both of these parameters are optional. If only one parameter is defiined, such as ICHAIN_UID=CN, the other parameter value will be filled with default behavior, such as a password, provided by the user.

IMPORTANT: If you have defined these special parameters and OLAC is not enabled or the value of the given attribute is NULL, iChain will pass NULL in the authentication header.