Policies

Skip to end of metadata
Go to start of metadata

The Policies page in the RaaS settings area of the Gigya Console allows the Site Administrator to define site policies for user registration and login. You need to be logged-in to access this page. 

Note: This page provides a user-friendly interface for specifying the most significant site policies. The extended list of site policies may be accessed through the usage of the accounts.setPolicies  and  accounts.getPolicies  API methods.

Registration-as-a-Service (RaaS) is a premium platform that requires separate activation. If RaaS is not part of your site package, please contact Gigya by filling in a support form. You can access the support page by clicking Support on the upper menu after logging into your Gigya Console.


Policies Configuration

The Policies page may also be accessed by clicking Settings in the upper menu and then Policies in the left menu:

   

 

Login Identifier

Select the preferred login identifier for your users; the options are Email, Username, or both.  If you select both, your users can choose whether to use their email or username for logging in:

 

The system-defined default screen-sets are designed to work only with Email as the Login Identifier, which is the default setting. Changing the login identifier setting requires you to add a user name field to the default screen-sets or to create your own screen-sets if the screen-set was created prior to October 26th, 2015. The Login Identifier of Screen-Sets created on or after October 26th, 2015 can be set to use Username by selecting that option from the Properties window of the LoginID field. Screen-Sets can be created or updated using the Screen-Set UI Builder. 

The system does not allow duplicate Usernames or  Emails.

 

Link Accounts Support

Set whether account linking is required when a user enters the system with an unregistered social network, which shares an e-mail with a registered account.

  • Disabled - The accounts are not linked: a new (separate) account is created in which the email is not used as a login identifier.
  • Site identities only - (Default) The user will be prompted to link the social network to an existing account which uses the same email as a login identifier, only if that account is a registered site account (not created by a social network login). The user can choose to create a new unlinked account which will not use the email as a login identifier. 
  • All identities - If any account on the system uses the email entered by the user as a login identifier, the user is prompted to link the social network to that account. The user can choose to create a new unlinked account which will not use an email as a login identifier.
    NoteWhen enabling social-to-social account linking (by choosing the 'All identities' option), the corresponding screen-sets must be created to support account linking. Make sure that these are created as part of the default screen-sets schema of Gigya, or create them if necessary. Any Sites or Screen-Set Collections created after September 15th, 2014, have the necessary screens created by default.

 

Default Login and Registration Screen-Set

As of October 26th, 2015, default Gigya Screen-Sets are responsive and any screen-set collections created after that date work for both Desktop and Mobile devices.

Select "Default-RegistrationLogin" as the default screen-set for logging into web interfaces and "Default-RegistrationLogin" as the default screen-set for logging-in to mobile interfaces from the drop-down menus. 

'

