-
Log in to Administration Console.
-
Click .
-
Select and specify a name for the class. For example, Social authenticator.
-
Select in the list.
-
Click .
-
(Optional) Configure the settings if you need to perform actions on the logged in user. 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:
-
Social User Attribute: Select an attribute that provides a unique user identity. For example, . The user email ID provided in a social website will be mapped to the user’s local LDAP attribute in .
User mapping is done if the value of is equal to the value of .
IMPORTANT:Provisioning does not occur in the following scenarios:
-
Local Attribute: Select an attribute, for example . The incoming configured attribute from the social website is mapped to user’s local LDAP attribute.
IMPORTANT:When you configure more than one social authentication providers, the attribute must be a multi-valued attribute. This is required to store the social attributes corresponding to each social provider.
-
User Identifier: Select this option adjacent to that you want to use in identifying the user during social authentication. For example, if you select , the incoming configured social attribute from the social website is mapped to user’s local when a user logs in for the first time. The user identifier is used to identify the user for all subsequent logins.
IMPORTANT:If you select a as and if its respective is not provided by the social provider, the user will not be authenticated. For example, Twitter does not provide email, so you should not select email as .
-
Auto Provision User Using: Select this option if you want to map an incoming user specified attribute to an existing user in the local user store. A user is provisioned when the incoming attribute matches with the local attribute. If attributes do not match, the user needs to perform the local user authentication. After authentication, the user attribute is mapped and stored. The following are two ways to auto provision a user:
-
Click (Add Mapping) to add other social attributes.
-
Click under to provide the authentication provider details.
-
Auth Provider: Select the authentication provider from the list. For example, Facebook. You can select from one of the predefined providers or select to specify your own providers. Only the predefined providers have been verified for compatibility with Access Manger. If you select , you must provide two additional information:
-
Provider Name: Specify the name of the provider. This name is case-sensitive. The social authentication class will not work if the other provider name is not identical to the name specified in the social authentication library. You can configure Yahoo, Hotmail, Salesforce, AOL, Foursquare, Myspace, Instagram, Mendeley, Yammer, and GitHub. For example, in case of GitHub, specified in social authentication library is api.github.com. So, for GitHub must be api.github.com for the GitHub social authentication class to 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 of supported providers.
-
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.
-
Click > .
-
Continue with creating a contract and a method for this class.
For configuration information, see Section 4.1.3, Configuring Authentication Methods and Section 4.1.4, Configuring Authentication Contracts.
IMPORTANT:
-
With the latest Facebook API, the user's email address is no longer shared by default. For social authentication with Facebook in Access Manager, configure the following properties in the social authentication method:
graph.facebook.com.custom_permissions = email
-
When you configure a Facebook application for integrating Access Manager with Facebook, ensure that you deselect the advanced setting. For more information about integrating Access Manager with Facebook, see Integrating Access Manager with Facebook.
How Social Authentication Works With Access Manager
For completing social authentication, 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 mapping to succeed:
<socialprovidername>:<social attribute value>
For example, consider that the social authentication class properties are set as follows:
-
: Selected
-
: Ldap Attribute:mail
-
: Email
-
: Selected
-
: Facebook
As the 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 setting is disabled, Access Manager will verify if the local user LDAP attribute mail value is facebook:<social-email-address> for the authentication to succeed.
IMPORTANT:The attribute value is set with the provider's name.
4.4.3 Configuring the Social Authentication Class
Log in to Administration Console.
Click Devices > Identity Servers > Edit > Local > Classes.
Select New and specify a name for the class. For example, Social authenticator.
Select Social Auth Class in the Java class list.
Click Next.
(Optional) Configure the User Identification settings if you need to perform actions on the logged in user. 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:
Social User Attribute: Select an attribute that provides a unique user identity. For example, Email. The user email ID provided in a social website will be mapped to the user’s local LDAP attribute in Local Attribute.
User mapping is done if the value of Local Attribute is equal to the value of Social Attribute.
IMPORTANT:Provisioning does not occur in the following scenarios:
If Facebook or Google+ is the service provider and you select DisplayName in Social User Attribute. These providers do not have the DisplayName attribute.
If Twitter is the service provider and you select Email in Social User Attribute.
Local Attribute: Select an attribute, for example LDAP Attribute:mail [LDAP Attribute Profile]. The incoming configured attribute from the social website is mapped to user’s local LDAP attribute.
IMPORTANT:When you configure more than one social authentication providers, the Local User LDAP attribute must be a multi-valued attribute. This is required to store the social attributes corresponding to each social provider.
User Identifier: Select this option adjacent to Local Attribute that you want to use in identifying the user during social authentication. For example, if you select LDAP Attribute:mail [LDAP Attribute Profile], the incoming configured social attribute from the social website is mapped to user’s local LDAP Attribute:mail [LDAP Attribute Profile] when a user logs in for the first time. The user identifier is used to identify the user for all subsequent logins.
IMPORTANT:If you select a Local User Attribute as User Identifier and if its respective Social Attribute is not provided by the social provider, the user will not be authenticated. For example, Twitter does not provide email, so you should not select email as User Identifier.
Auto Provision User Using: Select this option if you want to map an incoming user specified attribute to an existing user in the local user store. A user is provisioned when the incoming attribute matches with the local attribute. If attributes do not match, the user needs to perform the local user authentication. After authentication, the user attribute is mapped and stored. The following are two ways to auto provision a user:
SSPR: Select this option to provision the user by using details from Self Service Password Reset. This option is available if you enabled the Self Service Password Reset under Shared Settings. To enable Self Service Password Reset, see Section 2.3.10, Configuring Self Service Password Reset Server Details in Identity Server.
User Input: Select this option to prompt a user to provide information for user provisioning.
Click + (Add Mapping) to add other social attributes.
Click Add under Social Auth Providers to provide the authentication provider details.
Auth Provider: Select the authentication provider from the list. For example, Facebook. You can select from one of the predefined providers or select Other to specify your own providers. 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. This name is case-sensitive. The social authentication class will not work if the other provider name is not identical to the name specified in the social authentication library. You can configure Yahoo, Hotmail, Salesforce, AOL, Foursquare, Myspace, Instagram, Mendeley, Yammer, and GitHub. For example, in case of GitHub, Provider Name specified in social authentication library is api.github.com. So, Provider Name for GitHub must be api.github.com for the GitHub social authentication class to 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 of supported providers.
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.
Click OK > Finish.
Continue with creating a contract and a method for this class.
For configuration information, see Section 4.1.3, Configuring Authentication Methods and Section 4.1.4, Configuring Authentication Contracts.
IMPORTANT:
With the latest Facebook API, the user's email address is no longer shared by default. For social authentication with Facebook in Access Manager, configure the following properties in the social authentication method:
graph.facebook.com.custom_permissions = email
When you configure a Facebook application for integrating Access Manager with Facebook, ensure that you deselect the Require App Secret advanced setting. For more information about integrating Access Manager with Facebook, see Integrating Access Manager with Facebook.
How Social Authentication Works With Access Manager
For completing social authentication, 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 mapping to succeed:
<socialprovidername>:<social attribute value>
For example, consider that the social authentication class properties are set as follows:
Identify User Locally: Selected
Local User LDAP attribute: Ldap Attribute:mail
Social User Attribute: Email
Auto Provision User: Selected
Social Auth Provider: Facebook
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, Access Manager will verify if the local user LDAP attribute mail value is facebook:<social-email-address> for the authentication to succeed.
IMPORTANT:The attribute value is set with the provider's name.