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 (TOTP),” on page 150
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 Appendix D,
“Configuring the Supported Social Authentication Providers for API Keys and API Secrets,” on page 493.
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.
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.
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.
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.