OLAC Parameters
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 additional plug-ins called CONSTANT, SECRETSTORE, and INTERNAL. The CONSTANT 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.
The INTERNAL OLAC data source obtains user information that is available in the proxy. This allows the login query string to be passed to the Web server. It displays content based on login information. The following table lists the OLAC values and corresponding entries for the INTERNAL data source.
The OLAC Parameters dialog box is shown here:
Figure 18
OLAC Parameters
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 the 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:
Table 3. Valid OLAC Options
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. Exceeding this number of characters might cause the authentication header to fail to appear for some Web browsers/servers (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. See Figure 58.
Using the iChain OLAC feature, you can customize the authorization header as described below.
By default, iChain puts the fully qualified distinguished name and user-entered password in the authorization 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 authorization 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 authorization header. The values returned by OLAC will be placed in the authorization 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 authorization 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 via Forward Authorization.
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 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.
More Web service applications are using single sign-on or are sharing some application information. Administrators might want to preconfigure user credentials so the user never sees what his/her credentials are for various applications. Novell products including Novell Portal Services, Novell Secure Login, and iChain OLAC might share login credentials (user name and password).
Shared Secrets is a new feature that allows the sharing of a user's secret credentials across applications. Administrators can register users' credentials, and can only create and/or overwrite the credentials. The same as with a password, administrators cannot read and/or retrieve users' credentials.
The shared secret is identified by <type>:<name>, where <type> is the type of shared secret and <name> is the name of the shared secret.
NOTE: In order to use Shared Secrets, the administrator must install SecretStore version 3.x on the iChain Authorization Server.
The OLAC plug-in for Shared Secrets supports defining OLAC parameters at the level of the key name of the SS_CredSet shared secret. The datasource name is SECRETSTORE.
For example, this can be defined in the OLAC configuration screen in ConsoleOne as described in the following table:
where SS_CredSet is the type of shared secret, and ss1 is the name of the shared secret, and CreditCardNo is the key name in this particular shared secret.
NOTE: Use a double backslash (\\) to escape. The double backslash is necessary because Novell Secure Login (and other products) has created the Share Secret containing an escape (backslash) character. To use this secret through OLAC, you must add an additional backslash.
Shared Secrets allows only secure channels for applications that want to communicate with it. OLAC can be configured to run over non-SSL when communicating with the LDAP server, while the secret store plug-in for OLAC can be configured to run over SSL. Administrators can configure the secret store plug-in using the oac.properties file. See Table 3 for more details. The administrator will need to have an IP certificate file (.der) on the iChain Proxy server. This certificate can be the same as the one OLAC uses for LDAPS. The secret store plug-in will also use the same keystore (which is dynamically created) as used for OLAC.
A typical configuration of the SecretStore plug-in in your oac.properties file is as shown:
[SECRETSTORE Processor]
Initial Context Factory = com.sun.jndi.ldap.LdapCtxFactory
Provider URL = ldap://227.229.259.243:636
Security Authentication = ssl
Client Certificate File = svr243IP.der
Class Name = com.novell.ichain.oac.secretstore.ParamListBuilder
WARNING:
Enabling the Shared Secrets plug-in for OLAC may significantly affect the system's performance, as Shared Secrets requires SSL binds for each user to get the secrets.
The following are known limitations for using OLAC with Shared Secrets: