To inject values into the authentication header, you need to know what the Web server requires. For basic authentication, you need to inject the username and password. For a sample policy for a Web server that requires the LDAP username and password to be injected into the header, see Setting Up an Identity Injection Policy
in the Novell Access Manager 3.1 SP2 Setup Guide.
To create and configure an authentication header policy:
In the Administration Console, click
> .Select the policy container, then click
.Specify a name for the policy, select
for the type, then click .(Optional) Specify a description for the injection policy. This is useful if you plan to create multiple policies to be used by multiple resources.
In the
section, click , then select .Fill in the
field.Select
to insert the name the user entered when the user authenticated. This is the most common value type to use for the username.The default contracts assign the cn attribute to the Credential Profile. If you have created a custom contract that uses credentials other than the ones listed below, do not use the Credential Profile as a condition.
If your user store is an Active Directory server, the SAMAccountName attribute is used for the username and stored in the cn field of the LDAP Credential Profile.
Depending upon what the user must supply for authentication, select one of the following:
LDAP Credentials: If you prompt the user for a username, select this option, then select either
(the cn attribute of the user) or (the fully distinguished name of the user). Your Web server requirements determine which one you use.X509 Credentials: If you prompt the user for a certificate, select this option, then select one of the following options depending upon your Web server requirements.
X509 Public Certificate Subject: Injects just the subject field from the certificate, which can match the DN of the user, depending upon who issued the certificate.
X509 Public Certificate Issuer: Injects just the issuer field from the certificate, which is the name of the certificate authority (CA) that issued the certificate.
X509 Public Certificate: Injects the entire certificate.
X509 Serial Number: Injects the certificate serial number.
SAML Credential: Although this option is available for the username, most applications that use SAML assertions use them for the user’s password. For the username, you should probably select an option that allows you to supply the user’s name, such as
or .Your Web server requirements determine the data type you select for the username. LDAP, X509, and SAML credentials are available from the Credential Profile. If you have created a custom contract that uses a credential other than the ones listed in the Credential Profile, you can select one of the following values to insert into the header as the username:
Authentication Contract: Injects the URI of the authentication contract the user used for authentication.
Client IP: Injects the IP address associated with the user.
LDAP Attribute: Injects the value of the selected attribute. For Active Directory servers, specify the SAMAccountName attribute for the username. If the attribute you require does not appear in the list, click
to add the attribute.The
option allows you to determine when to send a query to the LDAP server to verify the current value of the attribute. Because querying the LDAP server slows down the processing of a policy, LDAP attribute values are normally cached for the user session.Change the value of this option from session to a more frequent interval only on those attributes that are critical to the security of your system or to the design of your work flow. You can select to cache the value for the session, for the request, or for a time interval varying from 5 seconds to 60 minutes.
For more information, see Section 4.1.1, Using the Refresh Data Option.
Liberty User Profile:
Injects the value of the selected attribute. If no profile attributes are available, you have not enabled their use in the Identity Server configuration. See Managing Web Services and Profiles
in the Novell Access Manager 3.1 SP2 Identity Server Guide.
Proxy Session Cookie: Injects the session cookie associated with the user.
Roles: Injects the roles that have been assigned to the user.
Shared Secret: Injects the username that has been stored in the selected shared secret store.
You can create your own username attribute. Click Section 5.4, Creating and Managing Shared Secrets.
, specify a display name for the store, and the Access Manager creates the store. Select the store, click , specify a name for the attribute, then click . The store can contain one name/value pair or a collection of name/value pairs. For more information, seeThe
option allows you to determine when to send a query to verify the current value of the secret. Because querying slows down the processing of a policy, secret values are normally cached for the user session.Change the value of this option from session to a more frequent interval only on those secrets that are critical to the security of your system or to the design of your work flow. You can select to cache the value for the session, for the request, or for a time interval varying from 5 seconds to 60 minutes. For more information, see Section 4.1.1, Using the Refresh Data Option.
String Constant: Injects a static value that you specify in the text box. This value is used by all users who access the resources assigned to this policy.
Java Data Injection Module: Specifies the name of a custom Java plug-in, which injects custom values into the header. Usually, you can use either the Novell® Access Manager Developer Tools and Examples.
or option to supply custom values, because both are extensible. For more information about creating a custom plug-in, seeData Extension: (Conditional) If you have installed a data extension for Identity Injection policies, this option injects the value that the extension retrieves. For more information about creating a data extension, see Novell Access Manager Developer Tools and Examples.
The value type you use depends upon how you have set up the application.
Fill in the
field.Select
to insert the password the user entered when the user authenticated. This is the most common value type to use for the password. If you have created a custom contract that uses credentials other than the ones listed below for the password, do not use the Credential Profile for the password.LDAP Credentials: If you prompt the user for a password, select this option, then select
. If the user’s password is the same as the name of the user, you can select either (the cn attribute of the user) or (the fully distinguished name of the user).X509 Credentials: If you use a certificate for the password, select this option, then select one of the following:
X509 Public Certificate Subject: Injects just the subject from the certificate, which can match the DN of the user, depending upon who issued the certificate.
X509 Public Certificate Issuer: Injects just the issuer from the certificate, which is the name of the certificate authority (CA) that issued the certificate.
X509 Public Certificate: Injects the entire certificate.
X509 Serial Number: Injects the certificate serial number.
SAML Credential: Injects the SAML assertion in the authentication header as the user’s password.
Your Web server requirements determine the data type you select for the password. LDAP, X509, and SAML credentials are available from the Credential Profile. You can also select one of the following values to insert into the header as the password:
Authentication Contract: Injects the URI of a local authentication contract that the user used for authentication.
Client IP: Injects the IP address associated with the user.
LDAP Attribute: Injects the value of the selected attribute. For Active Directory servers, specify the SAMAccountName attribute for the username. If the attribute you require does not appear in the list, click
to add the attribute.The
option allows you to determine when to send a query to the LDAP server to verify the current value of the attribute. Because querying the LDAP server slows down the processing of a policy, LDAP attribute values are normally cached for the user session.Change the value of this option from session to a more frequent interval only on those attributes that are critical to the security of your system or to the design of your work flow. You can select to cache the value for the session, for the request, or for a time interval varying from 5 seconds to 60 minutes. For more information, see Section 4.1.1, Using the Refresh Data Option.
Liberty User Profile: Injects the value of the selected attribute.
Proxy Session Cookie: Injects the session cookie associated with the user.
Roles: Injects the roles that have been assigned to the user.
Shared Secret: Injects the password that has been stored in the selected shared secret store.
You can create your own password attribute. Click Section 5.4, Creating and Managing Shared Secrets.
, specify a display name for the store, and the Access Manager creates the store. Select the store, click , specify a name for the attribute, then click . The store can contain one name/value pair or a collection of name/value pairs. For more information, seeThe
option allows you to determine when to send a query to verify the current value of the secret. Because querying slows down the processing of a policy, secret values are normally cached for the user session.Change the value of this option from session to a more frequent interval only on those secrets that are critical to the security of your system or to the design of your work flow. You can select to cache the value for the session, for the request, or for a time interval varying from 5 seconds to 60 minutes. For more information, see Section 4.1.1, Using the Refresh Data Option.
String Constant: Injects a static value that you specify in the text box. This value is used by all users who access the resources assigned to this policy.
Java Data Injection Module: Specifies the name of a custom Java plug-in, which injects custom values into the header. Usually, you can use either the Novell Access Manager Developer Tools and Examples.
or option to supply custom values, because both are extensible. For more information about creating a custom plug-in, seeData Extension: (Conditional) If you have installed a data extension for Identity Injection policies, this option injects the value that the extension retrieves. For more information about creating a data extension, see Novell Access Manager Developer Tools and Examples.
The value type you use depends upon how you have set up the application.
Specify the format for the value:
Multi-Value Separator: Select a value separator, if the value type you have select is multi-valued. For example,
can contain multiple values.DN Format: If the value is a DN, select the format for the DN:
LDAP: Specifies LDAP typed comma notation:
cn=jsmith,ou=Sales,o=novell
NDAP Partial Dot Notation: Specifies eDirectory™ typeless dot notation.
jsmith.sales.novell
NDAP Leading Partial Dot Notation: Specifies eDirectory typeless leading dot notation.
.jsmith.sales.novell
NDAP Fully Qualified Partial Dot Notation: Indicates eDirectory typed dot notation.
cn=jsmith.ou=Sales.o=novell
NDAP Fully Qualified Leading Dot Notation: Indicates eDirectory typed leading dot notation.
.cn=jsmith.ou=Sales.o=novell
Click
.(Optional) To add a second rule, click
in the Rule List.You can inject only one authentication header into an Identity Injection rule. However, your policy can have multiple rules. If you inject two authentication headers, each in a separate rule, the authentication header in the rule with the highest priority is applied, and the authentication header action in the second rule is ignored.
To save the policy, click
, then click .