4 Configuring Advanced Local Authentication Procedures. NetIQ Access Manager 4.0
Advertisement
Advertisement
4
Configuring Advanced Local
Authentication Procedures
The following authentication procedures require more than a username and password. Some of them require that you configure another server to provide the user with a token or a certificate.
Section 4.1, “Configuring Social Authentication,” on page 145
Section 4.2, “Configuring for Two-Factor Authentication Using Time-Based One-Time Password
Section 4.3, “Configuring Persistent Authentication,” on page 153
Section 4.4, “Configuring for RADIUS Authentication,” on page 155
Section 4.5, “Configuring Client Integrity Check,” on page 156
Section 4.6, “Configuring Mutual SSL (X.509) Authentication,” on page 157
Section 4.7, “Creating an ORed Credential Class,” on page 164
Section 4.8, “Configuring for OpenID Authentication,” on page 165
Section 4.9, “Configuring Password Retrieval,” on page 166
Section 4.10, “Configuring Access Manager for NESCM,” on page 169
4.1
Configuring Social Authentication
Access Manager can be configured to support authentication through external OAuth providers like
Facebook, Google+, Twitter, LinkedIn, and so on. Social authentication simplifies login for end users and does not require maintaining large user stores. This authentication can be configured using the
SocialAuthClass. Login using social identities provide a convenient way for users, improving customer satisfaction and increased registration levels. For more information on how to configure the supported social authentication providers for API Keys and API Secrets, see
.
Social login allows business, universities and government entities to leverage social identity providers to share select identity information for authentication via OAuth tokens. This information can then be used to provide protected online services ranging from customer-focused applications, university sites to state and local services and more.
4.1.1
Use Case
Authentication through external OAuth providers can be useful in the following two scenarios:
Allow external users to access secure resource
For example, you may want your customers and partners to access https://forums.novell.com.
Creating and managing these external users is a hassle for you and the user. Social
Authentication helps in this scenario.
Configuring Advanced Local Authentication Procedures
145
Users will be allowed to sign in with their Facebook or Yahoo ID. Social authentication provider will give Access Manager a set of logged-in user’s attributes. Hence, you will get user data without maintaining it. Access Manager can use this user data and perform actions based on that if required.
Apply policies to restrict users to access a protected resource
If the Identify User Locally option is selected, the social provider user will be mapped to the local user and you can execute authorization policies based on the user attributes. For example, if Joe is a Facebook user, you can match the attributes of Joe in the local user store based on a rule and execute an authorization policy to access a protected resource. You want to apply policies on an incoming user. For example, your enterprise user 'Bob' has logged into https:// forums.novell.com/ with a social identity. You may want to identify that 'Bob' is your local user and provide him with forum moderator privileges. The Identify User Locally option lets you map a social user to your local user and apply appropriate policies.
Simplify user login : You may want to keep the user in your user stores but still make the registration process easy for the users. Social authentication saves the user from remembering another identity. User can login with their social identity while the Auto Provision User option will map the incoming user specified attribute with an existing user in the local user store. If the attribute matches, user will be provisioned, else user will be prompted for local user authentication.
Personalized web content in B2C scenarios : Organizations want to make services and information available in a manner that is personalized to individual. The common approach of creating individual identities for users is costly for the organization and inconvenient for the user.
Social login allow users to login with their preferred form of identities. This simplifies the login experience for customers while increasing the registration levels and lowering IT costs.
Step up authentication : While you as an administrator want to improve the user registration through social identities, you would also want to ensure that a second factor authentication is employed when users access sensitive information. Access Manager provides options to configure multiple contracts for protected resources and as users access these resources, they can be prompted to login with a second factor such as their corporate identity or an OTP.
4.1.2
Prerequisite
You must have registered Access Manager with the social authentication providers and should have the API keys and API secrets for establishing federation between Access Manager and the provider for example, Facebook.
4.1.3
Configuring SocialAuthClass
Use the Administration Console to define a new Social Authenticator class, method and contract for the Identity Server cluster. Social authenticator providers such as Facebook, Google+, LinkedIn and
Twitter are supported.
1
Login to the Administration Console.
2
Click Devices > Identity Servers > Edit > Local > Classes. Select New to add a new class.
3
Specify a name to identify the class. For example, Social authenticator.
4
Select SocialAuthClass from the Java Class drop-down list. Click Next.
146
NetIQ Access Manager 4.0 SP1 Identity Server Guide
5
Configure the User Identification settings if you need to perform actions on the logged in user.
This is optional. By default, user authentication is done without mapping the social provider user to a local user.
Identify User Locally : Select this option to map the incoming user to an existing user in your user store. You can apply an authorization policy for these incoming users to provide access control. The following two parameters specify how to perform the user mapping:
Local User LDAP Attribute
: Select an attribute from the drop-down list, for example
LDAP Attribute:mail [LDAP Attribute Profile]
. The incoming configured attribute from the social website is mapped to local user’s LDAP attribute.
NOTE:
If there are more than one social authentication providers configured, the Local
User LDAP
attribute must be a multi-valued attribute. This is required to store the social attributes corresponding to each social provider.
Social User Attribute : Select an attribute which provides a unique user identity for example Email. The user email provided in a social website will be mapped to the specified local user’s LDAP attribute.
User mapping is done if the value of Local User Attribute is equal to the value of
Social User Attribute
.
NOTE:
Provisioning will not occur in the following scenarios:
If you are going to use Facebook or Google+ as your authentication provider, do not select DisplayName as Social User Attribute as these providers do not have the DisplayName attribute.
If Social User Attribute is email attribute in Twitter.
Auto Provision User : If you enable this option, incoming user specified attribute will be mapped with an existing user in the local user store. If the attribute matches, user will be provisioned, else user will be prompted for local user authentication. After authentication, user attribute will be mapped and stored.
6
Click Add under Social Auth Providers to provide the authentication provider details.
Auth Provider : Select the authentication provider from the drop-down list for example,
Facebook. You can select from one of the predefined providers or select Other to specify your own providers. Note that only the predefined providers have been verified for compatibility with Access Manger. If you select Other, you must provide two additional information:
Provider Name
: Specify the name of the provider. Other provider names can be specified under Others option. Other provider name can be Yahoo, Hotmail,
SalesForce, AOL, FourSquare, MySpace, Instagram, Mendeley or Yammer. Name of social authentication provider is case-sensitive and must match as listed. Else, social authentication class will not work.
(Optional) Implementation Class: Specify a back end class that can authenticate with these providers if the other providers are not supported. This is needed only for a custom provider that is not in the list provided above.
Consumer Key : Specify the API key that you received when you registered Access
Manager with the Social authentication provider.
Consumer Secret : Specify the secret that you received when you registered Access
Manager with the Social authentication provider.
7
Click OK and Finish.
Configuring Advanced Local Authentication Procedures
147
8
Continue with creating a contract and method for this class.
For configuration information, see Section 3.3, “Configuring Authentication Methods,” on page 125
and Section 3.4, “Configuring Authentication Contracts,” on page 128 .
How Social Authentication Works With Access Manager
For completing social authentication, the Identity Server maps the social attribute value in token to the local user attribute value. The local attribute must be set in the following format for the matching to succeed.
<socialprovidername>:<social attribute value>
For example, consider that the social authentication class properties are set as follows:
Identify User Locally
: Enabled
Local User LDAP attribute : Ldap Attribute:mail
Social User Attribute : Email
Auto Provision User : Enabled
Social Auth Provider
As the Auto Provision User setting is enabled, after authentication in Facebook, user is asked for a one-time local login. During this process, this user's mail attribute is updated with the social attribute value as facebook:<social-email-address>. Subsequent logins from the same user will be seamless and user will be identified automatically.
If Auto Provision User setting is disabled, for the authentication to succeed, Access Manager will check if local user LDAP attribute mail value is facebook:<social-email-address>.
NOTE:
The attribute value is set with the provider's name.
4.1.4
Adding Images for Social Authentication Providers
You can add images for social authentication providers such as Facebook, LinkedIn, Twitter, Google+ and so on. For more information about adding images, see
Section 6.5, “Adding Authentication Card
1
In the Administration Console, click Devices > Identity Servers > Shared Settings >
Authentication Card Images
.
2
Click New.
3
Fill in the following fields.
Name:
Specify a name for the image.
Description:
Describe the image and its purpose.
File:
Click Browse, locate the image file, then click Open.
Locale:
From the drop-down menu, select the language for the card or select All Locales if the card can be used with all languages.
4
Click OK.
5
If you did not specify All Locales for the Locale, continue with
Section 6.6, “Creating an Image
148
NetIQ Access Manager 4.0 SP1 Identity Server Guide
6
Add all the required images and click Close.
After configuring the Identity Server with the required social authentication provider images, the login page will display those images as in
Figure 4-1 . The User Login screen will ask you to
choose and access the social providers you have added when you access the Identity Server
URL.
Figure 4-1
User Login Screen with Social Authentication Provider Images
4.1.5
Changing the Social Authentication Icons
The following procedure allows you to change the default icons of social authentication providers.
1
Go to socialauth_icons.jsp file located at /opt/novell/nids/lib/webapp/jsp/. You can see all the supported providers and their corresponding public URL locations.
2
To change the icon of a particular provider, go to the icon variable name of that provider and replace the existing URL location with required URL location.
You can similarly change for other icons defined in the jsp file.
3
Restart the Identity Server after changing the jsp file.
4.1.6
Configuring the Supported Social Authentication Providers for API Keys and API Secrets
Access Manager requires API Keys and API Secrets from the supported social authentication providers to integrate with these providers. For more information about configuring the supported applications, see
Appendix D, “Configuring the Supported Social Authentication Providers for API
Keys and API Secrets,” on page 493
.
Configuring Advanced Local Authentication Procedures
149
4.2
Configuring for Two-Factor Authentication Using
Time-Based One-Time Password (TOTP)
This section explains how to use Google Authenticator Time-Based One-Time Password (TOTP) as a second authentication factor with Access Manager. The Google Authenticator uses a six-digit number
(OTP) in addition to first authentication (for example: username, password), to log into protected services.
The first step is to register the Google Authenticator client with the secret key. This secret key is used for all future logins to the Web Site.
Typically, users download and install the Google Authenticator app on their devices. To log into a Web
Site or service that uses two-factor authentication, in addition to the user name and password, the users enter a additional OTP generated by the Google Authenticator app. Access Manager validates the OTP and authenticates the user.
For more information about implementation, see Google Authenticator on Wikipedia
Section 4.2.1, “Why Two-Factor Authentication?,” on page 150
Section 4.2.2, “Prerequisite,” on page 150
Section 4.2.3, “Configuring TOTP Class, Method, and Contract,” on page 150
Section 4.2.4, “Registering with Google Authenticator,” on page 152
Section 4.2.5, “Verifying TOTP Configuration,” on page 152
4.2.1
Why Two-Factor Authentication?
Two-factor authentication such as TOTP provides additional security for the systems. It works on the principle of granting access based on a knowledge factor (something the user has) and a possession factor (something the user knows). This helps organizations that need to implement a multi-factor authentication scheme to satisfy regulatory requirements or increase security.
4.2.2
Prerequisite
Download and install the Google Authenticator app on your device. This app generates an OTP that is later used for authentication.
Google Authenticator relies on the device time (of the Google Authenticator app) to generate an
OTP. So, it is important that the time on your device is accurate.
4.2.3
Configuring TOTP Class, Method, and Contract
Use the Administration Console to define a new TOTP Authenticator class, method, and contract for the Identity Server cluster.
1
Log in to the Administration Console.
2
Click Devices > Identity Servers > Edit > Local > Classes > News to add a new class.
3
Specify a name to identify the class. For example, Google authenticator.
4
Select TOTPClass from the Java Class option. The Java class path is displayed as com.novell.nidp.authentication.local.TOTPAuthenticationClass
. Click Apply to save the changes. By default, the TOTP class stores the secret key in the Shared Secret store and no further configuration is required.
150
NetIQ Access Manager 4.0 SP1 Identity Server Guide
5
[Optional] You can also optionally store the secret key in an LDAP attribute, file or memory. To do that follow the steps outlined in this table:
NOTE:
File and Memory class implementation are not recommended for production deployment and are only suitable for a single node Identity Server test environment.
LDAP user attribute:
This option stores the secret key on an LDAP attribute of the user object in the user store.
1. Select the Properties tab of the Google Authenticator class configuration. Add a new property to indicate that the secret key should be stored in an LDAP attribute of the user object in the user store.
Specify the Property Name as SECRET_STORE_CLASS and Property Value as USERSTORE.
2. Add another property to indicate the attribute in which the secret key should be stored.
Specify the Property Name as SECRET_LDAP_ATTRIBUTE_NAME and specify the name of any single-valued attribute. For example, you can specify the Property Value as mobile, costcentre
etc.
The secret key is encrypted and stored in the LDAP attribute. If you do not specify any
Property Value
, the secret key is stored in the carLicense LDAP attribute.
NOTE:
Do not use a multi-valued LDAP attribute like email address as the Property
Value
as the user registration will fail. It is also important to ensure that the LDAP attribute you have specified as the Property Value is a non-operational attribute. For example, it is not recommended to use LDAP Attributes like groupmembership.
File class:
The File class writes the secret key to a file on the Identity Server file system.
Select the Properties tab of the Google Authenticator class configuration and add a new property to have the user's secret key stored in a file on the file system.
Specify the Property Name as SECRET_STORE_CLASS and Property Value as FILE.
Memory class:
The Memory based class writes the secret key into memory. This memory is transient in nature and therefore the secret key value is lost each time the Identity Server is restarted.
Select the Properties tab of the Google Authenticator class configuration and add a new property to define the memory-based property where each user’s secret key is stored.
Specify the Property Name as SECRET_STORE_CLASS and Property Value as MEMORY.
6
Click Devices > Identity Servers > Edit > Local > Methods. Select New to add a new method.
7
Specify a name to identify the method. Select the Google authenticator class from drop-down list. This links the Google authenticator class to the authentication method.
8
Deselect the Identifies User option. Click Apply to save the changes.
9
Select the user store from the list of Available user stores and move it to User store.
10
You can either use an existing authentication contract or create a new authentication contract.
For example, you can add the default Name/Password – Form method as the first method and
Google Authenticator method as the second method. Click Apply to save the changes.
NOTE:
If you use TOTP as a post-authentication method in a federation setup, a JSP file not found
message is displayed and federation fails.
Configuring Advanced Local Authentication Procedures
151
4.2.4
Registering with Google Authenticator
1
Go to NetIQ Identity Server page http(s)://<idp server >:<port>/nidp
2
Select the contract where Google Authenticator is configured as the second method for twofactor authentication.
3
Login with the first method.
4
Click the link beside Please register for two factor authentication to generate a OTP. Make a note of the secret key displayed.
If you have installed the Google Authenticator client on your device, scan the code. You can also manually enter the secret key in the Google Authenticator mobile client.
After the registration is complete on the Google Authenticator client on your mobile, the OTP is displayed.
4.2.5
Verifying TOTP Configuration
1
Go to NetIQ Identity Server page: http(s)://<idp server >:<port>/nidp
2
Select the contract where Google Authenticator is configured as the second method for twofactor authentication.
3
Login with the first method.
After successfully authenticating with the username and password, prompt is displayed to enter the Google Authenticator OTP.
4
Use the Google Authenticator app to generate the OTP and login using this OTP.
152
NetIQ Access Manager 4.0 SP1 Identity Server Guide
4.3
Configuring Persistent Authentication
This authentication class stores user session on the browser after successful login. When the user is prompted for authentication subsequently, this class will reuse the saved authentication instead of prompting the user for credentials. The user will be prompted for credentials again only when the cookie lifetime expires. This authentication class is used only for applications that do not require very high security.
4.3.1
Frequent Re-authentication Using Password
This class helps in configuring websites that have low security such as enterprise forums. Frequently typing the password to re-authenticate may be vulnerable and cause security issues. To avoid this with PersistentAuthClass configuration you will not be required to re-authenticate using the password frequently. For sites that you use a low-grade identity for example, enterprise forums or some web sites that restrain your preferences, having to re-authenticate every few-hours is annoying.
Some web sites offer the remember my password feature that will not ask the user to re-authenticate if you select this option. This class provides that remember my password functionality so that the user does not have to frequently re-authenticate.
4.3.2
PersistentAuthClass Properties
You can set the following class properties in the configuration file.
CryptoKey : This key is used to encrypt the user's information in the cookie. If this value is long and random, the user information will be secure. The value must be at least ten characters. The certificate private key will be used if you do not set this value. If you change or update the certificate, the user is re-authenticated.
CookieSuffix
: The Cookie Name is derived using this suffix. PA_ is added as a prefix to the cookie name. By default, cookie name is PA_PERSISTENT_AUTH. For example, if you configure the CookieSuffix as PER_AUTH, the Identity server sends cookie with PA_PER_AUTH name at browser.
MaxAgeSeconds : This property will decide the cookie lifetime. Default value is 86400 seconds
(1 day). Maximum value is 4294967295 seconds.
ParamName : The name of the HTTP parameter to enable this feature. The default value of the parameter is EnableCookieAuth. If you want to modify the default value of parameter name for example to TestCookieName, follow the procedure given below.
1. Login to the Identity Server.
2. Go to /opt/novell/nids/lib/webapp/jsp
3. Open login.jsp file using an editor.
4. Search for EnableCookieAuth parameter name and provide the new name as
TestCookieName in the input tag.
5. Ensure that you select the Remember Me option.
6. Restart the Identity Server.
This value is used by the Identity Server to identify if user has enabled Remember Me option on the login page.
Configuring Advanced Local Authentication Procedures
153
4.3.3
Configuring Persistent Authenticator Class
The following procedure allows you to configure the PersistentAuthClass.
1
Login to the Administration Console.
2
Click Devices > Identity Servers > Edit > Local > Classes.
3
Click New, then specify a Display name for example, PersistentAuth.
4
Select PersistentAuthClass from the Java Class drop-down list.
5
Click New to create a new authentication class.
6
In the Add property window, specify the following values. Specifying these values are optional.
Property Name: Specify the name of the property. For more information on the names you can specify here, see
Section 4.3.2, “PersistentAuthClass Properties,” on page 153
Property Value:
Specify the property value you would like to define here.
7
Click OK and Finish.
8
Continue with creating a contract and method for this class.
For configuration information, see Section 3.3, “Configuring Authentication Methods,” on page 125
and Section 3.4, “Configuring Authentication Contracts,” on page 128 .
4.3.4
Logging Out of the Persistent Sessions
When a user performs an explicit logout, the Identity Server clears the persistent authentication cookie at browser if the logout request goes through the browser. If SOAP communication is used between the service provider and the Identity server, then the Identity server does not clear the cookie automatically. The cookie can only be cleared by sending a request to a page on the server that issued it. If the page is available on the Identity server, the clearCookieAuth.jsp file clears the page. You must customize the service provider’s logout page to run the Identity server’s clearCookieAuth.jsp
page.
The clearCookieAuth.jsp file clears it. The URL for this page will be https://idpserver.example.com/ nidp/clearCookieAuth.jsp
. Any request to that URL will clear the authentication cookie.
With this class in use, the user will be unable to logout of the system because re-accessing any protected page will simply re-authenticate the user using the user information stored in the browser stored. There are at least two ways to invalidate an outstanding browser stored authentication cookie.
The first is to change the user’s password and second is to clear the stored cookie from the browser.
Only way to invalidate the cookie is to change the encryption key used. The cookie that is created can only be cleared by a request from the server which created it.
The following configurations are specific to the Novell service provider. If the users uses third party service provider, then the user must customize the logout pages.
In a federation scenario add the following to the logoutSuccess.jsp file at /opt/novell/nam/idp/ webapps/nidp/jsp/
of the service provider. You can have logout page redirect to this page, or have an <iframe> that references the page. You may also customize the /opt/novell/nam/mag/webapps/ nesp/jsplogoutSuccess.jsp
file to provide login links or instructions to your user.
<tr>
<td> <iframe src="https://idp.labs.com:8443/nidp/jsp/clearCookieAuth.jsp" width="0" height="0"> </td>
</tr> where idp.labs.com is the URL of the Identity Server.
154
NetIQ Access Manager 4.0 SP1 Identity Server Guide
4.3.5
Limitations
Following are the limitations with the Persistent Authentication Class:
User is authenticated even if the password is changed.
If the user is already logged in with Remember Me option enabled, you will be unable to stop the session until the cookie expires.
4.4
Configuring for RADIUS Authentication
RADIUS enables communication between remote access servers and a central server. Secure token authentication through RADIUS is possible because Access Manager works with Novell Modular
Authentication Service (NMAS) RADIUS software that can run on an existing NetWare server. Access
Manager supports both PIN and challenge-and-response methods of token-based authentication. In other words, RADIUS represents token-based authentication methods used to authenticate a user, based on something the user possesses (for example, a token card). Token challenge-response is supported for two-step processes that are necessary to authenticate a user.
1
In the Administration Console, click Devices > Identity Server > Edit > Local > Classes.
2
Click New.
3
Specify a display name, then select RadiusClass or ProtectedRadiusClass from the dropdown menu.
4
Click Next.
Configuring Advanced Local Authentication Procedures
155
5
Click New to add an IP address for the RADIUS server. You can add additional servers for failover purposes.
6
Click OK.
7
Fill in the following fields:
Port:
The port of the RADIUS server.
Shared Secret:
The RADIUS shared secret.
Reply Time:
The total time to wait for a reply in milliseconds
Resend Time:
The time to wait in milliseconds between requests.
Server Failure Retry:
The time in milliseconds that must elapse before a failed server is retried.
JSP:
Specify the name of the login page if you want to use something other than the default page. The filename must be specified without the JSP extension. The default page is used if nothing is specified.
User Look Attribute Name:
Specify the LDAP attribute on which the user will be searched in the Radius server. CN is the default attribute.
Require Password:
Select to require the user to also specify an LDAP password.
8
Click Finish.
9
Create a method for this class.
For instructions, see
Section 3.3, “Configuring Authentication Methods,” on page 125 .
10
Create a contract for the method:
For instructions, see
Section 3.4, “Configuring Authentication Contracts,” on page 128
.
If you want the user’s credentials for Identity Injection policies and you did not enable the
Require Password
option, add the password fetch method as a second method to the contract.
For more information about this class and method, see Section 4.9, “Configuring Password
.
11
Update the Identity Server.
4.5
Configuring Client Integrity Check
You can configure a client integrity check policy to verify the recommended software (such as firewall and antivirus software) is installed on the client machine. You can configure different policies for
Windows, Linux, and Macintosh machines and specify software that must be available in client machines to pass the client integrity check.
You need to create an identity provider authentication class that checks for the specified software on the client machine. You can configure policies to check processes, files, Windows registry, system services, and so on. This class can be executed with the first method of the contract. If the check fails, the user authentication fails.
Perform the following steps to configure the client integrity check:
1
Copy the following file from /opt/novell/nam/sslvpn/webapps/sslvpn to /opt/novell/nam/ idp/webapps/nidp/classUtils
:.
For Linux:
LinCic from the linux folder.
For Macintosh:
MacCic from the MacOS and Maci386 folders.
For Windows:
wincic.msi from the windows folder.
2
Extract the binary file on the Identity Server machine and make it executable by using the chmod
+x
.
156
NetIQ Access Manager 4.0 SP1 Identity Server Guide
For example, run chmod +x wincic.exe for Windows.
3
Create CIC policies and assign it to a security level.
For more information about how to configure a CIC policy, see “ Configuring Policies to Check the
Integrity of the Client Machine ” in the
NetIQ Access Manager 4.0 SSL VPN Server Guide
.
4
Copy the cic_linux.txt, cic_windows.txt, and cic_mac.txt files from /etc/opt/novell/ sslvpn
to the respective windows, linux and mac folders at /opt/novell/nam/idp/webapps/ nidp/classUtils
.
5
In the Administration Console, click Identity Server > Edit > Local > Classes > New.
6
Specify a name for the class and select ClientIntegrityCheckClass in Java class.
7
Click Next.
8
Click New and specify property name and property value.
9
Click OK > Finish.
10
Create a method for this class and deselect Identifies User check box and set all other fields to default settings and click OK. For instructions, see
Section 3.3, “Configuring Authentication
.
11
Go to the Contracts tab and select CIC method from the Available Methods list and click OK.
For instructions, see
Section 3.4, “Configuring Authentication Contracts,” on page 128
.
4.6
Configuring Mutual SSL (X.509) Authentication
Mutual authentication is used when a user is issued an X.509 certificate from a trusted source, and the certificate is then used to identify the user. To ensure the validity of the certificates, Access
Manager supports both Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol
(OCSP) methods of verification.
To configure X.509 authentication, you need to create an authentication class, then configure the validation and attribute mapping options.
1
Log in to the Administration Console.
2
Import the trusted root certificate or certificate chain of the Certificate authority into the Identity
Server trusted root store.
For information about how to import trusted roots, see “ Importing Public Key Certificates
(Trusted Roots) ” in the
NetIQ Access Manager 4.0 SP1 Administration Console Guide
.
The Identity Server must trust the Certificate authority that created the user certificates.
3
To create the X.509 authentication class, click Devices > Identity Servers > Edit > Local >
Classes
.
4
Click New.
5
Specify a display name, then select X509Class from the drop-down menu.
6
Click Next.
Configuring Advanced Local Authentication Procedures
157
7
Configure the validation options:
Validations:
The validation type. Trust validation occurs if the certificate chain is verified in the
NIDP Trust Store
. In addition to usual certificate validations, the Identity Server supports CRL
(certificate revocation list) and OCSP (Online Certificate Status Protocol) validations for each authentication request.
Access Manager caches CRLs, so the revoked status of a newly revoked certificate is not picked up until the next cache refresh. For higher security requirements, use OCSP validation with CRL validation. You can select None, CRL, OCSP, OCSP-CRL, or CRL-OCSP validation. In a production environment, for highest security, select either OCSP-CRL or CRL-OCSP validation.
The default setting is to check OCSP first, then CRL.
CRL Validation:
Checks the CRL. If you enable CRL validations, the CRL distribution point extension is read out of the user’s X.509 certificate. The CRL distribution point contains the URL where the complete CRL can be found, as published by the certificate authority. The system checks the CRL itself and then checks to see if the user certificate is in the revoked list. The system can get the CRL over HTTP and LDAP. If you are not expecting the distribution point in user certificates, you can specify a value in the LDAP URL option to get the CRL.
Access Manager supports two schemes for a URL: http:// and ldap://.
OCSP Validation:
If OCSP validation is enabled, the Authority Info Access point (AIA) is read out of the user certificate, which contains the URL for the OCSP responder. A signed OCSP request for the user certificate is sent to OCSP responder. A signed OCSP response is received from the responder that has the revoked status for the user certificate. Alternately, if you are not expecting an AIA in a user certificate, you can specify a value in the OCSP responder URL field.
The value you enter here overrides any OCSP responder URLs in a certificate.
Access Manager supports two schemes for a URL: http:// and ldap://.
158
NetIQ Access Manager 4.0 SP1 Identity Server Guide
Disable Root CA Revocation Check:
Disables whether to check if a certificate authority has been revoked. This option checks the CRL and OCSP for the trusted root certificate in the chain.
You can enable or disable this option for X.509 user authentication performance.
If you enable the root CA revocation check, what the Identity Server checks depends upon the certificates that have been added to the Identity Server trust store. If the root certificate and the intermediate certificates in the chain are in the trust store, the Identity Server only validates the client (leaf) certificate. If the trust store only contains the root certificate, the browser sends the intermediate and leaf certificates, which are then validated by the Identity Server.
8
Configure the trust stores:
NIDP Trust Store:
This trust store must contain the trusted root certificate of the certificate authorities that signed your user certificates. Click this link to add certificates to the trust store.
OCSP Trust Store:
This trust store must contain the signing certificate of the OCSP servers you want to trust. Click this link to add certificates to the trust store. You must add the signing certificate, not the trusted root certificate, for this feature to work.
9
Configure the browser restart option.
Some browsers, such as Internet Explorer, keep the SSL session active until the user closes the browser. When the user logs in with the certificate on a smart card, then removes the card and logs out but does not close the browser, the SSL session is still active. If another user has access to the machine, that user can use the existing session.
To prevent this from happening, select Force browser restart on logout.
10
Click Next.
11
Continue with Section 4.6.1, “Configuring Attribute Mappings,” on page 159 .
4.6.1
Configuring Attribute Mappings
The attribute mapping options allow you to specify how the Identity Server maps the certificate to a user in the user store. Subject name is the default map.
1
Step 3 of the wizard or click Devices > Identity Servers > Edit > Local > Classes > [Name of
X.509 class]
> Properties > Attributes.
2
Configure attribute mappings.
Configuring Advanced Local Authentication Procedures
159
Show certificate errors:
Displays an error page when a certificate error occurs. This option is disabled by default.
Auto Provision X509:
Enables using X.509 authentication for automatic provisioning of users.
This option allows you to activate X.509 for increased security, while using a less secure way of authentication, such as username/password. Extra security measures can even include manual intervention to activate X.509 authentication by adding an extra attribute that is checked during authentication.
An example of using this option is when a user authenticates with an X.509 certificate, a lookup is performed for a matching SASallowableSubjectNames with the name of the user certificate.
When no match is found, and Auto Provision X509 is enabled, the user is presented with a custom error page specifying to click a button to provide additional credentials, such as a username and password, or to start an optional Identity Manager workflow. If the authentication is successful, then the user’s SASallowableSubjectNames attribute is filled in with the certificate name of the user certificate.
When Auto Provision X509 is enabled, and the attribute that is used for subject name mapping is changed from the default sasAllowableSubjectNames, you need to ensure that the LDAP attribute that is used can store string values with a length as long as the longest client certificate subject name. For example, if you use the LDAP attribute title (which has an upper bound of 64 characters) the Auto Provision X509 fails the provisioning part of the authentication if the client certificate subject name is longer 64 characters. The authentication works if a valid name and password is given. However, provisioning fails.
Attributes:
The list of attributes currently used for matching. If multiple attributes are specified, the evaluation of these attributes should resolve to only one user in the user store.
The evaluation first does a DN lookup for subject name or directory name mapping. If this fails, the rest of the mappings are looked up in a single LDAP query.
Available attributes:
The available X.509 attributes. To use an attribute, select it and move it to the Attributes list. When the attribute is moved to the Attributes list, you can modify the mapping name in the Attribute Mappings section. The mapped name must match an attribute in your LDAP user store.
160
NetIQ Access Manager 4.0 SP1 Identity Server Guide
Directory name:
Searches for the directory address in the client certificate and tries to match it to the DN of a user in the user store. If that fails, it searches the sasAllowableSubjectNames attribute of all users for a value that matches. The sasAllowableSubjectNames attribute must contain values that are comma-delimited, with a space after the comma. (For example,
O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.)
Email:
Searches for the email attribute in the client certificate and tries to match it with a value in the LDAP mail attribute.
Serial number and issuer name:
Lets you match a user’s certificate by using the serial number and issuer name. The issuer name and the serial number must be put into the same LDAP attribute of the user, and the name of this attribute must be listed in the Attribute Mappings section.
When using a Case Ignore String attribute, both the issuer name and the serial number must be in the same attribute separated by a dollar sign ($) character. The issuer name must precede the
$ character, with the serial number following the $ character. Do not use any spaces preceding or following the $ character. For example: O=CURLY, OU=Organization CA$21C0562C5C4
The issuer name can be from root to leaf or from leaf to root. The issuer name must be commadelimited with a space after the comma. (For example, O=CURLY, OU=Organization CA or
OU=Organization CA, O=CURLY.)
The serial number cannot begin with a zero (0) or with a hexadecimal notation (0x). If the serial number is 0x0BAC05, the value of the serial number in the attribute must be BAC05. The certificate number is displayed in Internet Explorer with a space after every fourth digit. However, you should enter the certificate number without using spaces.
The LDAP attribute can be any Case Ignore List or Case Ignore String attribute of the user. If you are configuring your own attribute, ensure that the attribute is added to the Person class. When using a Case Ignore List attribute, both the issuer name and the serial number must be in the same list. The issuer name needs to be the first item in the list, with the serial number being the second and last item in the list.
Subject name:
Searches for the Subject name of the client certificate and tries to match it to the
DN of a user in the user store. If that fails, it searches the sasAllowableSubjectNames attribute of all users for a value that matches the Subject name of the client certificate. The sasAllowableSubjectNames attribute must contain values that are comma-delimited, with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization
CA, O=CURLY.)
3
Click Finish.
4
Create a method for this class.
For instructions, see
Section 3.3, “Configuring Authentication Methods,” on page 125 .
5
Create a contract for the method:
For instructions, see
Section 3.4, “Configuring Authentication Contracts,” on page 128
.
If you want the user’s credentials available for Identity Injection policies, add the password fetch method as a second method to the contract. For more information about this class and method, see
Section 4.9, “Configuring Password Retrieval,” on page 166 .
6
Update the Identity Server.
4.6.2
Setting Up Mutual SSL Authentication
SSL provides the following security services from the client to the server:
Authentication and nonrepudiation of the server, using digital signatures
Configuring Advanced Local Authentication Procedures
161
Data confidentiality through the use of encryption
Data integrity through the use of authentication codes
Mutual SSL provides the same things from the server to the client as SSL. It provides authentication and nonrepudiation of the client, using digital signatures.
1
Set up Access Manager certificates for security, and import them into the Access Manager system. (See “ Creating Certificates ” in the
NetIQ Access Manager 4.0 SP1 Administration
Console Guide
.)
2
Create an X.509 authentication class. (See
Section 4.6, “Configuring Mutual SSL (X.509)
Authentication,” on page 157 .)
3
Create an authentication method using this class. (See Section 3.3, “Configuring Authentication
.)
4
Create an authentication contract using the X.509 method. (See
Authentication Contracts,” on page 128
.)
5
Update the Identity Server cluster configuration. (See
Section 16.1.1, “Updating an Identity
Server Configuration,” on page 412
.)
6
Update any associated Access Gateways to read the new authentication contract.
7
Assign the contract to protect resources.
See “ Configuring Protected Resources ” in the
NetIQ Access Manager 4.0 SP1 Access Gateway
Guide
.
8
Update the Access Gateway.
Customizing Certificate Errors
In case of certificate validation failure, the browser displays a standard Page expired error. If you want the Identity Server to display an Access Manager error instead of the usual error messages provided by the browser, edit the /opt/novell/nam/idp/conf/server.xml by using the following procedure:
1
Search for the clientauth attribute in the server.xml file.
2
Modify the value of the clientauth attribute from the default value of false to want.
3
Save the file and restart Identity Server by using the rcnovell-idp restart command.
This setting ensures that the certificate is exchanged between the client and the server. This will result in a prompt being displayed on the browser during authentication.
4
Export the user and server certificate from the Administration Console by using the Security >
Certificates
option.
To avoid the untrusted certificate messages in browsers, import the trusted root certificate of the
CA into your browsers. For details, see “ Resolving Certificate Import Issues ” in the
NetIQ Access
Manager 4.0 SP1 Administration Console Guide
4.6.3
Configuring X.509 Authentication to Provide Access
Manager Error Message
You can configure the X.509 class property and the Identity Server to avoid the browser provided message and display Access Manager error message. This occurs when the SSL mutual handshake fails because of non availability of client certificate.
162
NetIQ Access Manager 4.0 SP1 Identity Server Guide
NOTE:
You can specify the Port and URL name as per your environment. The URL name and port number specified in the following procedure is an example.
Prerequisite:
To configure you should have a parent domain, for example, https://
240onbox.provo.novell.com:8443/nidp/ and sub domain https://onbox.provo.novell.com:8448/ available. You can also have a different port or IP combination.
Follow the procedure given below to configure X.509 based authentication for Access Manager specific error.
1
Go to identity provider and navigate to /opt/novell/nam/idp/conf directory.
2
Open server.xml file using the vi editor.
3
Search for <Connector NIDP_Name="connector" and create a copy of existing connector.
4
Go to the new connector you created and search for clientAuth=false string and change it to clientAuth=want. Change the port to a new port for example, 8448.
5
Save the server.xml file and exit.
6
Navigate to /opt/novell/nids/lib/webapp/META-INF/ directory and open context.xml file.
7
Change Tomcat context.xml to set a same cookie for sub domains. Ensure that the path is set to "/" as follows.
<?xml version="1.0" encoding="UTF-8"?>
<Context sessionCookiePath="/"
sessionCookieDomain=".provo.novell.com"> <!-- Disable session persistence across Tomcat restarts -->
<Manager pathname="" saveOnRestart="false"/>
</Context>
8
Change session proxying for setting this cookie.
8a
Navigate to/opt/novell/nam/idp/webapps/nidp/WEB-INF/classes directory
8b
Open nidpconfig.properties using vi editor and add the following lines.
CLUSTER_COOKIE_DOMAIN = .provo.novell.com
CLUSTER_COOKIE_PATH = /
NOTE:
Before you go to the next step, ensure that you have configured X.509 class,
method, and contract. For more information about configuring, see Section 4.6,
“Configuring Mutual SSL (X.509) Authentication,” on page 157
.
9
For X509Class based redirection, in the X.509 method add the property for X.509 to be redirected to the new connector as follows.
Property Name: CONNECTOR_HOST
Property Value: https://onbox.provo.novell.com:8448/
10
Restart Tomcat using the following commads.
Linux: /etc/init.d/novell-idp restart
Windows: Enter the following commands:
net stop Tomcat7
net start Tomcat7
Verify the configuration as follows.
Configuring Advanced Local Authentication Procedures
163
Access NIDP URL in browser that does not have client certificate. Access the X.509 authentication card and verify the behavior. It must redirect to connector port 8448 and redirect back to original page with an Access Manager error message or error code.
4.7
Creating an ORed Credential Class
Access Manager includes a class that can be configured to accept any combination of name/ password, X.509, or RADIUS credentials. When this class executes as part of a contract, users can select and enter their preferred type of credential.
For example, if a name/password credential is ORed with an X.509 credential, the user can select to use a certificate or to enter a name and password. As an administrator, you have decided that both credentials are equally secure for the protected resource the contract is protecting.
To create an ORed credential class:
1
In the Administration Console, click Devices > Identity Servers > Edit > Local > Classes.
2
Click New, then fill in the following fields:
Display name:
Specify a name for the class.
Java class:
Select NPOrRadiusOrX509Class.
3
Click Next, then select the types of classes you want to OR. You must select at least one of the following:
Use Name/Password:
Select this option if you want the PasswordClass to be one of the authentication options available to the user.
Use Radius:
Select this option if you want the RadiusClass to be one of the authentication options available to the user.
Use X509:
Select this option if you want the X509Class to be one of the authentication options available to the user.
4
(Conditional) If you want to use the protected version of the PasswordClass or RadiusClass, select the Enforce use of HTTPS option.
5
(Conditional) If you selected the Use Name/Password option, configure the properties:
5a
In the Name/Password Properties section, click New.
5b
Specify a property name and property value.
For information about the properties that the PasswordClass and the
ProtectedPasswordClass support, see Section 3.2.2, “Specifying Common Class
5c
Click OK.
5d
Repeat
through
Step 5c to add more than one property.
6
Click Next.
7
(Conditional) If you selected the Use Radius option, configure the Radius properties.
For information about the configuration options, see Section 4.4, “Configuring for RADIUS
Authentication,” on page 155 .
8
(Conditional) If you selected the Use X509 option, configure how the certificate is validated.
For information about the configuration options, see Section 4.6, “Configuring Mutual SSL
(X.509) Authentication,” on page 157
.
9
Click Next.
10
(Conditional) If you selected the Use X509 option, configure the attribute mappings.
164
NetIQ Access Manager 4.0 SP1 Identity Server Guide
For information about the configuration options, see Section 4.6, “Configuring Mutual SSL
(X.509) Authentication,” on page 157
.
11
Click Next.
12
Click Finish.
13
Continue with creating a method and a contract for this class.
For configuration information, see Section 3.3, “Configuring Authentication Methods,” on page 125
and Section 3.4, “Configuring Authentication Contracts,” on page 128 .
If the contract allows the user to select from the three types of credentials, the login page looks similar to the following:
The Radius class prompts the user for a token instead of a password. The user can use the drop-down menu to select between the password and the token. If the user selects to send a certificate, the username and password/token options become unavailable.
4.8
Configuring for OpenID Authentication
OpenID is an open, decentralized method for identifying users which allows users to use the same digital identity for logging in to multiple services. You can configure the Identity Server to trust the provider or providers of OpenIDs by configuring the OpenID class. You then configure a method and contract and assign a protected resources to use the contract for authentication. When the users supply the OpenID, they are granted access if the Identity Server has been configured to trust the provider of the OpenID server.
NOTE:
Access Manager supports OpenID1.1.
1
In the Administration Console, click Devices > Identity Servers > Edit > Local > Classes.
2
Click New, then fill in the following fields:
Display name:
Specify a name for the class.
Java class:
Select OpenIdClass.
The Java class path is configured automatically.
3
Click Next, then configure the following properties:
Configuring Advanced Local Authentication Procedures
165
Open ID Provider Substrings:
Specify at least one URL substring of an OpenID provider. The
OpenID URL that user enters during the login process must contain one of the strings as a subset of the OpenID URL. For example, if user enters https://user123.myopenid.com, this field needs to contain one of the following strings: myopenid.com
.myopenid.com
To specify multiple URLs, separate them with a semicolon (;)
Identity the OpenID user locally:
After the user authenticates at the OpenID provider, Access
Manager can associate a username from the user store with the OpenID user. With this association, Access Manager can use the policies defined for the username to enforce access to protected resources.
When this option is not selected, the OpenID user is not mapped to a local user. The username of the authenticated user remains as the OpenID URL. For example, if the user enters http://user123.myopenid.com for the URL, http://user123.myopenid.com becomes the username.
When this option is selected, an attempt is made to map the OpenID user with a username in the user store. You can do this manually by storing the user’s OpenID in the attribute specified in the LDAP Attribute Name option. You can also have the Identity Server add the OpenID value to the attribute by selecting the Auto Provision LDAP Attribute option.
LDAP Attribute Name:
Specify the name of the attribute that contains the identification information for the users. For OpenID authentication, this attribute should contain the OpenID for the user.
Auto Provision LDAP Attribute:
Select this option when you want the user to provide additional information for identification for the first authentication, such as a username and password. The Identity Server uses this information to identify the user, then writes the user’s
OpenID value to the attribute specified in the LDAP Attribute Name option. On subsequent logins, the Identity Server can identify the user by using the specified attribute and the user is not prompted for additional information.
4
Click Finish.
5
Create a method for this class.
For instructions, see
Section 3.3, “Configuring Authentication Methods,” on page 125 .
6
Create a contract for the method:
For instructions, see
Section 3.4, “Configuring Authentication Contracts,” on page 128
.
If you want the user’s credentials available for Identity Injection policies, add the password fetch method as a second method to the contract. For more information about this class and method, see
Section 4.9, “Configuring Password Retrieval,” on page 166 .
7
Update the Identity Server.
4.9
Configuring Password Retrieval
If you have configured contracts that do not use a username and password for the credentials and you want to configure single sign-on to protected resources that require a user’s name and password, you need to configure the PasswordFetchClass to retrieve the user’s name and password. You need to create the class, then create a method from the class. The method needs to be assigned as the second method for the authentication contract that does not prompt the user for a username and password. When the Identity Server executes the contract, the PasswordFetchClass retrieves the username and password and stores them with the LDAP credentials, which makes them available for
Identity Injection policies.
166
NetIQ Access Manager 4.0 SP1 Identity Server Guide
IMPORTANT:
The PasswordFetchClass only works with eDirectory user stores.
1
In the Administration Console, click Devices > Identity Servers > Edit > Local > Classes.
2
Click New, then fill in the following fields:
Display name:
Specify a name for the class.
Java class:
Select PasswordFetchClass.
The Java class path is configured automatically.
3
Click Next, then configure the following general properties:
Ignore password retrieval failure:
Select this option if you want users to continue with their sessions when the Identity Server can’t retrieve their passwords. If this option is not selected, users are denied access when their passwords can’t be retrieved.
Retain Previous Principal:
Select this option to retain the principal obtained from the previous authentication method. If you do not select this option, then the principal will be used from the method associated with this class.
Password to be retrieved:
If your users have been configured to use a universal password, select Universal Password. Otherwise, select Simple Password.
Configuring Advanced Local Authentication Procedures
167
NOTE
Set the Universal Password Retrieval options in the configuration of the Universal Password policy, so that the policy allows the password to be retrieved from the User Store.
User must reset the password after configuring the password policy for universal password.
For more information about Unable to retrieve Universal Password from eDirectory using
PasswordFetchClass issue, see TID 7007114 .
The password retrieval of the user store lookup settings are mapped based on the CN attribute value of the user object, attribute details that is based on the distinguished name to LDAP attribute. These options are added so that the password can be fetched from Active Directory. If you are not using Active Directory but eDirectory, then you use the default CN attribute of the eDirectory to map with the Active Directory user store.
4
Configure the following UserStore Lookup Settings:
Based on the CN of the user object:
The CN users are mapped between two different user stores. CN is mapped with for retrieving the password from user store. For Example - Active
Directory CN is mapped with eDirectory CN for retrieving the password from eDirectory user store.
Based on the Attribute value of the user object:
The user names are detected and handled in LDAP attribute or DN users of the Active Directory are mapped with LDAP attribute of the eDirectory. If you select this option, then specify the attribute value in attribute details of the
Attribute name of DN
and enable the Auto Provision check box if required.
Attribute Name of the DN:
Specify the attribute name of the DN.
This attribute must contain the CN of user whose password you want to obtain. For example, if you are trying to obtain a password from eDirectory for a user with cn=a,dc=b, then you need to specify name of the attribute, which value is cn=a,dc=b.The passwordfetchclass tries fetching the password from the current user store based on the value of the LDAP attribute specified, which are mapped to user's DN of the Active Directory.
Auto Provision:
If you enable this check box, then the passwordfetchclass tries fetching the password from LDAP attribute specified above which has the value of the DN users of the Active
Directory and retrieves the password, else it prompts to log in to the eDirectory. If the log in is successful, then the LDAP attribute value gets populated with the DN user of the Active
Directory. When the user is logged next time the same value is used.
5
Click OK.
6
Create a method for this class.
For instructions, see
Section 3.3, “Configuring Authentication Methods,” on page 125 .
7
Assign the password fetch method as the second method for a contract that is using one of the following for its authentication method:
RADIUS. See
“Configuring for RADIUS Authentication” on page 155
.
X.509. See “Configuring Mutual SSL (X.509) Authentication” on page 157
.
OpenID. See
“Configuring for OpenID Authentication” on page 165
.
Smart Card. See
“Configuring Access Manager for NESCM” on page 169 .
Kerberos. See
“Configuring for Kerberos Authentication” on page 177 .
Google Authenticator. See “Configuring for Two-Factor Authentication Using Time-Based
One-Time Password (TOTP)” on page 150
8
Click Apply and update the Identity Server.
168
NetIQ Access Manager 4.0 SP1 Identity Server Guide
4.10
Configuring Access Manager for NESCM
To use a smart card with Access Manager, you need to configure Access Manager to use the eDirectory server where you have installed the Novell Enhanced Smart Card Login Method for NMAS
(NESCM). You then need to create a contract that knows how to prompt the user for the smart card credentials. The last task is to assign this contract to the protected resources that you want protected with a smart card. The following sections describe the prerequisites and the tasks:
Section 4.10.1, “Prerequisites,” on page 169
Section 4.10.2, “Creating a User Store,” on page 169
Section 4.10.3, “Creating a Contract for the Smart Card,” on page 171
Section 4.10.4, “Assigning the NESCM Contract to a Protected Resource,” on page 175
Section 4.10.5, “Verifying the User’s Experience,” on page 175
Section 4.10.6, “Troubleshooting,” on page 176
4.10.1
Prerequisites
Ensure that you can authenticate to the eDirectory server by using the smart card from a workstation.
The NESCM method needs to be installed on the eDirectory server and the workstation.
See “Installing the Method” (http://www.novell.com/documentation/iasclient30x/ nescm_install/data/b7gx5la.html) in the
Novell Enhanced Smart Card Method Installation and Administration Guide
(http://www.novell.com/documentation/iasclient30x/ nescm_install/data/bookinfo.html) .
The NESCM method needs to be configured. See “Configuring the Server” (http:// www.novell.com/documentation/iasclient30x/nescm_install/data/b7tf2gi.html) in the
Novell
Enhanced Smart Card Method Installation and Administration Guide
(http:// www.novell.com/documentation/iasclient30x/nescm_install/data/bookinfo.html) .
Provision your smart card according to your company policy.
Ensure that you have a basic Access Gateway configuration with a protected resource that you want to protect with a smart card. For more information, see the
NetIQ Access Manager 4.0 SP1
Installation Guide
and the
NetIQ Access Manager 4.0 SP1 Setup Guide
.
4.10.2
Creating a User Store
The Identity Server must be configured to use the eDirectory replica where you have installed the
NESCM server method.
If you have already configured the Identity Server to use this replica, skip this section and
continue with Section 4.10.3, “Creating a Contract for the Smart Card,” on page 171
.
If your Identity Server is using a different user store, you need to configure the Identity Server.
To configure the Identity Server for the eDirectory replica that has the NESCM method:
1
In the Administration Console, click Devices > Identity Servers > Edit > Local> User Stores >
New
.
Configuring Advanced Local Authentication Procedures
169
2
On the Create User Store page, fill the following fields:
Name:
A display name for the eDirectory replica (for example, nescm_replica).
Admin Name:
The distinguished name of the admin user of the directory. Administrator-level rights are required for setting up a user store.
Admin Password and Confirm Password:
The password for the admin user and the confirmation for the password.
NOTE:
If the admin account's password needs to be changed in the LDAP directory due to some issue, then change the admin password in the Create User Store page accordingly and apply the change. Else, this admin account of the user store will get locked.
Directory Type:
Select eDirectory.
3
In the Server replica section, click New, and fill the following fields:
Name:
The display name for the LDAP directory server (for example, nescm_server).
IP Address:
The IP address of the LDAP directory server. The port is set automatically to the standard LDAP ports.
4
Click Use secure LDAP connections. You must enable SSL between the user store and the
Identity Server. The port changes to 636, which is the secure LDAP port.
5
Click Auto import trusted root.
6
Click OK to confirm the import.
7
Select the Root CA Certificate to trust any certificate signed by that certificate authority.
8
Specify an alias, then click OK.
An alias is a name you use to identify the certificate used by Access Manager.
170
NetIQ Access Manager 4.0 SP1 Identity Server Guide
9
Click Close, then click OK.
10
Under Server Replicas, verify the Validation Status.
The system displays a green check mark if the connection is valid.
11
Set up a search context.
12
Click Finish to save the information.
13
Continue with Section 4.10.3, “Creating a Contract for the Smart Card,” on page 171 .
4.10.3
Creating a Contract for the Smart Card
You need to create a contract that uses the NESCM method. To do this, you need to first create an
NMAS class, then a method that uses that class. The last task is to create a contract that uses the method. The following sections describe these tasks:
“Creating an NMAS Class for NESCM” on page 171
“Creating a Method to Use the NMAS Class” on page 172
“Creating an Authentication Contract to Use the Method” on page 173
Creating an NMAS Class for NESCM
When you create a class, you can specify values for properties. In the following steps, you specify a property value that determines the sequence of login prompts that the user receives when authenticating with a smart card.
1
In the Administration Console, click Devices > Identity Servers > Edit > Local > Classes >
New
.
2
Specify a display name for the class (for example, Class-NMAS-NESCM).
3
For the Java class, select NMASAuthClass from the selection list.
4
Click Next.
5
On the Specify Properties page, click New.
Configuring Advanced Local Authentication Procedures
171
6
Specify the following values for the property:
Property Name:
Specify NMAS_LOGIN_SEQUENCE
Property Value:
Specify Enhanced Smart Card
The Property Value matches the method name as displayed in the NMAS task > NMAS Login
Methods
.
7
Click OK, then click Finish.
8
Continue with “Creating a Method to Use the NMAS Class” on page 172 .
Creating a Method to Use the NMAS Class
When you create a method, you can specify property values that are applied to just this method and not the entire class. In this tutorial, we want the method to use the same login sequence as the class.
The method also allows you to specify which user stores can use the method. For a smart card method, you need to ensure that the user store or stores specified for the method have NESCM installed.
1
On the Local page for the Identity Server, click Methods > New.
172
NetIQ Access Manager 4.0 SP1 Identity Server Guide
2
Specify a Display name (for example, Method-NMAS-NESCM).
3
4
In the Available user stores list, select the user store created in
User Store,” on page 169 , then click the left-arrow to move this user store into the User stores
list.
Leave other settings on this page unchanged.
5
Click Finish.
6
Continue with “Creating an Authentication Contract to Use the Method” on page 173 .
Creating an Authentication Contract to Use the Method
Contracts are the element you can assign to a protect a resource.
1
On the Local page for the Identity Server, click Contracts > New.
Configuring Advanced Local Authentication Procedures
173
2
Specify a Display name (for example, Contract-NMAS-NESCM-UserStore1).
3
Enter a URI (for example, nescm/test/uri).
The URI is used to identify this contract for external providers and is a unique path value that you create.
4
In the Available methods list, select the method created in “Creating a Method to Use the
NMAS Class” on page 172 , then click the left-arrow to move this method into the Methods list.
All other fields can remain in the default state.
5
(Conditional) If you want the user’s credentials (username and password) to be available for
Identity Injection policies, add the password fetch method as a second method for the contract.
For more information about this method and class, see
Section 4.9, “Configuring Password
.
6
Click Next, then configure a card for the contract by filling in the following fields:
ID:
(Optional) Specify an alphanumeric value that identifies the card. If you need to reference this card outside of the Administration Console, you need to specify a value here. If you do not assign a value, the Identity Server creates one for its internal use.
Text:
Specify the text that is displayed on the card to the user, for example Smart Card.
Image:
Select the image to display on the card. You can select the NMAS Biometrics image or you can select the Select local image option and upload an image that your users can associate with using this smart card authentication contract.
Show Card:
Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.
7
Click Finish, then click OK.
8
Update the Identity Server.
9
Update the Access Gateway.
10
Continue with Section 4.10.4, “Assigning the NESCM Contract to a Protected Resource,” on page 175
174
NetIQ Access Manager 4.0 SP1 Identity Server Guide
4.10.4
Assigning the NESCM Contract to a Protected Resource
Contracts must be created before they can be assigned to protected resources. The following steps explain how to assign the NESCM contract to an existing protected resource. If you have not created a protected resource, see “ Configuring Protected Resources ”in the
NetIQ Access Manager 4.0 SP1
Access Gateway Guide
.
1
In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse
Proxy]
.
The reverse proxy should be configured with a resource that you want to protect with the smart card.
2
Click the Protected Resource link for the proxy service where you want to assign the NESCM contract.
3
To enable the NESCM contract on an existing protected resource, click the Authentication
Procedure
link for that resource, then select the NESCM contract created in “Creating an
Authentication Contract to Use the Method” on page 173
.
If the contract is not listed, ensure that you have updated the changes to the servers, first to the
Identity Server and then the Access Gateway. If you have multiple Identity Server configurations, ensure that the Access Gateway is assigned to the Identity Server configuration that contains the
NESCM contract (click Access Gateways > Edit > Reverse Proxy / Authentication).
4
Click OK.
5
Click the Access Gateways task, then update the Access Gateway.
6
Continue with Section 4.10.5, “Verifying the User’s Experience,” on page 175 .
4.10.5
Verifying the User’s Experience
1
From the smart-card-equipped workstation, browse to and select the URL of the proxy service where the protected resource requiring NESCM type authentication is enabled.
2
When prompted by Access Manager, enter a username.
3
When prompted for the smart card password, enter a password (the smart card PIN).
If the Smart Card contains a certificate that meets the defined criteria (in this example, a matching
Subject name and trusted signing CA), the user is now successfully authenticated to the IDP and is connected through the Access Gateway to the protected resource.
Configuring Advanced Local Authentication Procedures
175
4.10.6
Troubleshooting
Error Resolution
Authentication fails without prompting the user for the token
Verify that you have configured the class and method correctly. See
“Creating an NMAS Class for NESCM” on page 171
and
“Creating a Method to Use the NMAS Class” on page 172 .
Certificate validation fails Verify that a trusted root object created for the signing CA of the certificate on the smart card exists in the eDirectory trusted root container.
176
NetIQ Access Manager 4.0 SP1 Identity Server Guide
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
Advertisement
