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.