Previous Page: Setting Up Web Single Sign-on Services  Next Page: Setting Up Form Fill

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 Novell eDirectory® 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 in LDAP datastore that are embedded and passed within the HTTP request header or as a query string. You can assign a name as the tag to the data.

iChain also supports an additional plug-in called CONSTANT. This plug-in allows you to pass the same constant literal with every OLAC request. This is particularly valuable when an application requires a constant to be passed and the administrator does not want to include the constant in each user object (for easier setup and maintenance).

The following table lists the LDAP and CONSTANT plug-ins' 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).

CONSTANT

Adds the constant literal for every OLAC request, where defined

constant (case-insensitive)

Constant Literal (for example, "string123")

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 Frameworks and its plug-ins are partly stored in the iChain Access Control profile and partly from 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

80

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 eDirectory through OLAC using LDAP, the total length of the query string should not exceed 255 characters for some Web browsers/servers 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 may also fail to appear.- trying to send an attribute value from eDirectory through OLAC via LDAP.


Customizing the Authentication Header

Using iChain 2.1'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 defined, 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.


OLAC Caching

OLAC has two levels of caching: The first level of OLAC caching occurs in OLAC server (OACJAVA), which caches the protected resource name and its associated OLAC parameters, data source, and value (the name of the attribute in case of LDAP) initially when the OLAC server is started and/or when it is issued an OACREFRESH command.

Administrators can refresh OLAC from the Web GUI (at the Access Control tab) or they can run OACREFRESH from the NetWare prompt (not the iChain prompt) on the iChain console. OACREFRESH is a java program that opens a socket to the OLAC server and sends the REFRESH command. After receiving the command, the OLAC server refreshes the cache. OLAC is also refreshed when the administrator opts to refresh the iChain Proxy configuration in the ISO snap-in in ConsoleOne after making changes. OLAC also auto-refreshes every "n" minutes, where "n" is specified in the OAC.PROPERTIES file. This value currently defaults to 180 minutes.

The second level of OLAC caching is for "OLAC values" cached in proxy for that user session and cannot be refreshed by any command. The life of this cache is only for that authenticated user session. OLAC refresh gets the changes in the protected resources and associated parameter definitions. It does not refresh any LDAP connections. The administrator must restart OLAC for those changes to take effect. Restarting OLAC can be done easily from the Access Control tab in the Web GUI.



  Previous Page: Setting Up Web Single Sign-on Services  Next Page: Setting Up Form Fill