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 Novell 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) creates 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. Starting with iChain 2.3 SP5, both the LDAP profile and the SecretStore processor use the LDAP servers which are configured for the iChain ACLCHECK profile. As a result, the algorithm that takes care of LDAP load balancing and failover now also provides fault tolerance for OLAC. (For more information about this LDAP feature, see Section B.0, Using LDAP Server Load Balancing and Failover.)
To enable SecretStore, add the following lines to the oac.properties file:
[SECRETSTORE Processor] Initial Context Factory = com.sun.jndi.ldap.LdapCtxFactory Class Name = com.novell.ichain.oac.secretstore.ParamListBuilder
If you have configured the OLAC LDAP processor for a non-secure port, you need to add the following lines:
Security Authentication = ssl Client Certificate File = svr243IP.der
The OLAC LDAP processor can run on the non-secure port, but the SecretStore processor must run over SSL. These two lines configure the SecretStore processor for SSL. Replace the value for the Client Certificate File option with the name of the trusted root certificate you have installed on iChain for accessing the LDAP server. This certificate is located in sys:\.
Having OLAC LAP use non-secure communication and SecretStore use secure communication is not a recommended configuration. The health check built into proxy cannot detect problems with SSL communication if the normal communication to the LDAP server is set up for non-secure communication. It checks the LDAP servers according to the authentication profiles defined in the system, which means it checks the non-secure communication process and does not check the secure communication process.
IMPORTANT:Enabling the Shared Secrets plug-in for OLAC might significantly affect the system's performance, because Shared Secrets requires SSL binds for each user to get the secrets.
The following are known limitations for using OLAC with Shared Secrets:
For Mutual and RADIUS authentication, there is no password. This means you cannot use Shared Secrets for these types of authentication because they require a user name and password.
In Shared Secrets, administrators can define duplicated names in name=value pairs. There is no way for OLAC and Form Fill to pick the right name=value because OLAC and Form Fill aren't interactive applications. This means if you have a duplicated case, you should not define it for OLAC or Form Fill.
OLAC and Form Fill currently only support login credentials (for example, SS_CredSet).