Working iChain formfill policy not working with Access Manager shared secrets

  • 3823293
  • 18-Jan-2007
  • 26-Apr-2012

Environment

Novell Access Management 3 Netware Access Gateway
Novell Access Management 3 Linux Access Gateway
Novell Access Management 3 Access Administration
Novell Access Management 3 Linux Novell Identity Server
Novell iChain 2.3

Situation

iChain 2.3 was setup to use formfill to single sign on to a back end Web server page that presented a HTML login form asking for a userID field (type text) and password (type password). The setup used the '~' character so that the user would be prompted to authenticate the first time the Login page was displayed and iChain would store those credentials in the users iChainformfillcrib attribute for future use.

After upgrading to Access Manager and using the Linux or Netware Access Gateway to accelerate the same Web site, the users were continuously being prompted to enter their credentials ie. there was no single sign on using formfill.

Resolution

Make sure that the secret store parameters are setup correctly in the 'input field name'. All form information had been setup correctly (form name, matching criterias, fill options) but the input field name was incorrect.

When creating the form fill policy, the equivalent operation to the iChain '~' character and the iChainformfillcrib attribute on Access Manager is the Local Shared Secret.The policy engine allows you to create local secret stores and name the attributes for the store as you are creating an identity injection or form fill policy.

A local shared secret does not contain any name/value pairs until you configure a form fill policy to add name/value pairs or enable the Allow End Users to See Credential Profile option. (Click Identity Servers>Setup>[Configuration Name]> Liberty>Web Service Providers.)


In the above case, we created it manually by initally setting the'Input field value' to Shared Secret. Selecting the Shared secret is the next option (page with title of 'Select shared secret') where we created a new secret. The administrator created a LoginCredentials secret, although any name could be taken. Selecting the LoginCredentials secret will provide the administrator with the option to create additional subsecrets. In this case, we created an additional two secrets - LoginID and LoginPwd.

By assigning the LoginCredentials -> LoginID to the 'UserID' parameter name mentioned above and the LoginCredentials -> LoginPwd for the 'password' parameter name, the single sign on worked fine.