The selected screen-sets pop-up following Social Login (e.g., when a user clicks on a social network button within one of Gigya's Engagement Add-Ons). The chosen default screen-sets should be used for login, and for "link accounts" and "re-authentication" situations (according to the error codes that are returned from the server).

Learn more about defining screen-sets .

Note: When using site groups, Child sites automatically inherit default screen-sets from their master site. To override the default screen-sets per child site, select 

 

Email Verification

When the user registers to a site that requires email verification, they are sent an email to verify their address. The link appearing in the verification email automatically redirects to the landing page, which in turn, finalizes the registration process and logs the user in to the site.

Check this box to require users to verify their email addresses:

 

Email verification is done by sending a verification link to the email address registered to the user. You can specify the format of the verification email using the Email Templates  page in Gigya's website. For more information, see Email Templates.

Once Require Email Verification is enabled, you must enable users to be able to complete registration. To do this, you must first ensure that you have an email field on the Complete Registration screen of your site's Screen-Set. You must also make sure that this field is set as Required in the site's schema. If you are using Gigya Default Screen-Sets, you can accomplish this by opening the Complete Registration screen in the UI Builder, selecting the Email field and checking the Required checkbox under the Schema tab of the Properties menu. Not doing this will result in users being unable to complete registration if their social network does not provide an email address, i.e., Twitter.

 

Note: When using site groups , Child sites automatically inherit email verification policy from their master site. To override email verification settings per child site, select  
For more information regarding the SSO implications of overriding email verification settings when using site groups, see SSO - Member Site Policy Override.

Activating Automatic Login

In order to use the Automatically login users upon email verification option, make sure to specify a Customize redirection URL.

 

The page at this url must contain a reference to Gigya's Javascript library. In addition, the onLogin event is automatically fired and may be used in your client-side code.

A sample html page can be found below.

<!DOCTYPE html>
<html>
<head>
<!-- mydomain.com/LandingPage.html -->
<title>Email verification custom landing page</title>
    <!-- gigya.js script should only be included once -->
    <script type="text/javascript" src="http://cdn.gigya.com/js/gigya.js?apiKey=[YOUR_API_KEY]"></script>
</head>
<body>

<script type="text/javascript">

// This function is called when the onLogin event is fired
function loggedIn(){
document.getElementById('successDiv').style.display = "";
document.getElementById('successDiv').innerHTML = "This is awesome, I am already logged in!";
}

// Register for Login event
gigya.socialize.addEventHandlers({ onLogin: loggedIn });
</script>

<div id="successDiv" style="display:none">Logged In!</div>

</body>
</html>

 

Verification Options

The following options are available once email verification has been selected:

  • Customize redirection URL - The page to which the user will be redirected after verifying their email.
  • Customize verification link expiration time - The number of hours that verification emails are valid.
  • Automatically login users upon email verification - When selected, users will be logged in automatically once their email address is verified.
    • When this option is selected, you must specify a customized redirection URL (i.e., a landing page) on your site to handle the logged-in user. The landing page must contain the Gigya Javascript library, and will automatically fire the onLogin global event. See Policies - Advanced for more information.

 

Default Verification Flows

Partners can define basic sets of policies through their account console on the Gigya website. Advanced configuration can be achieved using the account.setPolicies method.
When activating the email verification policy, new users encounter the following default login behavior:

  • For site users - When a user registers using the site's registration form, the user will be prompted to verify the registered email address by clicking the link in the verification email sent to the specified address.
    Note: The verification email can be customized. More details in the email templates section.
  • For social users - When a user registers using a social network account - the email address obtained from the social provider is considered a verified email address.
    This setting can be overridden by setting the ' verifyProviderEmail'  parameter to true  when calling the accounts.setPolicies method. If 'verifyProviderEmail' == true, the email address obtained from the social provider is considered an unverified email, until the user verifies it. 
  • If no email was obtained from the social provider - the user will be asked to enter their email address, and verify it through the authentication link. To see which providers deliver the users email address on login, visit the data availability table on the user object page.

 

Multiple Login Attempts

You can choose different options for multiple login attempts:

  • Account lockout - after a set number of failed login attempts, you can lock the account out of the system for a set number of seconds.
    • Reset failure count - determines how long after the last failed login attempt the fail count will automatically reset itself. This only applies if the account hasn't been locked out yet.
      *This checkbox appears only if you click the Lockout account option.
  • IP lockout - after a set number of failed login attempts from a certain IP address, you can lockout the IP address for a set number of seconds.
  • CAPTCHA required - after a set number of failed login attempts, you can require CAPTCHA verification for the next login.

 

Password Strength

The password strength is defined by:

  • Min Length - minimum number of characters
  • Min Character Groups - the number of the different character groups that must be included in the password. The character groups are: capital letters, lowercase letters, numbers and special characters.
    For example:
    If you define "Min Character Groups: 3", it means that a password should include at least three different types of characters. In such case, the following passwords would meet the requirement: Fcc3d1, YH*77P. And the following passwords would not meet the requirement: hwi654yy, 6FG5VV because they only include 2 character groups.
  • Regular Expression -  an alternative/additional way to specify password strength is by defining a string pattern that the passwords must match.
    Supported regEx syntax can be found here.

Password Change

In this section you may choose whether the password should be changed, and if so, after how many days. 

You can also decide to forbid reusing a specified number of previous passwords. Regardless of this setting, the password can never be reset to the current one.

 

For additional information regarding how you can use RaaS to reset a users password see Email Templates.

 

Age Limit - COPPA Compliance

Gigya supports forcing age restriction in compliance with COPPA rules. Enable this option to apply COPPA compliance and force a minimum age limit on new registered users to your site:

By default this option is disabled. When enabled, each time a user registers with your site, Gigya will check their age. Users must be 13 years +1 day old (to guarantee compliance due to time-zone variations) to register for your site. If they don't meet the minimum age requirements, they are prompted with the message "Your age does not meet the minimal age requirement (13+) for this site", if you are using our client-side tools (UI Builder/Markup Extensions).
If you are using direct server-side API calls (i.e., accounts.register) you will receive the following error in the response: "Underage user" (error code: 403044). For more information, see Identity Compliance.

If COPPA is enabled, it is important that all Registration/Registration Completion screens contain the necessary birth date fields, if a user is unable to provide their age, the user will be unable to finalize and complete their registration.

 

Additional Security Measures

Choose whether additional security measures should be employed when users register to your site. 

CAPTCHA

A CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a user identification procedure used to determine whether or not the user is human.  

Gigya's CAPTCHA component is implemented using Google's reCAPTCHA freeware, and looks like this:

To ensure proper registration form validation, be sure to include the CAPTCHA widget in your registration screen.

Account Harvesting

Login identifier harvesting, also known as account harvesting, is the process of grabbing legitimate user IDs to gain access to target systems for illegal or malicious purposes. You can protect against login identifier harvesting by enabling this option.

When enabled, new users will not be notified if a requested log-in ID already exists, while existing users entering an incorrect password will receive an "Unauthorized access error".
Because of its detrimental impact on user friendliness, this option is disabled by default.   

If you enable this option, the following API methods change their behavior:

  • The gigya-loginID-availability widget does not function, preventing new users from easily checking the availability of user IDs.
  • The accounts.getConflictingAccount method always returns a "Not supported" error. This means that you will no longer be able to link accounts.
  • The accounts.isAvailableLoginID method always returns an "Unauthorized access error" (code 403026).
  • The accounts.resetPassword method returns error code '0' (indicating success), even when the loginID passed with the method does not exist in the system or the email address is improperly formatted.
  • If a site account already exists and the user subsequently logs in with a social provider using the same email address, the accounts will not be linked and the socialize.login method returns error code '0' (indicating success) and creates a new account which does not use the email address as the login identifier.
  • The accounts.register method:

Regardless of this setting, the Login screen (from the RaaS screen-sets) always displays a generic error message when a login ID doesn't exist and/or a password is incorrect.

Automated Emails

 

Note: Before automated emails can be enabled, templates must be defined for the relevant emails. For instructions on template definition see here

 

  • New user welcome - When enabled, a mail is sent after the user successfully completes registration. On sites where verification is required, the mail will only be sent after successful verification.
  • Password reset confirmation - When enabled, a mail is sent after the user successfully resets their password, note that this is a confirmation email, and differs from thePassword Reset mail sent to a user who has forgotten their password.
  • Account deletion confirmation - When enabled, a mail is sent after the user successfully deletes their account. 

Email verification emails are enabled above

 

Two-Factor Authentication

TFA configuration is no longer set via site Policies and is now available as part of Risk Based Authentication.

 

Site Policies and SSO

You can override certain policies configured for the master site, in individual sites in a site group. 

To override master configurations for a child site:
  1. Go to the Policies page for the relevant child site. 
  2. Check the Override master settings checkbox for the relevant configurations (e.g., Additional Security Measures).
  3. Click Save Settings.

These are the settings that can be overridden by a child site: 

  • Default login and registration screen-sets
  • Email verification
  • CAPTCHA requirement for new registrations
  • The sending of the following automated emails: 
    • New user welcome
    • Password reset confirmation
    • Account deletion confirmation

Some policies can only be activated or disabled on the master site, but can be fine-tuned on each member site:

For information about the parameters that can be overridden when using the REST API, see the following pages.

accounts.setPolicies REST

accounts.getPolicies REST

 

Advanced Policies Configuration

It is important to note that any time you make a field required in the site schema, you must include a field for the item within the Registration Completion screen of your site's Screen-Sets. Failure to do this will make it impossible for some users to register with your site.

REST API

While the Gigya console provides you with certain built-in policy schemas and options, these policies can be further customized using the accounts.setPolicies REST API. 

The API allows for a greater range of flexibility when customizing site policies.

Additional Customization

Please refer to the complete Accounts REST API documentation for all possible api methods available.