A shared secret is an object that holds name and value pairs for Form Fill and Identity Injection policies.
If your HTML form prompts a user for more than credential information, you need to create a shared secret to store the values.
If your web server requires some name/value pairs to be injected and these are not available from the HTTP request, you need to create a shared secret to store these name/value pairs so that they can be injected into the header before it is sent to the web server.
Access Manager supports the creation and use of secrets from the following locations:
In the local configuration store
In eDirectory user stores that are running Novell SecretStore
In a user store that has been configured with a custom attribute for secrets
NOTE:Before using Access Manager to store and encrypt secrets, ensure that you choose your Preferred Encryption Method and change the default Encryption Password Hash Key value. If either of these options is changed after any secrets are stored, Access Manager cannot retrieve the secrets.
For more information about configuring Access Manager to store secrets, see Configuring a User Store for Secrets.
This section describes the following topics:
The policy engine allows you to create shared secrets and name the attributes for the store when you create an Identity Injection or Form Fill policy. When you create the shared secret, it is recommended that you name the shared secret after the application for which you are creating the policy. Each value requires a name, it is recommended that you use the same name for the value name as the Input Field Name on a Form Fill policy or for the header name on an Identity Injection policy.
For example, if your email application requires the email address for the name on the login form, you can set up the following Shared Secret values:
|
Input Field Name |
Input Field Value |
Shared Secret Name |
Entry Name |
|---|---|---|---|
|
emailaddress |
Shared Secret |
emailapp |
emailaddress |
Your applications, how you use them, and your personal preferences determine whether you create one shared secret and use it for all your applications or whether you create a shared secret for each application.
If the applications use some of the same secrets, you can use the same shared secret for these applications. In this case, give the shared secret a name that reflects all of the applications using it.
If an application does not use the same secrets as another application and you want the freedom to remove the application and its secrets without affecting other applications, you must create a separate shared secret for this application.
If you are using Novell SecretStore, the secret names specified in your Access Manager policies need to match the names you have already configured.
A local shared secret store does not contain any name/value pairs until you configure a Form Fill policy to add name/value pairs or enable Allow End Users to See Credential Profile. This option allows the username and password to be stored in the local secret store. To set this option, click Devices > Identity Servers > Edit > Liberty > Web Service Providers > Credential Profile.
You can create, edit, and delete the values of a shared secret in the following scenarios:
When you use a Form Fill policy.
When you log in to Identity Server and use the default landing page. Click on Profile > My Profile > Credentials > Credential List. This will be allowed only after enabling the Allow End Users to See Credential Profile as mentioned above.
When you use other NetIQ products such as Identity Manager and Secure Login. This can be used if you are using external eDirectory secret store.
The Identity Injection policy can use the shared secrets, but will not allow to create/edit/delete the values of shared secrets.
You can create a shared secret as part of the process of creating a Form Fill or Identity Injection policy. You can also create a shared secret independent of a policy.
Click Devices > Identity Servers, then click Shared Settings > Custom Attributes.
Click New in the Shared Secret Names section and specify the following details:
Secret Name: Specify a display name for the shared secret.
Secret Entry Name. Specify an attribute name for a value you want to store.
Click OK.
Identity Server creates and encrypts the object.
To create additional attributes to store values, click the secret name, click New, specify a name, then click OK.
Click OK.
Before deleting a shared secret, you need to delete policies that are using the shared secret or modify the policies to use a different shared secret. For information about deleting policies, see Deleting Policies.
Both Form Fill and Identity Injection policies can use shared secrets. Perform the following steps to modify an Identity Injection policy to use a new shared secret and then delete the old shared secret:
Click Policies > Policies > [Name of Policy] > [Rule].
Select Value that uses the shared secret you want to delete. Click its name, then click New Shared Secret.
Specify the name for a new shared secret, then click OK.
Click the name of the shared secret, select the new shared secret store, then click New Shared Secret Entry.
Specify the attribute name for this shared secret entry, then click OK.
Modify any other Value fields to use the new shared secret. Create new attributes as needed.
Click OK > OK > Apply Changes.
To delete the old shared secret, click Identity Servers > Shared Settings > Custom Attributes.
Select the name of the old shared secret and the attributes, then click Delete.